Building fast. Learning slow.
Benny Andrén
Manifesto for AI-assisted software development
We have never built software faster. But we have never been less sure it was the right software to build.
It was 2001, and seventeen developers drove up a mountain in Utah to argue. They represented competing beliefs: Scrum, Extreme Programming or Crystal but everyone was convinced they had found a better way to build software. Outside, it was a ski resort. Inside, it was a reckoning. The industry was drowning in process, in thousand-page requirement documents, in projects that took years to deliver something nobody wanted anymore. These seventeen people knew it. They just hadn’t yet found the words to say it together. Snowbird was where those words converged.
With AI-assisted development, patterns are re-emerging. Browse any developer community right now and you will find a flood of posts about writing perfect specifications, designing detailed AI workflows, and optimizing prompts for maximum output. None of this is wrong. But something familiar is happening. Attention is drifting upstream, toward description and away from validation. The friction has moved, but the distance from the customer is starting to grow again.
Why Agile was necessary
Agile did not emerge because teams disliked planning. It emerged because they did not know enough at the outset.
Before Agile, processes like RUP and Waterfall followed a single long sequence: requirements, design, implementation, testing — and only then, real users. Months of work could pass before any assumption was tested in reality. Iteration was not part of the model.
Figure 1. The shift agile introduced. Further reading: The New Methodology — Martin Fowler
Agile changed the sequence. Not by removing planning, but by shortening the distance to real feedback. Working software shipped early and often became the mechanism for learning.
Working software became the primary measure of progress because it was the only reliable way to validate decisions in reality. Specifications, plans, and intentions were proxies. Before Agile, users existed at the beginning of the process, their needs captured, interpreted, and translated by business analysts, and then disappeared until the end. Agile brought them back, not through conversation, but through observation. Working software could be shown to real users, used in real contexts, misunderstood, criticized, and watched. What users did with software turned out to matter far more than what they said they wanted. Iteration existed to make that contact with reality happen earlier, allowing teams to test choices in practice rather than defend them in theory.
Working software became the primary measure of progress because it was the only reliable way to validate decisions in reality.
Agile optimized for learning under uncertainty. But when implementation stops being the bottleneck the conditions that made Agile necessary are changing.
The cost of building software is collapsing. Code that once took days to write can be generated in seconds, variations and rewrites are cheap and trivial. For developers this feels like a superpower. For leadership it creates a subtler problem. When you can ship more features faster than ever before, it becomes harder to stay focused on whether those features are actually solving anything. Output accelerates. The customer’s voice does not.
And yet the same force that risks drowning out the customer could bring them closer than ever. Prototyping is now cheap. Testing an idea with real users no longer requires weeks of preparation. You can put multiple versions of something in front of a customer in a single session, observe what they do, and change direction on the spot. We have never had tools this powerful for staying close to the people we are building for.
We are just not using them that way. Not yet.
Why fast iteration still matters — and where spec driven development misses it
Agile does not iterate for the sake of iteration. It iterates because working software is the primary measure of progress. Not software that compiles, not software that runs, but software that solves a real problem for a real user. That is the only validation that matters.
Spec Driven Development is a natural response to AI-assisted coding, and on the surface it feels not just efficient but rational. Invest in a detailed specification, feed it into an AI, let the system generate the implementation. Better prompts do produce better code. The feedback loop is real and it is rewarding.
But there is a concept worth keeping in mind: the cone of uncertainty. At the start of any project, when the least is known, uncertainty is at its highest. As we learn, it narrows. Specification does not narrow the cone. No matter how refined, it is still a description of reality, not a test of it.
Figure 2. The pipe vs the cone. Further reading: Henrik Kniberg, Scrum and XP from the Trenches
What changes with Spec Driven Development is the level at which validation happens. Instead of small, testable increments in front of real users, validation tends to happen against the specification itself. The software works. It matches the description. But whether the description was right remains untested. Incorrect assumptions become harder to isolate and correct. Not because the team is moving slowly, but because the feedback is too coarse to learn from. You are not moving through a cone. You are moving through a pipe.
A login flow shipped to ten users and observed tells you more than a complete authentication system built to specification. The first tests an assumption. The second assumes the assumptions were correct.
Toward AI native agility
If the bottleneck has shifted from production to cognition, what we optimize for must shift with it. Not by abandoning Agile, but by taking its original insight seriously in a new context. Learning is still the scarcest resource. The constraint has just moved.
This means the question changes. It is no longer “can we build this faster?” It is “are we building the right thing, and how quickly can we find out?” Those are different questions and they reward different behaviors.
In practice, this looks less like writing better specifications and more like putting rough things in front of real people sooner. A prototype that takes an afternoon to build and an hour to test with five users will tell you more than a week of refinement against a document. Not because the document is worthless, but because the user will do something you did not anticipate, and that moment is where the real learning happens. AI makes this cheaper than it has ever been. The same tools that accelerate implementation can accelerate validation, if we choose to use them that way.
It also means taking accountability seriously in a new way. When a developer wrote every line, the gap between intent and output was narrow. With AI-generated code, that gap can be large and invisible. The output looks correct. It may even be correct. But whether it solves the right problem, for the right person, in the right context, is a judgment that no model can make. That judgment belongs to the people building the product, and it requires contact with reality to exercise well.
If history is a guide, new practices are already forming in the gaps. In teams that have noticed the drift. In developers who feel the unease of shipping fast without knowing why. Fragmented, as they always are at first. Scrum, Extreme Programming, Crystal — none of them waited for permission. They emerged from practitioners who recognized a constraint that the prevailing wisdom had stopped addressing.
The academic community is already moving. In 2023, thirty-five researchers gathered in Copenhagen and produced their own manifesto for human-centered AI in software engineering. The instinct is right. But the constraint practitioners are facing on the ground is more specific.
When enough of those practices have proven themselves, it will be time to converge. To find the common voice. To gather.
Until then, someone has to go first.
The manifesto below is a first attempt to name what that shift looks like. Not a framework, not a methodology. A set of values to orient around while the practices are still forming.
Manifesto for AI-assisted software development
(A first iteration, shared early to invite feedback.)
We value problem framing over solution generation.
We value validated learning over accelerated output.
We value observed behavior over specification.While there is value in specification, planning, and automation, we recognize that in an AI-driven world, validated learning is the scarcest resource.
It is time to drive up that mountain again
Twenty years ago we learned that optimizing for output while losing sight of the user is not progress, it is just faster failure. Spec Driven Development is a rational response to AI-assisted coding, but rationality is not the same as wisdom.
Photo by Daniel Shapiro on Unsplash
We are at risk of learning the same lesson twice. The tools may have changed but the temptation stays the same. When implementation gets cheaper, the pull toward abstraction gets stronger. More process, more specification, more confidence in the description and less contact with reality. We have been here before.
The Agile movement did not emerge from theory. It emerged from practitioners who recognized a constraint that the prevailing wisdom had stopped addressing. They did not wait for consensus. They gathered, aligned around what actually mattered, and pushed.
The bottleneck has shifted and the principles should follow. I am not waiting for consensus. Neither should you.
