The pull request was fourteen hundred lines across nine files. The description said add user flow. It was approved four minutes after it was opened, by somebody who was in a meeting at the time, and it went to production that afternoon.

Nothing bad happened. That is the important part. Nothing bad happened for about eleven weeks.

I want to be careful here, because there is a lot of moralizing about this subject and most of it is written by people who are not shipping anything. The productivity gains are real. Teams report forty to sixty percent improvements on bounded tasks and I believe them, because I have seen it. The problem is not the tool. It is that a tool designed for exploration keeps getting promoted into a role it was never designed for, and the promotion happens silently.

What the data actually says

The most careful measurement available comes from an analysis of two hundred and eleven million lines of code changed between 2020 and 2024 across repositories at large technology companies. Two findings matter.

Copy-pasted code rose from 8.3 percent of changed lines to 12.3 percent, a relative increase of roughly half. Over the same period, refactored lines fell from around twenty-five percent to under ten percent. In 2024, for the first time on record, copy-pasted code exceeded refactored code.

That inversion is the whole story in one statistic. Refactoring is how a codebase stays comprehensible. Duplication is how it stops being comprehensible. The tools made it cheaper to add and no cheaper to consolidate, so the ratio moved, and it moved in the direction that compounds.

A separate study of around eight million pull requests found technical debt rising by thirty to forty percent after teams adopted AI coding tools. And in a detail I find quietly telling, the researcher who coined the term vibe coding in early 2025 had, by early 2026, publicly described it as past its moment and shifted to advocating a model with substantially more human oversight in the loop. The phrase did not survive its first year before its inventor moved on.

Where the line goes

The useful framing is not whether to use these tools. It is which code is allowed to be produced this way.

Generate freely. Interface components, internal dashboards, one-off scripts, data migrations you will inspect anyway, test fixtures, prototypes, anything you intend to throw away, anything with no access to production data. This is the majority of code by volume and the speed gain here is close to free.

Never without dedicated review and automated analysis. Authentication. Authorization, which is a separate and more frequently broken thing. Payment handling. Anything touching personal data. Anything that writes to production. Anything that decides what a user is allowed to see.

The failure modes in that second category are boringly consistent. Across incidents reported through 2025 and into 2026, the same handful of causes recur: databases left open by default configuration, row-level security never enabled, keys hardcoded into code that reaches the client, backend services exposed without authentication. None of these are exotic. All of them are the kind of thing that a generated solution produces because it satisfies the request as stated and nobody stated the rest.

The ninety-day reckoning

There is a recognizable arc and it runs on roughly a quarterly clock.

Weeks one to four, velocity is extraordinary and everybody is delighted. Weeks four to ten, small inconsistencies accumulate: three different ways of handling errors, two competing patterns for the same operation, functions that do four things because it was easier to extend than to separate. Around week ten to twelve, the first incidents arrive, and they are hard to diagnose because nobody wrote the code and the person debugging it is reading it for the first time under pressure.

By day ninety, teams commonly report spending twenty to thirty percent of sprint capacity on defects traceable to generated code. The velocity gain from month one is gone. Then it goes negative, because every subsequent change is harder in a codebase nobody trusts.

This is now a market. Rescue engineering, the business of taking a product that was built quickly and rebuilding it into something maintainable, is a recognized specialty with recognized pricing, commonly quoted between fifty thousand and five hundred thousand dollars depending on how long the product ran before somebody looked underneath it. Of the several thousand startups that shipped production applications using these tools through 2025, a large majority reportedly needed some form of partial rebuild or rescue work within the following year.

The cost is not the rebuild. The cost is the six months you spend doing it instead of building.

The protocol that actually works

Five rules, and none of them require slowing down much.

• Somebody must be able to explain it. This is the only rule that really matters. If nobody on the team can explain how authentication works without opening a chat window, you do not have authentication. You have an arrangement that has not yet been tested.
• Cap diff size on anything sensitive. A fourteen hundred line change is not reviewable and everybody knows it, which is why it gets approved rather than read. Small changes get read.
• Static analysis on every path that handles credentials, permissions or personal data. Automated, in the pipeline, blocking. This costs nothing per run and catches the recurring failures listed above.
• Write the tests by a different route than the code. Generated code validated by generated tests derived from the same description will agree with itself confidently. Specify the tests from the requirement, not from the implementation.
• Keep your junior engineers and give them maintenance work. This one is strategic rather than tactical. The people who will be able to maintain generated systems in two years are the people who spend this year reading and modifying code they did not write. That is exactly the work that is being automated away from them, and teams that eliminate it are removing the pipeline for the skill they will most need.

We did eventually go back and read the fourteen hundred line change. It was mostly fine. It also contained a permission check that ran on the client and not on the server, which meant the check was a suggestion. Finding it took an afternoon. Finding it after somebody else had would have taken considerably longer and involved a lawyer.

You can ship code you do not understand. You cannot run a company you do not understand.

Tomorrow: the churn email, and the three kinds of slop.