“We’ll Fix It Later” Was the Review Process
Business software has had a review problem for as long as I’ve been paid to write it, which is since 1991. The clients I worked for wanted something that mostly worked, as fast as they could get it. Both sides agreed that we could always come back and fix whatever turned out to be wrong during a phase two when other changes would be implemented. That understanding took the place of what a real review would have done. AI has sped up the coding phase and made the return visit far more expensive than the people agreeing to it realize.
Three Days or Four Weeks
Shortly after the Y2K non-fiasco, I worked on a medical tracking system for a client in Tulsa. The system was an early attempt at applying logic and rules to data for predictive analysis. It loaded its data from a file somebody else sent, which served as the basis for its reports. I recommended building guardrails around the load process so that a bad file would be caught before it went in and could disrupt the reports and analysis. It was about three days of work to implement because I had the codebase already cracked open. The client assured me that the current process was fine, and that they would make sure the data clerk knew how to run it.
For a couple of months, the clerk ran it and everything worked. The reports generated properly, and the patient outcomes they were tracking showed steady improvement. As with all computer systems, the source system for the data file was updated and the format of the incoming file changed slightly. Some of the data started landing in the wrong fields and nobody noticed for a month. When the reports were run, the numbers didn’t look right, so they reloaded the data. Then somebody looked at the raw file, saw what had moved, fixed the fields, and loaded it again. After that, only half the reports were correct and the other half showed three times the real figures. They had loaded the data multiple times without verifying if it already existed.
They called me in the third month. I refreshed all of the data, reworked the reports, and built the guardrails I had recommended at the start. The cleanup and recoding effort took about four weeks. Both repairs made before anyone called me were made by people who hadn’t built the load, and each one left the data in worse shape than it found it. In “Perfect Software” I described a floor that goes into a system whether anyone asks for it or not, and validation on anything crossing a trust boundary is on that list. On this job, I asked, and I was told no. On later projects, three days versus four weeks became my standard explanation for why guardrails and validation aren’t optional.
Why Later Used to Be Cheap
Fixing it later was a reasonable bargain for most of the years I worked under it, and it rested on two critical things nobody wrote down. There was only so much unreviewed code, because a developer could type a limited amount of code in a given day. And the person who came back to fix a bug was usually the person who had written it, so they knew where to look before they opened the file. The medical system showed me what happens when the second assumption fails. AI removes both at once. The code arrives faster than anyone ever typed it, and nobody on the team typed it, so nobody carries it in their head. Whoever comes back to fix it is reading it for the first time, and that includes the developer whose name is on it.
A Harvard working paper by Fiona Chen and James Stratton, updated in August 2026, followed software development activity across 718 companies. After firms adopted AI coding agents, lines of code per developer rose about 30 percent, commits 20 percent, and pull requests 23 percent. The researchers found no statistically significant corresponding increase in completed software output. Meanwhile, the share of pull requests sent back for changes rose from 13 percent to about 25 percent. Before adoption, the average pull request contained more than a thousand changed lines and received fewer than two review comments. I read fewer than two comments on more than a thousand lines as the fix-it-later bargain showing up in the data, before the agents ever arrived.
Later, on Purpose
Anthropic, the company that makes Claude, has published an account of rebuilding its source control because the tools it had were built for human scale. In May 2026 it merged around 2,500 code changes a day, and by September more than 30,000. At that volume, some of its automated verification moved to after the merge and before deployment. Anthropic accepts that changes can conflict, because Claude can usually fix the conflicts faster than a person can spot them. The engineers on that project still review every change, and they read each one for its intent instead of line by line. That is a controlled version of “later,” deliberately built into the process by the company that makes the tool. For a company with its own model available to do the fixing, an engineering environment built around it, and a token budget few businesses would contemplate, that can be a sound tradeoff. It also answers only half of what the medical system taught me.
Anthropic has answered one half with agents, extensive automation, and engineers who still review every change. Most businesses aren’t Anthropic. For everyone else, a promise to fix it later now needs two things attached to it: who will do the fixing, and what they will know about the code on the day they open it. The second question is the one that cost me four weeks in Tulsa. The only durable answer I know is an old one: somebody has to review the work closely enough to understand what is going into production. AI can participate in that review. It can automate parts of it. It may eventually perform most of it. But somebody still has to own the intent.
Otherwise the review still happens.
It just happens in production, and the client is the reviewer.