Writing/Producing code was never the bottleneck
13 Oct 2026
Loading...
61.2970°N 23.5025°E
© Sami Surakka 2026
The 10× promise reminds me of the cake in Portal. Product and engineering leaders are the ones being handed it, and they still have to decide what to build, who it is for, and how it reaches users without putting the business at risk.
Justin Reock’s State of AI in Software Development draws on DX data from 400+ organisations and about 200,000 engineers, from November 2024 into February 2026. Weighted pull-request throughput rose by a median of about 8%, and about 13% on average. Engineers’ felt rate of delivery rose only about 4–5% over a year. No organisation in that set doubled, and none reached 5× or 10×. The question he hears back is “We spent $10M on tokens, where is the 10x productivity?”
Code generation is about 14–16% of the value stream. Even perfectly accurate, instant code would only be working on that slice. Reock’s line is “An hour saved on something that isn’t the bottleneck is worthless.”
On the quality side, perceived maintainability ticked up by about 4%. Change confidence fell by about 6%. Median pull requests grew from roughly 44 lines to 72. People can modify the code in front of them more easily, and they trust the result less. Larger changes are harder to review and harder to undo.
In Software Fundamentals Matter More Than Ever, Matt Pocock says “bad code is the most expensive it’s ever been.” A first pass is cheap. Living with the wrong structure still costs the team. If tests, types, and review are slow, the model gets ahead of what you can check: “The rate of feedback is your speed limit.” Pocock cites Kent Beck on investing in the design of the system every day.
The time goes into a familiar set of decisions, and they did not get easier: what to build, what is valuable for the business and the user, in which order, when and to whom to roll it out, how, when to roll it back, when to remove a feature, how to tell people it changed, and how to know it had the effect we claimed.
I have written about pieces of that set already. Taking developers on UX field trips is the ongoing conversation with the people in the work, which is still how you find out which pain is real. Part 1: Deployment is not a release and Part 2: AI made deploys faster. It didn’t make releases happen are the rollout half: who is live, who can explain the change, and why a mature product cannot have its surface moved every afternoon. An early product can shift harder, because habits are still thin and users expect movement. An established one has workflows, training, and tickets built on what you already shipped.
The first step of an SDLC that can survive this is the machine that builds the product. Continuous integration, continuous delivery, a design system people actually use, test automation, a way to expose a change to a small cohort, a way to roll it back, and a way to see what happened. Reock’s readiness list is close to that: clear documentation, modular code, fast local and CI feedback, a test suite that is not flaky. Pocock’s speed limit is the same constraint, stated as feedback rate.
In Design systems used to take months I wrote that the scaffolding collapsed and the slow work did not. Adoption, governance, tokens, a system that outlasts the person who started it. Those were the investments teams postponed because starting them looked like a programme. Agents make the postponement expensive. A model will add surface to a codebase that cannot be reviewed, tested, or rolled back. The practices were a way to avoid spending the next month on a failure you could have seen coming. They are now also how you avoid putting that failure in front of every user on the same day.
The risks have ordinary price tags: a vulnerability merged by accident, client data you were supposed to hold, a checkout that stops taking payment. Some of those end a company. AI makes more experiments affordable. The experiment still needs a boundary: a small slice of users, an easy rollback, and enough observation to learn whether the change did what you thought. If the SDLC cannot contain the change, a higher authoring speed shortens the time to the incident.
I do get more done in less time. That part of the pitch matches my week, and it was true at Cambri. If you’re interested in the case study, read it here. The caveat is that I am tracking more threads and making more decisions per day. The cognitive load went up. Pocock treats the load inside the code as a design problem: a simple interface, the human on the boundary, the model in the interior. The same load shows up one level higher, in the product decisions. If the supporting systems are missing, whether the week lands well is mostly luck.
When the machine is there, the extra speed is available for those product questions.
Brandon Thomas’s Artcraft suite is a challenge I welcome. It is a set of seven open-source apps aimed at Photoshop, Illustrator, Premiere, Lightroom, After Effects, InDesign, and Acrobat, built with Claude in Rust and released under MIT and Apache licences. Ars Technica describes them as “ambitious, free, and nowhere near finished.” Thomas has called the work a super early alpha. He first said feature parity would take a month, then that the last percent would be measured in months rather than years.
I have wanted small, autonomous, cross-functional teams for a long time, and teams that size have been able to challenge large companies for just as long. AI makes it cheaper to put that challenge in public, quirky legacy products included. Thomas’s own description still holds: this suite is an alpha. What we make of it depends on the attempt staying aimed at a pain someone actually has, and on the team being able to ship it and learn whether it worked.
I want the extra speed pointed at a pain I have actually seen, with a release I can roll back, and with enough observation to know whether it worked. The question that stays is the one that was already the job: what we should build next, and for whom.