Development is becoming free. What will you build?

For most of the history of software, the expensive part was the construction itself, turning an intent into working code that holds together. Deciding what to build, and judging whether the result was any good, were the cheap parts by comparison. That cost is now collapsing, and it is further along than the argument about AI coding tools suggests.

That argument is still stuck on whether a model can write good code. Sometimes it can and sometimes it cannot, which was the interesting question while these tools were party tricks. Their usefulness turns on continuity instead: whether a workflow holds together across a long piece of work, or collapses into regressions, rewrites, and the point at which a developer gives up and does it by hand. Earlier models failed on continuity, and they failed in a particular way. They would make progress and then quietly break something that already worked, forget a decision from minutes earlier, or fix a bug by undoing a constraint set the day before. They were useful only under constant supervision, which turns delegation into a new kind of management.

That capability is what has changed, and the change is measurable. METR has tracked the length of task a frontier agent can complete unattended at even odds, and found it doubling roughly every seven months for six years, with the doubling nearer four months across the last two.1 What the trend measures is duration: how long a system can carry a piece of work before it loses the thread.

In practice this no longer looks like a toy demo. I left an agent running on a build of my own, a game in Godot whose first milestone was a rendering pipeline built on 3D signed distance fields, with the gameplay stacked on top. Anyone who has done shader work knows how fast that collapses, into black screens, wrong coordinate spaces, distance functions that look right until movement warps them, frame jitter when timing and state fall out of step. It ran unattended through twenty milestones, checking its own work as it went: a gradient to confirm the coordinate system, a known primitive to confirm the distance function and camera, a screenshot to confirm the right thing was in the right place. By the end, the build did what its specification described.

“Complete” here is narrower than bulletproof. The build was validated the way a product milestone is, by running the checks, playing it, and confirming the promised behaviours were present and coherent. This was not adversarial testing or an edge-case hunt. The test was whether an autonomous agent could take a moderately complex specification and deliver it across many milestones without supervision. On this evidence, it can.

It also exposed a boundary. The feel of the thing, its timing and difficulty, was wrong, and that is not a defect in the agent. It is the line between two kinds of work. Correctness can be specified and checked, so an agent can drive towards it. Feel cannot, because feel is a matter of taste and feedback: someone has to play the thing and decide what “better” would be.

None of this came from prompt engineering, which is the wrong mental model now. It came from a disciplined process that most engineers would recognise at once: a specification broken into milestones, explicit constraints on architecture and safety, a definition of done with a way to prove it. This is how a competent engineering team already runs, work decomposed into tickets with acceptance criteria, the hard decisions forced up front, nothing accepted until it passes its checks.

The decomposition does much of the work, because it keeps each step local: one milestone, one definition of done, one path to verifying it, which holds drift and accidental rewrites in check. Continuity lets the work run; constraints keep it from wandering; verification makes “done” demonstrable. The method is the one good teams already use; what changed is that the worker following it no longer has to be a person. The model underneath matters less than the discipline around it.

When construction stops being the bottleneck, the bottleneck moves to intent: working out what is worth building, specifying it precisely enough to be built, and proving that what comes back is what was asked for. For senior engineers the change moves where the value sits. The reflex question, whether this replaces developers, is a dead end. Value moves towards the work good seniors already do: turning needs into buildable specifications, setting constraints that prevent drift and unsafe behaviour, designing the validation that makes “done” provable, and reading output the way a maintainer does, alert to the gap between plausible and correct. The work that survives is the judgement.

The limits are real, and the same benchmarks that show the gains show them. Leading agents now resolve more than three-quarters of SWE-bench Verified, a set drawn from real GitHub issues, while on a harder and less familiar set the best scores fall to about a quarter, and developer trust in the output has slipped even as use has climbed.2 Agents stay weak on long-term maintenance judgement and unreliable on security and performance without expert review. Turned loose inside a mature production codebase they are dangerous, because the binding constraints there live outside the repository, in integrations, old compromises, organisational memory, and the edge cases nobody remembers until they break. Fast output becomes fast damage when it is not bounded.

The cost of the construction itself is falling at a rate with no real precedent, by some measures tenfold a year for a given level of capability.3 As it approaches zero, the constraint left standing is the one the agent could not supply: knowing what is worth building, and recognising what “better” would be once it exists. That judgement is not getting cheaper. The question stops being whether the machine can build it, and becomes what is worth building at all.

---

References

1. METR, “Measuring AI Ability to Complete Long Tasks” (19 March 2025). On a suite of 170 software, cybersecurity and reasoning tasks, the length of task a frontier agent can complete autonomously at 50% reliability has doubled roughly every seven months over six years, with the doubling nearer four months across 2024 to 2025. https://metr.org/blog/2025-03-19-measuring-ai-ability-to-complete-long-tasks/ ↩

2. Capability and its limits. Leading systems now resolve over three-quarters of SWE-bench Verified, a 500-problem set built from real GitHub issues (top agentic scores around 77%, higher across multiple attempts). On SWE-Bench Pro, a harder and less familiar set, the best scores fall to roughly a quarter. Adoption is near-universal: about 84% of developers use or plan to use AI tools in Stack Overflow’s 2025 survey, and GitHub reports its assistant writing close to half the code of active users, even as positive sentiment has slipped and 45% cite debugging AI-generated code as a real cost. https://llm-stats.com/benchmarks/swe-bench-verified-(agentic-coding) ; https://labs.scale.com/leaderboard/swe_bench_pro_public ; https://survey.stackoverflow.co/2025/ai/ ↩

3. The cost of a given level of AI capability has been falling fast. Andreessen Horowitz puts it at roughly tenfold a year over three years for models of equivalent performance (“LLMflation”). Epoch AI, measuring the price of a fixed benchmark score, finds declines of about five to ten times a year for frontier capability, steeper on some tasks. The exact multiple is disputed; the direction is not. https://a16z.com/llmflation-llm-inference-cost/ ; https://epoch.ai/data-insights/llm-inference-price-trends ↩