A randomized controlled trial by METR gave 16 developers AI coding tools and measured what happened. They took 19% longer to complete tasks. They perceived a 20% speedup. The actual result and the felt result pointed in opposite directions, and the developers could not tell.
Even after experiencing the slowdown, they still believed AI had helped. The perception gap held.
I think about this through the lens of constraint inversion. The standard complaint about AI is that it removes constraints. You no longer need to know how to code to ship code. You no longer need design principles to produce a usable interface. The loss is real, but the diagnosis is usually wrong. The constraint that got removed was doing the thinking.
The constraint was the thinking
Before AI, limited execution capacity forced you to be selective. You couldn't build everything, so you had to decide what was worth building. That bottleneck was execution. But execution constraints were subsidizing judgment. They made you slow, and slow made you careful.
AI removed the bottleneck. It did not replace what the bottleneck was funding.
Itamar Gilad names this the competence/judgment gap: "AI lets you do work that you're poorly equipped to judge. A PM may generate bad production code and a developer may choose bad ideas, and neither can tell the difference." He cites Anthropic's own data. Developers approved Claude Code suggestions at a 93% rate. Anthropic's classifiers caught 89% of harmful changes. Humans caught 13%. A 93% approval rate tells you nobody is evaluating.
Competent, conventional, shipped
The evidence shows up in the output. Romero et al. had 92 participants evaluate AI-generated and human-designed interfaces in a blinded study. The AI-generated work scored well on usability and efficiency but neutral to negative on originality and innovation. AI produces functional interfaces that reinforce existing visual and structural patterns. The work is competent. It is also interchangeable.
This is where the danger sits. Incompetence is visible. Bad code breaks. Ugly interfaces get flagged in the first review. But competent-looking work that lacks judgment passes review. It ships. It accumulates.
Second Talent, aggregating data from CodeRabbit, GitClear, and Stack Overflow, reports that AI-generated code carries 1.7 times more total issues than human-written code. Logic and correctness errors run 1.75 times higher. Only 3% of developers say they highly trust AI-generated code. And 67% report spending more time debugging AI-generated code.
The code works well enough to approve. It fails quietly enough to compound.
The volume outran the judgment
Fifty percent of designers now ship AI-generated code to production, according to the State of AI Design Report 2026. Eighty percent say they still rely on their own quality judgment for final polish. Those two numbers together should make you uneasy. The volume of output went up. The capacity to evaluate it stayed flat. Forty-three percent of companies now expect working prototypes as standard deliverables, which means the judgment gap is becoming a job requirement.
In a Hacker News thread discussing the METR study, one practitioner described the split: "AI is very effective at the boilerplate-heavy tasks that I hate and very ineffective at the architecture and debugging tasks that I love." That maps the gap precisely. AI delivers competence on the parts that were never the hard problem. The hard problem, knowing whether the thing you built is the right thing, remains entirely yours.
Add the constraint back
Constraint inversion says: when removing a constraint made things worse, add a different constraint that does the same job on purpose. NN/g argued in June 2026 that the core skill of design is shifting from specification to critique. The job becomes less about telling the machine what to build and more about defining what good looks like and evaluating how closely the output adheres to that definition. That reframing is itself a constraint. It forces a judgment step before anything ships.
The constraint to add back is explicit evaluation checkpoints. A team that ships AI-generated work needs someone whose job is to evaluate, not generate, and a judgment gate embedded in the process with the authority to kill work that is competent but wrong.
Most teams will not do this. Adding a constraint feels like slowing down, and the whole point of adopting AI was speed. That is exactly why competence without judgment will keep shipping. The teams that survive will be the ones who recognize what the execution constraint was actually funding: the question nobody wants to ask when the demo looks good and the deadline is Thursday. Is this actually worth building, or did we just build it because we could?
.webp)
.webp)
.webp)
