David Heinemeier Hansson has argued that writing code by hand is becoming economically irrational for a large part of software development. At the Rails World keynote in Austin on September 23, he said that over roughly 21 years he averaged about 30,000 lines of production Ruby a year, and that in August he produced about 150,000 lines in a single month using AI agents. His old pace works out to about 2,500 lines a month, so the jump is roughly sixty-fold. He acknowledged that much of the new code is verbose Rust that he lets agents write in ways he would never accept in his own Ruby, so the figure is a poor measure of productivity, as lines of code always have been. What it does show is that the economics of producing software have changed, and that is the part worth arguing about.
For most of the history of the industry, implementation capacity was the constraint. Companies always had more features, integrations, fixes and internal tools than their engineers could build, and that shortage shaped roadmaps, budgets, hiring and which ideas were worth discussing at all. If agents loosen it, more software will get built, because a large part of the cost that forced prioritization has fallen away.
That is the pattern I wrote about in Migrating Scarcity. When technology makes one part of a system abundant, the constraint moves to whatever has to absorb the abundance. In software, the first pressure lands on testing, security, review and architecture. A team that produces many more changes does not become equally better at understanding how those changes interact with years of accumulated assumptions, dependencies and workarounds. A new service can do exactly what it was designed to do and still leave the company with a dependency to run for years, a generated test suite can pass while encoding the wrong assumptions, and individually reasonable decisions can add up to an architecture nobody chose.
Verification will not stay the bottleneck for long. The models that generate code will get better at reviewing it, writing tests, tracing dependencies and watching production, because that work sits on the same improvement curve as the technology that created the need. What remains is harder to reduce to another model call. Someone has to decide how much authority the system has, where that authority ends, which consequences the organization will accept, and who can intervene when the system is doing exactly what it was built to do and producing an outcome nobody wants. Those questions concern who makes a decision and who carries the consequences, and a better bug-spotter does not answer them.
Knight Capital is a useful case, although it proves nothing about the volume of AI-generated change. In 2012, long before generative AI, a faulty deployment led the firm’s automated router to send millions of orders into the market over about 45 minutes, and the SEC put the resulting loss at more than $460 million. The failures the SEC found concerned authority as much as code. No second person was required to review the deployment, and an internal system produced 97 automated emails about the error before the market opened that were never designed as alerts and were not acted on. The firm also had no procedures for halting the router in response to its own aberrant activity or for deciding when to disconnect a malfunctioning system, and when engineers tried to fix the problem live, uninstalling the new code from the seven correct servers made it worse. The episode shows software acting faster than the organization around it could understand and stop it, and coding agents widen that gap.
Once an agent can write, test, review and prepare a change, the temptation is to require a human approval for every one, which recreates the coding bottleneck at the approval desk. The opposite extreme is no better, since a change to payment authorization or identity management is not the same as a change to a page layout. I call the answer Offensive Permission Architecture: define the blast radius, pre-authorize the actions that can safely be delegated, and make the activity auditable. In practice that means deciding in advance which classes of change an agent can make alone, how much damage is acceptable, what evidence is required before a change moves into a higher-risk environment, and who holds standing authority to stop it. Standing matters because the middle of an incident is the worst time to negotiate who may shut something down. Whether agents may ship unattended into regulated data or safety-critical code is a different kind of decision, hard to reverse and revealing about what the company will answer for, and it belongs with the people who own that accountability.
Cheap implementation also changes what gets built. Cost has always been a crude form of architectural discipline: when a new service takes a team three months, someone asks whether it deserves to exist, and when it takes an afternoon that question is easy to skip. The build cost looks trivial while the operating cost spreads across future years and across people who were not in the room. Each local decision gets cheaper while the whole system gets more expensive to understand, and this happens even with perfectly competent code, because every decision was defensible when it was made.
DHH is an unusual case against which to test all of this. He created Rails and has spent decades forming views on what good architecture looks like, so when an agent proposes an abstraction he is not meeting it as a beginner. His ability to stop writing code depends partly on experience accumulated while writing a great deal of it. The likelier reading of his results is that AI has given someone with a lot of judgment far more implementation capacity, which differs from replacing the judgment, and companies should be careful about treating his output as evidence that experienced engineers matter less.
That makes the talent question awkward. Experienced engineers learned by debugging failures they did not expect, watching elegant designs age badly, running systems under load and owning decisions whose consequences appeared years later, and some of that learning came from routine implementation work that agents now handle. Preserving manual coding for its own sake would make little sense, so the task is to preserve the learning without preserving the obsolete work.
A junior sitting beside a senior who holds all the authority does not acquire it. What works is bounded ownership of the boundaries themselves: a junior proposes what counts as a low-risk class of change an agent may make alone, defends the proposal to a senior who reviews the reasoning instead of redoing the work, and revises it after an incident. They can shadow the engineer with stop authority during a rollout and later exercise that authority in a controlled environment, own a section of a postmortem, or rotate through operations and diagnose a live problem before being shown the answer.
Line-by-line inspection is a poor skill to train, since review agents will get very good at it. The skill worth building is framing the decision around the code: what could interact badly with something outside the change, when the evidence is too thin, which consequence justifies a stop, and whether the system is growing more complicated for a reason anyone can still explain.
Companies can adopt agents much faster than they can redesign those responsibilities. Buying a tool can take a quarter, while changing who owns architecture, what teams may ship, how incidents are handled and how junior engineers gain judgment usually takes much longer. I call this lag Organizational Rewiring Latency. It matters because the productivity gains arrive first, and the organization gets the capacity before it has rebuilt itself to handle it.
By the end of 2029, I expect a visible difference between teams that used coding agents to increase output and teams that changed the operating model around them. The second kind will have clearer authority boundaries, named architectural ownership, explicit stop rights and deliberate ways for junior engineers to build judgment. The fair test is inside a single company, because well-run firms tend to do both things and a comparison across firms would mostly measure management quality. Take teams that got the same tools at roughly the same time and compare serious incidents relative to how much they change, along with how quickly they recover, using change-failure data and postmortems. If the teams that rebuilt their operating model don’t do better, this argument deserves to be questioned.
Migrating Scarcity is available here.
