On a platform we built, an AI agent wrote a small feature: a warning that appears when a user makes a risky change. It built cleanly and went in. In the next two and a half hours it needed four more fixes. The warning was drawn behind another layer of the screen, so nobody could see it. Worse, the screen said "saved" while the change was never written to the database.
The feature and its first fixes reached the production branch. The build passed, because a build does not check whether a warning is visible or a save really happened.
The code arrived in minutes. Understanding it took longer, and nobody had planned for that part.
What changed
AI writes much of the first draft now. On our platform we can see it in the commit history, because many commits carry a line saying an AI model co-wrote them. Over the summer that was about 2% of commits. In September it was 21%. In the first half of October it was 40%, and those commits held 80% of the new code and test lines.
These numbers only count commits that say so. The real share is likely higher, and I am one of the people writing them.
Two things came with it. Code arrived faster, and it arrived in bigger pieces. Commits with the AI line had a median of 171 lines. Commits without it had a median of 55.
This matches what the 2024 DORA report found across many teams. More AI adoption went with a small drop in delivery throughput (an estimated 1.5%) and a bigger drop in delivery stability (7.2%), as InfoQ's summary reports. One explanation, from Laura Tacho of DX, quoted there: batch size seems to grow when AI writes the code, and bigger changes are riskier. DORA's own guide to working in small batches now says it plainly: AI tools tend to hand you a whole feature at once, and teams should resist "the temptation to generate massive pull requests".
Review became the bottleneck, and we skipped it
When code is cheap to write, the slow step moves. It moves to reading.
DORA's small-batch guide also notes that a small chunk of machine-written code can need more effort per line to review than code a person wrote. That fits what I see. The author of the PR may not fully know what is in it, because they didn't type it.
Here is the uncomfortable part. When we looked at our own history, most pull requests were one commit, merged by the person who wrote it, about a minute after the last commit. 189 of 195 feature PRs were merged by their own author. The merges into production were often 5,000 to 15,000 lines, and most were pushed directly, not through a PR at all.
That is not review. Nobody decided to skip it. Writing got faster, and the process around it stayed the same size. I am in those numbers too.
Cognitive debt
Technical debt is code you know is messy. Cognitive debt is code nobody on the team really understands, because nobody really wrote it. It works until it doesn't, and then nobody knows where to look.
The term comes from Margaret-Anne Storey, a computer science professor at the University of Victoria. In her post she describes a student team that hit a wall mid-term: simple changes broke other parts, and nobody could explain why the system was built the way it was. Her point is that this debt lives in people's heads, not in the code. The code can be clean and well tested, and the team can still be stuck.
I noticed it when we found the same logic written twice. Our platform had a feature for merging duplicate records. When a newer, agent-written part of the system needed the same thing, it got a second version written from scratch. The two share about 5% of their lines, so nobody copied anything. Generating new code was simply easier than finding the code that already existed.
This is not only us. GitClear's 2025 code quality research looked at 211 million changed lines and found that blocks of five or more duplicated lines grew about eightfold in 2024. It was also the first year that copy-pasted lines outnumbered moved lines, which GitClear reads as less refactoring. Their explanation is close to ours: an assistant makes it easy to add a new block, and less likely to suggest reusing a function it can't see.
There is a quieter version too. We wrote an instructions file for the coding agents in one part of the code. A few months later it described the main state file as about 3,000 lines long. It had grown to about 3,700. The agents were reading an old map, and so was anyone new who read it.
Tests matter more
When the person who opened the PR may not know every line in it, tests are what catch the rest.
One more example from our history, and this one carries no AI marker. An automated edit script was meant to add a missing import to a file. The file didn't have the line the script was looking for, so the edit silently did nothing. The check written alongside it only covered the other change in the same script. The test suite passed because no test loaded that file. The app crashed to a white screen on load. The fix went in 11 minutes later.
The test suite also had a habit worth naming. Commit after commit reported the same few dozen known failures as "unchanged". A red test that everyone has learned to ignore checks nothing.
What stays the engineer's job
When agents write the code, three things stay with the engineer:
- Knowing what should be built. The agent builds what it was asked. Asking for the right thing is still a person's job.
- Deciding how it fits the system. In Clean Architecture, Robert Martin describes architecture as drawing boundaries between parts of a system. An agent working from one prompt does not see those lines unless someone shows them.
- Being able to explain every line you merge. Storey's first suggestion is along these lines: at least one person should fully understand each AI-written change before it ships.
Writing is no longer where most of the time goes. Reviewing is the job now.
If your team is shipping faster with agents and the review side hasn't caught up, that is part of how we work in product engineering.
What I would change in a team's process tomorrow
None of this is new. It is old advice that matters more now.
- Small PRs, even when AI writes them. Ask the agent for one step at a time. If a change can't be reviewed in one sitting, split it.
- The author must be able to explain any line. If they can't, it isn't ready, whoever typed it.
- Tests with every change, run by CI. Not on someone's laptop, not "the same failures as before". In our case only one of four repositories had a test step in CI at all.
- An architecture note the agents read too. A short file that says where things live, which patterns to reuse and which to avoid. Formats like AGENTS.md exist for this. Then keep it current, because a stale note teaches the agent the old system.
The agents stop inventing a new pattern each time only when someone has written down the old one.
One thing to do this week
Open the last pull request your team merged that an agent helped write. Pick ten lines at random. Ask the author to explain each one, without opening the chat that produced it.
The lines they can't explain are your cognitive debt. Now you know where it is.