The judgement is the product.
An LLM is the fastest junior engineer you will ever hire. It is also never unsure. That second trait is the catch.
Vibe coding (take the plausible output, run it once, move on) gets you to a demo. It does not get you to a build that ships, survives a save-format change, and still runs in eighteen months. The distance between those two is filled with engineering judgement, and on a real project it gets exercised constantly. Below: real calls, on real projects, where accepting the model's first answer would have shipped a bug, a crash, or a wasted afternoon.
What the model gets confidently wrong.
The fix that looked done but never ran.
A flagged task: move the build-cancel refund logic out of a throwaway menu widget. Easy to implement, easy to mark complete. I have a rule that nothing is done until it's verified in the running game, so I ran it, and the refund spawned zero items. Digging in: the refund code spawned a world-actor class off each item's data, and not one of the two-hundred-plus items in the database actually set that field. Materials had been silently vanishing on every cancelled build, for every recipe, indefinitely. The model "completed the task." The engineering was finding out the task description and the real bug were two different things.
The elegant fix that would have crashed the engine.
A menu-input bug had a clean-sounding solution: classify menus by their input mode instead of by class. Tidy, correct-looking, and a stack-overflow waiting to happen, because the input-stub's own mode query calls back into the very function I was rewriting. Pattern-matching the fix ships an infinite recursion that takes the whole editor down. Understanding the call graph means you exclude the stub by class first, then probe the rest. You only catch that if you're reading the system, not the snippet.
Verified in isolation is not verified in play.
I built a Crafting tab on a game project. I wired it to key 6. I wrote a screenshot harness that rendered it. I reported it as done and verified across multiple sessions. It was invisible in actual play, because the tab-bar header was a hardcoded list of five tabs and 6 and 7 never drew. My harness set the tab directly and drew it, so of course it looked fine. I never walked the path a real player takes: open the game, look at the tab bar, press a number. An LLM optimises for the verification it can run and presents that as confidence. The verification that actually matters is a human pressing keys in the real build, and that one I structurally can't do.
The test result I refused to trust.
After a pure logging change, a menu-cycle test went from green to failing. The lazy reactions are both wrong: panic-revert a correct change, or "fix" it by sprinkling delays until it passes. A logging edit cannot alter menu logic, so the test was lying, not the code. I traced it to an artefact in the test harness itself: a rapid open/close pattern that desynced and poisoned later runs. Proved it by clearing the stuck state directly, then confirmed the real behaviour was fine with a clean run. The call was to debug the cause, not silence the symptom.
A cook failure that wasn’t a code bug.
A package failed at the end with a vague "unknown cook failure" that mentioned a thermal component. Hand that to a model and it will happily start editing C++ for a thermal class that no longer exists. The actual cause was content, not code: an orphaned UI asset whose parent class had been deleted, plus a dangling reference buried in another widget's animation data. Knowing that a cook failure with no compiler error is almost always a Blueprint or asset problem, and that it's an editor fix not a code one, saved a hunt in entirely the wrong file.
Works in the editor is not works in the build.
World generation respected the player's seed perfectly in the editor and silently ignored it in the packaged game. Nothing in the code looked wrong. The fix lived in plugin internals and in a divergence the model has no reason to know exists: the voxel world auto-instantiating differently in a cooked build, requiring the seed to be forced through a specific override path before generation. The model optimises for "compiles and runs here." A developer remembers that here and shipped are different machines.
Knowing which fix not to make.
The most senior call is usually a no. An audit flagged a key-rebinding bug I could have closed in five minutes, and I deliberately left it open. The only honest way to verify a rebinding change is to exercise the live input system; my test harness can't reach that path; shipping an unverified change to something that can break all input is precisely the carelessness that gives AI-assisted work its bad name. Same instinct, one level up, in the architecture: the reflex of the model is to either reinvent what the engine already does well or cram everything into a heavyweight framework that doesn't fit. So the rule on this project is explicit about both: move the UI onto the engine's native system, and keep persistence and the medical simulation deliberately custom, because the native equivalents genuinely don't survive a shipped build or are wrong for the problem. Restraint isn't slower. It's the part that keeps the project shippable.
The model is leverage. The judgement is the product.
Verification at the level that matters
Compile-passes, unit-test-greens, and synthetic renders are the verification an LLM can run. The verification a buyer actually pays for is a human walking the user path on a real build. That gap is where shipped bugs live.
Architectural stewardship
An LLM cheerfully bolts the two-hundredth feature onto a structure that should have been split a hundred features ago. The instinct to stop and say "we are painting ourselves into a corner" is human, and someone has to have it.
Taste, including the taste to throw work away
When a "nice realism feature" breaks the survival loop, the right move is to delete the feature, not to patch around it. The model’s instinct is to keep the work. Knowing which work to throw away is the part that doesn’t come in the box.
The harness that makes the model trustworthy
The LLM does its best work inside a discipline framework: drive the real input path, assert observable outcomes, treat "tests green but feature invisible" as a failure mode. That framework is engineering work in its own right. Without it, you get a confident pile of green checkmarks sitting on top of an invisible feature.
Anyone can prompt a model. Pay for the person who knows where it's wrong.
None of the above is an argument against the tools. I use them harder than most, and the volume of work that's possible with them is genuinely new. It is an argument about where the value actually sits. The LLM writes fast. Knowing which of its answers you're not allowed to trust yet, that's the job, and it doesn't come in the box.