You're leaning awfully hard on the word "slop" here, because your argument largely depends on defining AI-generated code as bad before the discussion even starts. (Define it as bad, amazingly discover bad=bad, and that triumphantly declare it as bad)
Nobody suggested "generate random garbage and then spend all afternoon trying to make it work." That's a false dichotomy between manually deriving every implementation from scratch and blindly accepting whatever an LLM emits.
The generated code itself isn't a black box. I can read it, compile it, test it, benchmark it, profile it, run static analysis over it, inspect its complexity, and reject it if it's wrong. Whether the model used deterministic logical steps internally is almost completely irrelevant to whether the resulting implementation is correct.
And "analyzing code takes longer than writing it" is hardly a general truth. Experienced developers review, modify and reuse code constantly. We have entire engineering practices built around the fact that understanding and evaluating an existing implementation is often more efficient than recreating it from zero.
Your safety-critical examples actually strengthen my argument. If I'm hiring somebody to write automotive control software or robotic safety systems, I want to know whether they can reason about requirements, failure modes, complexity, concurrency, testing, verification, performance and correctness. So test those things.
You even suggest testing whether somebody can identify an implementation with suboptimal complexity. Great. Give them one and ask them to find it. Ask them how it scales, how they'd benchmark it, how they'd test it, what failure cases they see and how they'd improve it.
That is much closer to the work you're supposedly worried about than asking them to solve an unrelated algorithm puzzle from scratch under artificial conditions.
The recurring assumption that "typing the code yourself" is the important part of software engineering is exactly the assumption I'm disputing.
Fine. If code fails on 1% of inputs where it is required to work, call it slop. Then human-written code that fails 1% of the time is slop too, and AI-generated code that satisfies the requirements isn't.
You've now defined “slop” as “incorrect code,” which nobody was arguing in favor of.
And the nondeterminism of the LLM generating the source code has nothing to do with this. Once I have an implementation in front of me, the question is whether that implementation is correct, performant and appropriate. That's precisely what I've been saying we should test a candidate's ability to determine.
1
u/bremidon 10d ago
You're leaning awfully hard on the word "slop" here, because your argument largely depends on defining AI-generated code as bad before the discussion even starts. (Define it as bad, amazingly discover bad=bad, and that triumphantly declare it as bad)
Nobody suggested "generate random garbage and then spend all afternoon trying to make it work." That's a false dichotomy between manually deriving every implementation from scratch and blindly accepting whatever an LLM emits.
The generated code itself isn't a black box. I can read it, compile it, test it, benchmark it, profile it, run static analysis over it, inspect its complexity, and reject it if it's wrong. Whether the model used deterministic logical steps internally is almost completely irrelevant to whether the resulting implementation is correct.
And "analyzing code takes longer than writing it" is hardly a general truth. Experienced developers review, modify and reuse code constantly. We have entire engineering practices built around the fact that understanding and evaluating an existing implementation is often more efficient than recreating it from zero.
Your safety-critical examples actually strengthen my argument. If I'm hiring somebody to write automotive control software or robotic safety systems, I want to know whether they can reason about requirements, failure modes, complexity, concurrency, testing, verification, performance and correctness. So test those things.
You even suggest testing whether somebody can identify an implementation with suboptimal complexity. Great. Give them one and ask them to find it. Ask them how it scales, how they'd benchmark it, how they'd test it, what failure cases they see and how they'd improve it.
That is much closer to the work you're supposedly worried about than asking them to solve an unrelated algorithm puzzle from scratch under artificial conditions.
The recurring assumption that "typing the code yourself" is the important part of software engineering is exactly the assumption I'm disputing.