For decades, software development was organized around one assumption: writing code is the hard, expensive part. It needs skilled people. Those people are scarce. Everything else in the process existed to protect that constraint. That assumption just broke.
The fracture did not announce itself. There was no single date. But sometime in the last year, frontier AI models crossed a threshold where humans stopped being the primary authors of code, and the entire apparatus built on the old assumption started groaning under the weight of a reality it was not designed for.
The result is two new kinds of debt. AI debt and product debt. Both are accumulating right now in codebases across the industry. This piece is about how we got here, what the breakdown looks like from inside, and what to call it once we can finally see its shape.
How the old machine worked
To understand the groaning, you have to understand what the machine was built to do.
The software development lifecycle was a bottleneck-management system. Its job was to protect the scarce, expensive resources that created code. Before any developer wrote a single line, a coordinated effort on the front end made sure the work was worth doing: product requirements documents, technical design documents, architecture reviews. Business analysts, product managers, and designers worked upfront to reduce the odds of the expensive resource building the wrong thing. QA teams, automation engineers, and code reviewers worked on the back end to catch problems before they reached production.
This was not bureaucracy for its own sake. It was rational systems engineering. In any constrained system, the way to raise throughput is to find the bottleneck and relieve it. For decades, the bottleneck was writing code. The whole org chart was a response to that fact. Then, when the opportunity presented itself, we swiftly relieved it, eager to get more through.
The bottleneck moved in both directions
Code can now be produced almost as fast as you can articulate the idea.
Steve Yegge’s “Welcome to Gas City” traces the adoption ladder. It starts with IDE autocomplete, toes barely wet, and ends somewhere you could not have pictured from the first rung. You use Cursor to get comfortable, then stop writing code and start watching it get written. You trust the first Claude Code instance to run with more autonomy, checking its output instead of supervising every keystroke. With it running on its own, your hands go idle, so you open a second session, then a third. Before long you are running a swarm. As Yegge puts it, you become a shepherd tending flocks of agents, and you consider recruiting an agent to manage the other agents.
That progression accelerated sharply once frontier models reached context windows large enough to hold an enterprise codebase. An agent that compacts every few hundred lines of context cannot maintain continuity across a real system. Once that ceiling lifted, the dynamic changed.
The adoption numbers confirm what the anecdote suggests, and they contain a paradox. According to the 2025 Stack Overflow Developer Survey of more than 49,000 developers, 84% use or plan to use AI coding tools. Trust tells a different story: only 3% report highly trusting AI output, and overall trust in its accuracy fell from 40% to 29% in a single year. Yet over the same period favorability held at a clear majority. That is not the profile of a tool people resent. It is the profile of one they will not put down, flaws and all. We adopted the tool faster than we learned to believe in it.
Here is what systems thinking warns you about and most of us missed. Relieving a bottleneck does not end the story. The constraint moves. And when the bottleneck sits in the middle of the pipeline, relieving it does not push the pressure in one direction. It pushes outward to both ends. Writing code was the bottleneck in the middle. The middle is now a firehose. The two stages that flank it are where everything backs up: upstream, where you decide what’s worth building, and downstream, where you verify that what got built is what was intended.
What to Build PRDs · Design · Strategy
What Was Built Review · QA · Security
A process built for a trickle meets a firehose
The adoption curve has a second effect that gets less attention. It is not just senior developers running faster. It is everyone.
Juniors who never knew Java are now comfortable shipping features in a language they never learned. The traditional T-shape of developer skills is spreading and rising at the base. The areas where an experienced engineer outperforms the model keep shrinking. And it has moved past engineering entirely: product managers are opening their own pull requests. Designers are making their own tweaks. The code is coming from more people, at higher volume, from more angles than the SDLC ever anticipated.
The flood was not only possible. It became mandatory.
By early 2026, many companies were operating under what the industry started calling “token maxing”: maximize AI usage, maximize code throughput, ship at the highest possible velocity so no competitor outruns you. The fear driving this had a name too: the “SaaSpocalypse,” the worry that customers would stop buying software and start building their own with tools like Claude Code and Workspaces. Companies, terrified of being stranded on the wrong side of that shift, did not just permit the firehose. They ordered it open.
The pattern was visible in public. Coinbase’s CEO mandated AI coding tools company-wide, gave engineers roughly a week to adopt them, and fired the holdouts (Fortune, August 2025). Coinbase reported that about a third of its code was AI-written, with the target set at half. This was not an outlier; it was a signal of the operating mode most companies had already quietly adopted. Bloomberg reported that agentic AI usage at one large company jumped from about 32% in February 2026 to 84% in March 2026.
The “token maxing” framing came under early criticism. Gergely Orosz at The Pragmatic Engineer compared it to measuring developer productivity by lines of code: a metric that tells you something, just not the thing you actually care about. The criticism was structurally correct. But the mandate was already out.
The bill for that decision would arrive later, and from two directions.
A process designed for a trickle meets a firehose. And it is breaking in specific, predictable places.
Where the system is breaking: upstream
The upstream flank breaks first, and it breaks quietly.
When building is expensive, the cost of getting it wrong is obvious. Upfront rigor is not a tax on velocity; it is protection for your most scarce resource. Once code gets cheap, that logic inverts. A PRD for a two-hour build starts to feel absurd. So the rigor disappears. Ideas ship before they are vetted. The planning phase that once forced decisions gets skipped. Nobody runs the full technical design process on something an agent can prototype in a morning.
The features accumulate, but the judgment does not. Roadmaps get executed because execution is now cheap, not because anyone has asked whether the features cohere or whether the product gains something beyond surface area. Product managers and designers push their own changes straight to branches without routing through the people who used to catch the downstream consequences. The product gains features and loses identity. This is not speed for its own sake. The fear behind it is well founded: a nimble AI-native competitor can now move faster than any incumbent roadmap was built to withstand, and the boards behind these companies are pushing them to keep pace or be overtaken. So the roadmap ships fast, and whether each feature actually makes the product better stops being a question anyone has time to ask.
This is product debt accumulating at the upstream flank. Not the technical debt of bad code, but the strategic debt of building without thinking, features shipping faster than judgment can keep up, and a product that becomes harder to describe as it grows.
Where the system is breaking: downstream
The downstream flank breaks with more visibility, because it breaks in the form of things that stop working.
Pull request review is the most obvious casualty. PRs have ballooned. According to the Opsera 2026 AI Coding Impact Benchmark, AI-generated pull requests take 4.6 times longer to review than human-written ones, and code duplication in those codebases rose from 10.5% to 13.5%. A Stack Overflow survey found that 66% of developers cite “AI solutions that are almost right, but not quite” as their top frustration. Review bots have emerged to fill the gap. But a bot checks whether code is technically valid. It does not ask whether this architecture matches the expectations in the rest of the codebase, whether this feature serves the users, or whether the thing technically passing review is actually doing what was intended. As agents open PRs, other agents review them, post comments, and get responded to by the original agent, the human presence in that loop becomes thin.
Testing is overwhelmed in the same way, and for a harder reason. Here is a moment from my own work that I have lived more times than I care to admit.
The feature was done. Every quality check was green. The unit tests passed, all of them, the coverage report glowing. The agent had written a clean summary of what it built, walked me through the logic, and told me with full confidence that the new flow worked end to end. So I opened it myself. I clicked the button. Nothing happened the way it was supposed to. The state never updated, the modal hung half-open, and the thing was, by any honest definition, completely broken. The agent did not know that. It could not know that. It had checked everything it knew how to check and concluded, reasonably, that it was finished.
That is not an edge case. LLMs are not good at what a careful human QA catches: cumulative layout shift, a UI that feels inconsistent with the rest of the product, the subtle wrongness that experienced eyes catch in seconds and Playwright cannot reliably detect. Tools exist to automate browser testing, but they are slow, and they miss what matters.
Regressions compound the problem. Coding agents are effective at making the specific task in front of them work. They do not reason well about blast radius. They do not trace how a change in one part of a system propagates into areas they were not looking at. A dedicated developer’s intuition about ripple effects is not something that has been replaced.
The quality erosion lands somewhere specific. A research paper analyzing roughly 302,000 commits (arXiv 2603.28592) found 484,366 AI-introduced issues across those commits, with 22.7% still surviving in the codebase at HEAD. A separate study found that AI-assisted developers scored 17% lower on code comprehension than developers working without AI tools (arXiv 2601.20245). One randomized controlled trial found that experienced developers using AI tools were 19% slower by measured output while reporting that they felt faster (METR, arXiv 2507.09089). From a security standpoint, Veracode’s 2025 GenAI Code Security Report found that 45% of AI-generated code samples introduced an OWASP Top 10 vulnerability.
That erosion is also changing what the code itself looks like, and what it means for the people who come after. I used to passionately craft React components by hand. They were composed, DRY, with clean utility functions, so the next person could build context fast and make changes safely. These days I rarely do more than glance at the code, focusing primarily on “does it work” and “does it meet my standards” and not “how does it work.” Now the code is not maintained by people. I do not care that a component runs to 2,000 lines, because I am not the one maintaining it, and an agent reads that file almost instantly and starts contributing. In a world where agents do the maintenance, writing for human maintainability is the wrong optimization. But that tradeoff creates a codebase that becomes harder for humans to navigate and increasingly dependent on the agents that can move through it at speed. The dependency is self-reinforcing. This is AI debt forming in real time: the codebase drifts toward agent-readability, humans grow less able to navigate it unaided, and the reliance deepens with every commit. Quality erodes in aggregate; the character of the codebase shifts beneath you.
Two debts, two flanks, one broken pipeline
We now have names for what is accumulating at each end.
Product debt is the upstream failure. Features that shipped before anyone asked whether they belonged. Roadmaps executed because execution was cheap, not because the ideas had been examined. A product that gains surface area while losing coherence. The judgment layer that used to gate what got built was never designed to scale with velocity, and we did not rebuild it when velocity arrived.
AI debt is the downstream failure. Code written for agents to maintain rather than humans. Less standardized, less clean, harder for a person to pick up cold. A growing organizational dependency on AI tools, the result of a codebase that has evolved past what a human can navigate efficiently alone, and one that will not stay cheap. The 3% of developers who highly trust AI output are not being paranoid. They have seen what the rest of us are accumulating.
Both debts have the same cause: the middle of the pipeline got fast, and the flanks did not.
The meter is running
Shipping at any cost turned out to have a literal price. The same companies that mandated “token maxing” are now capping it.
Uber capped AI-tool spending at $1,500 per developer per month; Bloomberg reported in June 2026 that power users had been burning between $500 and $2,000 a month. A JP Morgan analyst note circulating at the same time was titled “AI Bills Are Out of Control.” The mandate that opened the firehose was now generating a line item large enough to attract CFO attention.
The strange part is that the same technology is being sold at two very different prices. The personal plans developers learn on are heavily subsidized: SemiAnalysis found that a $200-a-month subscription returns thousands of dollars of tokens at retail rates, roughly $8,000 worth on Claude and $14,000 on OpenAI, with the vendor absorbing the difference. That subsidy is doing something larger than buying market share. It is conditioning a generation of developers to treat a level of token usage as normal at a price no one is actually paying. The enterprise bill is the other price, and it is the real one. It is metered per token, it is not subsidized, and it is where the appetite that felt free on a personal plan finally gets charged. Uber’s runaway line item was not a subsidy being clawed back. It was the true volume of agentic work, showing up on an invoice for the first time.
And the cheap price is a subsidy sitting on top of a cost that is physically rising. OpenAI’s CEO admitted in early 2025 that the company loses money even on its paying Pro subscribers, and the real cost lives in power and the hundreds of billions being spent on data centers to supply it, with global data-center electricity demand on track to double by 2030. Microsoft’s CEO now says the binding constraint is electricity, not chips: processors he cannot plug in. The per-token price does keep falling, but in an agentic workflow that is a trap. Adoption and token consumption are rising faster than prices are dropping, so total spend climbs even as each token gets cheaper. And the same fundamentals named here, vendors losing money on paying customers, hundreds of billions sunk into data centers, electricity as the binding constraint, make the next price cut something nobody can promise. The unit price falls for now, and the invoice grows anyway.
The bill is not only financial.
The human cost
One study of more than 500 developers found that after adopting AI tools they merged about a quarter more code and logged roughly a fifth more of their commits outside working hours. The shorter workday AI was supposed to buy has not shown up in the data. If anything the signal runs the other way.
Part of it is that the work no longer drains you the way hand-writing code did, so you go for hours without the old fatigue. Part of it is simpler: the productivity is addictive, and once you have felt it you want more.
But the deeper change is to the texture of the work itself. The craft used to be solitary, headphones on, one problem held in the mind until it gave way. That is gone. Now a developer is in five conversations at once, handing work to one agent while another waits, each one a tool that resembles a coworker but works at breakneck speed and never sleeps, some of them assistants that remember you and carry a semblance of a personality. The strangeness is in relating all day to something that behaves like a person and is not one. It is more productive and more fragmented. A different and stranger kind of tired. This is not one person’s experience. A Harvard Business School study of more than 187,000 developers, using a design that isolates cause from correlation, found that access to AI shifts developers toward working alone, with fewer human collaborators and the collaborative project-management work that used to fill the day falling by roughly a quarter. Google’s 2025 DORA report found the median developer now spends about two hours a day working with AI. The day is reorganizing around the model rather than the team. It is a fast and fundamental shift in how most developers have approached the work, and it is hard to adapt to, some managing it better than others. The constant context-switching, the near-absence of writing actual code, the all-day company of colleagues who are not colleagues, all of it is working on the psyche of everyone in the field, and we do not yet know how.
The Genie Is Out of the Bottle
The right response to a constraint moving is to find it and relieve it. We did that with code, and there is no undoing it. The direction is not reversible, and most of us would not reverse it if we could. I lament the old craft, the deep single-threaded focus of building a thing by hand, but I recognize I cannot go back to it.
That is the part the warning signs miss. The paradox from the start of this piece is the whole answer. The tool whose output we distrust is the one we will not put down. Desire ran ahead of trust and never waited for it to catch up. That is why there is no going back.
The upside is real, and it is not handed out evenly. The largest study yet of developers, more than 160,000 of them, found the productivity benefit landing mostly with senior engineers, while early-career developers, the ones leaning on AI most, saw no measurable benefit at all. The floor is rising, and the ceiling is rising faster. Effective use of these tools is turning out to be a skill of its own, and the gap between those who have it and those who do not is widening.
The difference comes down to one thing: whether you rebuild your work around the tools or bolt them onto the old way. AI is an amplifier. It makes a disciplined process faster and a sloppy one sloppier. The two debts in this piece are what accumulates when you do not adapt.
You Are the Bottleneck
For months I have run this experiment on myself. I treat myself as the bottleneck and optimize for that. I write almost no code. I spend the day on the parts of the process this article has been pointing at the whole time: deciding what is actually worth building, talking to users, reading the implementation and architecture plans the agents draft and pushing back on them, working through the manual test plans they prepare so I can still exercise my nuanced review of features and interactions. A fleet runs around me.
None of this work is new to me. I left engineering management a while ago, and I have ended up doing it again, this time for a fleet that never sleeps. Every skill I built leading people came back at once: reviewing work and giving feedback that holds, keeping the codebase documented so a newcomer can find footing, turning every mistake into a CI check or a doc so it cannot recur, reading an architectural plan and catching the cascade before it ships. The job is to direct the fleet and guard the judgment it cannot supply.
The return on the tokens behind my work runs to more than ten times what they cost. That is one data point, and I am one instance of the upside being real.
What the job becomes is this: a queue of decisions the fleet routes to you, an intent to clarify, a plan to approve, a tradeoff to arbitrate, a result to verify, a judgment call that passed every automated check and still needs a human. The agents do the volume; the person does the judgment, at both ends of the pipeline.
This was never an argument to go back. AI collapsed the middle of the pipeline and pushed the constraint out to both ends: deciding what is worth building, and proving we built what we intended. Those two stages were always where intent lived, and we treated them as overhead. The genie is out, and the hard part of the work moved with it, out to the ends of the pipeline where the judgment lives. You are the bottleneck now, and that is not a problem to solve. It is the job.
The bottleneck moved to judgment — at both ends of the pipeline. AppGenie is building the layer that helps you exercise it: structured intent, tested against what shipped.
Get Early AccessFree during development · No credit card required