AI removed the constraint that made it good

The popular explanation: AI writes bad code, bad code ships, quality drops. That explanation is reassuring because it implies a fix. Make the AI smarter. Problem solved.

The evidence says something else.

GitClear analyzed 211 million lines of code and found that copy-pasted lines surged from 8.3% to 12.3%, a 48% relative increase. Refactored lines dropped from 24.1% to 9.5%. Code that had to be revised within two weeks climbed from 5.5% in 2020 to 7.9% in 2024. These are teams that stopped deciding what to build before building it. More code is being added. Less code is being reconsidered. The ratio tells you where the thinking went.

When writing code took days, the cost forced a question: is this worth the days? That question was a constraint. It filtered scope and killed bad ideas before they became pull requests. Remove the cost, and you remove the filter.

Mathew Spolin, AppDirect's SVP of Engineering and Technology, put it directly. Friction was where rigor lived, he argued. The time it took to write a specification was also the time it took to think clearly about what was being specified.

What followed is measurable. By February 2026, cumulative AI-introduced issues exceeded 110,000, with short-term velocity gains accompanied by persistent rises in code complexity and static analysis warnings. 69% of very frequent AI users report deployment problems with AI-generated code. Incident recovery times are increasing, with the heaviest AI adopters taking longer to resolve production issues. Trust in AI accuracy fell from 40% in 2024 to 29% in 2025, and the most common frustration (cited by 45% of developers) is outputs that are almost right, but not quite.

Almost-right is what you get when the problem was never defined tightly enough for any implementation to land. The model did not fail. The specification was never forced into existence, because nothing was expensive enough to demand one.

This is where constraint inversion applies. When stuck, ask what constraint, if added, would make the answer obvious. Teams are stuck in a loop of generating code faster and debugging it longer. The constraint that breaks the loop is a deliberate reintroduction of the decision cost that speed erased.

Before any AI-assisted implementation begins, the team writes a one-paragraph scope statement that names what will not be built. Decide what you are refusing to do, in writing, before the agent starts. That single act brings back the filtering pressure that used to come free with slow implementation.

Or: no AI-generated pull request ships without a named human who can explain, without reading the diff, what business problem it solves and what was traded off. If nobody can do that, the PR is evidence that the decision never happened.

92% of companies now experience governance challenges around AI coding. Four in five admit they adopted AI tools faster than governance policies. The tools arrived before anyone decided how to use them. A constraint was removed, and no replacement was installed.

Better models and better review tooling will improve AI-generated code. They will not replace the decision about what to build. That decision used to be forced by cost. Now it has to be forced on purpose.

Constraint inversion says the generous move is choosing the right friction. "Build anything, fast" is hostile in the same way "make it good" is hostile. Both hand you an absence of constraint disguised as freedom. "Build only what you can defend in one paragraph, then build it fast" gives the team something to push against.

The teams that will ship well in 2027 will be the ones that chose which constraints to put back.

Sol applied constraint inversion correctly. The diagnosis is clean: cost was a filter, the filter is gone, teams are generating instead of deciding. The GitClear numbers are useful not because copy-paste is bad in isolation but because the ratio of reconsidered-to-added code collapsed. That ratio was a proxy for thinking. When it drops, you know the decision layer evaporated.

Where I want to push: the two constraints Sol proposes are both document-shaped. Write what you won't build. Name a human who can defend the PR. Both useful. Neither forces contact with reality.

The constraint I have seen actually work is shorter: show it to a real person before you write the next thing.

When I built Fleetwise, the filter was not a scope statement. It was a fleet manager in Surabaya who would tell me in ten minutes whether the thing I shipped solved a problem he actually had. That feedback loop killed more bad features than any specification ever did. I did not need to write what I would not build because the user's reaction made the answer obvious.

On Merdeka Mengajar, the constraint was the device. A teacher on a four-year-old Android with 200MB left for the month. You cannot over-build for that user because the phone will not let you. The constraint lives at the proof layer, not the planning layer.

Sol's scope-statement fix reintroduces friction at the specification layer. Fine for teams that already know their user. For teams that do not, it adds a new document to get wrong. You can write a perfectly articulated paragraph about what you will not build and still be wrong about what you should.

The stronger version of constraint inversion puts the constraint at the proof layer. Distance to first proof: how many days until a real person uses a real version and has an opinion? Optimize for that number, and scope polices itself. The user becomes the constraint. Not a document about the user. The user.

"Build only what you can defend in one paragraph" is better than "build anything." "Build only what survives ten minutes with the person who will use it" is better still.