Kent Beck, the person who gave us Extreme Programming and popularised Test-Driven Development, wrote in April 2023:
90% of my skills just went to zero dollars. 10% of my skills just went up 1000x.
In a 2025 interview with Gergely Orosz, he expanded on what that 10% looks like: vision, milestones, design, and controlling complexity rather than remembering language syntax.
If you’ve been paying attention, you already know what the 90% is. And if you haven’t, well, this chapter is for you.
The $350K Weekend Project
Paul Ford, former CEO of Postlight and one of the sharpest observers of the technology industry, described what happened when Anthropic gave Pro plan subscribers $1,000 in free Claude Code credits in November 2025. Ford, a self-described “reasonably effective coder and horrific dilettante”, set out to burn $100 a day on side projects that had been sitting in folders for a decade.
Ford can put real numbers on this because he spent years as a professional software cost estimator. He knows exactly what things cost to build. Claude Code itself would estimate project costs and those estimates were, in Ford’s words, “extremely on the nose — for 2022.” But in 2025, one can type “do all of that; sounds like a bargain” and it gets done in fifteen minutes for maybe 50 cents.
Over the weekend, he ported his old blog from a custom, “incredibly obscure, disturbing data format” he first created in 1999 to a tidy new CMS. He built a timeline visualisation project with a new TypeScript frontend and backend. He created a functional clone of OwnCast. Total spend: about $150.
Ford’s description of the experience is worth lingering on: “Programming in Claude Code is like playing with a Tamagotchi, if a Tamagotchi was a forty-person engineering and product team, and instead of producing little digital poops, it could instead deploy database-backed web applications with type-safe API interfaces and React frontends.”
At 2021 retail rates, the dataset conversion alone would have been $350,000: a product manager, a designer, two engineers including one senior, four to six months of design, coding, and testing, plus maintenance. Ford himself, on weekends and evenings, for the price of leftover promotional credits.
This is not a general productivity benchmark. It is one experienced person’s account of doing work that he estimated would previously have required a small team and several months.
The Constraint That Shaped Everything
Developer time has long made code expensive. That constraint shaped many of the habits and institutions in our industry.
The cost of developer time is why we estimate stories and prioritise work in a backlog. It is also why a team may spend longer debating a refactor or a debug interface than building either one: choosing one piece of work has meant declining another.
Planning, estimation, feature prioritisation and the various forms of review all developed around the assumption that writing code is the expensive part.
Coding agents just dropped the cost of that part through the floor.
In his September 2025 essay “Programming Deflation”, Beck explored what happens when the cost of code production drops continuously. His conclusion isn’t that we’ll need fewer programmers; it’s that cheaper code surfaces latent demand. There are millions of problems nobody bothered solving because the cost of a software solution exceeded the value. When code costs plummet, those problems become worth solving. The total amount of software in the world goes up, not down.
Simon Willison, creator of Datasette and one of the most thoughtful practitioners writing about AI-assisted development, captures this shift in his Agentic Engineering Patterns guide. His heuristic is simple: when your instinct says “don’t build that, it’s not worth the time,” try an asynchronous agent session and inspect the result later.
That heuristic only makes sense once the cost of trying has fallen substantially.
What “Good Code” Still Costs
Before anyone accuses me of suggesting that quality doesn’t matter: it does. More than ever, in fact.
Willison defines “good code” as code that works, that we know it works, that solves the right problem, handles errors gracefully, is simple and minimal, protected by tests, documented appropriately, affords future changes, and meets the relevant “-ilities”: accessibility, testability, reliability, security, maintainability, observability, scalability, usability.
Agent tools can help with most of that list. But there remains a substantial burden on the developer to ensure the produced code is actually good. The stochastic nature of LLMs means you can’t just trust the output. The word “stochastic” matters here: it means the same input can produce different outputs each time. A test that passes doesn’t mean it’s a good test. Code that compiles doesn’t mean it’s correct.
This is, paradoxically, what makes LLMs so powerful for coding compared to other domains. Compilers can reject invalid programs, test suites can exercise expected behaviour, and type systems, linters and static analysis give us further ways to challenge the output. Software has verification tools that most other domains lack.
But verification requires knowing what “correct” looks like. And that’s where the 10% that went up 1000x lives.
Google’s 2024 DORA report found that a 25% increase in AI adoption was associated with a 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability. It also found that 39% of respondents had little or no trust in AI-generated code. These are associations rather than proof of one cause, but they are a useful warning: feeling faster is not the same as improving delivery.
The Nail Gun Analogy
AI is a nail gun. In the hands of someone unskilled, it’s dangerous. In the hands of a professional, it speeds them up enormously. And in the end, all anyone cares about is that a nail exists in that location.
You may feel this is a simplification. I’d argue it’s more accurate than you might expect.
The user doesn’t care about your SonarQube stats. They don’t care whether you used functional or object-oriented style, whether the architecture is hexagonal or layered, whether you chose Rust or TypeScript. They care that the app does what it says, that it’s fast enough, that it doesn’t lose their data, and that it’s available when they need it.
Of course, there’s a big risk here. If you don’t verify progress, if you just let an agent generate code without understanding what it’s producing, you may end up with a blob of slop that sinks under its own weight. We’ve all read the horror stories. That’s why this isn’t just about tools. It’s about systems.
The System Is the Asset
Look at systems that have survived for a long time because they worked. What endured was not the implementation details. What endured was well-understood behaviour and a clear sense of what must not break.
A more tangible example: consider a marketplace for C2C sales. What is the system? It’s not the language, the microservices, or the deployment topology. The durable parts are its SLA for latency and availability; the audit trails, accounts and transaction records; the contracts at its boundaries; and invariants such as one bid per item per user or a maximum number of items on sale.
If you have all of that defined in detail, you could recreate the system over and over. Different tools, different architectures, different teams, different agents. And the user wouldn’t notice.
I can hear the counterpoint already: waterfall showed us that we clearly miss invariants and details, that business evolves and we need to update these system definitions constantly. I’m not advocating doing it just once, perfectly. That has never worked and never will.
But I am advocating for focusing on system definition as the primary engineering activity. If your code complies with the contracts, passes the tests, meets the SLAs, does it matter if it’s code you’d write yourself?
This bridges naturally to observability. More and more, we’re moving toward systems that are debugged in production. A system with stable contracts, strong evaluations, continuous monitoring, and clear rollback paths can safely tolerate many changes, with less human supervision, at bigger scale. That’s the challenge of the new era.
Which, of course, in a sector where companies have been trying to “be agile” and failing (or adopting SAFe) for 25 years, means there’s going to be a lot of pain in the near future.
The Mindset Shift
The skill set needed to use AI agents well turns out to be a mixture of product manager and development team manager. You need to know what to build, why it matters, what “done” looks like, and how to verify the result. Declarative development, “here’s what I want and how we’ll know it works”, can beat imperative micromanagement when the constraints are strong enough.
Developers who micromanage every agent action risk becoming the bottleneck. Those who learn to specify, verify, and iterate are better placed to benefit. Beck’s percentages are rhetorical, but the distinction is useful: judgement and verification become more valuable as typing becomes cheaper.
Ford captured the emotional complexity of this moment perfectly: “All of the people I love hate this stuff, and all the people I hate love it.” The social friction is real. Developers adopting AI tools often face pushback from within their professional communities. It adds a psychological layer to what is fundamentally an economic shift.
But this is not only about AI enthusiasm or scepticism. It is also about industrialisation. Organisations that make production cheaper can redirect effort into quality, distribution, or entirely new work; they can also produce defects faster. If your business depends on software, you need to understand both sides of that change.
Even after the current hype cycle ends, local and hosted coding models will remain useful. Their future cost and capability are not guaranteed, but the constraint has already shifted enough to change how I work.
Code may be cheaper. Defining the right system, and proving that it behaves as intended, has not become cheap.