In February 2001, seventeen software developers gathered at the Snowbird ski resort in the Wasatch Mountains of Utah and wrote a short document that would reshape how the industry thought about building software. In February 2026, Thoughtworks hosted a workshop called “The Future of Software Development” in Deer Valley, a few miles from where the manifesto was written. The geographic callback is deliberate. Martin Fowler, one of the original signatories and the host of that bliki post, describes it as a forward-looking event rather than a retrospective. That distinction matters.
The Agile Manifesto succeeded partly because it was short. Four value statements, twelve principles, and a collective signature from people whose opinions the industry respected. It did not describe a methodology. It described a posture toward uncertainty: prefer working software over documentation, people over processes, responding to change over following a plan. The manifesto’s genius was that it could be wrong in the details and still be right in aggregate. Teams that internalized the values got better outcomes than teams that followed waterfall to the letter, even when the agile teams were doing agile badly.
Twenty-five years later, the values hold up less cleanly. Not because they were wrong, but because the context that made them meaningful has shifted underneath them.
What the Manifesto Assumed
The manifesto was written against a specific failure mode: large organizations building software through long planning cycles, extensive upfront documentation, and handoff-heavy processes that separated people who understood the problem from people who wrote the code. The waste was coordination waste. You could get enormous gains just by putting the business and the developers in the same room and letting them talk directly.
The manifesto assumed that the hard part was communication between humans, and that the artifact produced by that communication was code written by those humans. Both assumptions were reasonable in 2001. They are less universal in 2026.
AI coding tools have changed the cost structure of software production significantly. GitHub Copilot, Claude, and their successors can generate working code from natural language descriptions with a fidelity that would have seemed implausible even five years ago. The bottleneck is no longer typing speed or even raw implementation skill for a large category of tasks. Teams using these tools report throughput increases that are real, measurable, and not evenly distributed across task types. Greenfield CRUD applications, boilerplate-heavy integrations, and mechanical refactoring compress dramatically. Complex system design, subtle correctness requirements, and novel algorithms do not compress at the same rate.
This creates a problem for a framework built around the assumption that the hard part is coordination. If you double or triple the rate at which working code gets produced, you have not necessarily improved anything. You have moved the bottleneck. The queue that was backed up at implementation now backs up somewhere else: code review, integration testing, deployment, monitoring, actually understanding what got built.
The Agile Values Under New Conditions
Take the first value: individuals and interactions over processes and tools. This was a pointed critique of organizations that had buried their engineers under process theater, approval chains, and status meetings while actual software problems went unsolved. The corrective was right. But “tools” in 2001 meant IDEs, issue trackers, and heavyweight CASE tools. The tools in 2026 include autonomous agents that can interpret a ticket, write the code, run the tests, and open a pull request without a human touching a keyboard.
The manifesto’s framing does not obviously apply here. An AI coding agent is not an individual in the manifesto’s sense, but it is not merely a tool either. It occupies a category the manifesto did not anticipate: something that participates in the production of software but whose judgment cannot be trusted the way a skilled engineer’s judgment can be trusted. Managing that participation requires a kind of oversight that looks more like process than the manifesto’s authors would have endorsed.
The second value, working software over comprehensive documentation, has gotten more complicated in a similar way. The argument against documentation was that it went stale, consumed time that could be spent building, and gave false confidence. All true. But large language models are context-sensitive tools. They work better with more context. Teams are discovering that the better their specifications, their architectural decision records, and their inline documentation, the better their AI-assisted output. The code review discipline of writing down why a decision was made, not just what was decided, has measurable value when AI tools need to extend that code six months later.
This is not a refutation of the manifesto’s values. Documentation for documentation’s sake is still waste. But the trade-off has shifted. The cost of not documenting has gone up in a world where AI tools need to understand your codebase to help you with it.
What Forward-Looking Looks Like
The Deer Valley workshop’s forward orientation is the right posture. The software industry has a tendency to either idealize its past frameworks or discard them entirely, and both responses are usually wrong. The Agile Manifesto’s values came from observing real failure modes in real organizations. Those failure modes have not disappeared. Large organizations still bury engineers under process theater. Coordination waste is still real. The pull request review queue is still a bottleneck at most companies that have not deliberately addressed it.
But new failure modes have appeared alongside the old ones. Teams that automate their way to high throughput without investing in the judgment to evaluate what they are producing create a different kind of waste: software that works in demos but fails in production, codebases that grow faster than anyone can understand them, and technical debt accumulated at a rate that reflects the speed of generation rather than the speed of comprehension.
The engineers who navigated the agile transition well in the 2000s were the ones who took the values seriously rather than adopting the ceremonies. They asked what the daily standup was actually for, rather than standing up for fifteen minutes because Scrum said to. The engineers who will navigate the AI transition well are probably the ones asking the same kind of question now: what is code review actually for, what is the real function of a sprint, what does “working software” mean when you cannot read all the software you are shipping.
Kent Beck, another of the original manifesto signatories, has written recently about how AI changes the economics of software in ways that require revisiting fundamental assumptions about how work is structured. His framing, roughly, is that the 3x engineer is now table stakes and the interesting question is what engineers do with the capacity they have recovered. The answer is not obviously “write more software faster.” It might be “understand systems more deeply” or “reduce the surface area of what gets built” or “spend more time on the parts that AI handles poorly.”
The Longer View
The Agile Manifesto’s influence peaked and declined in a predictable way. The values spread. The ceremonies calcified. SAFe and its relatives turned a manifesto about reducing process overhead into elaborate process frameworks. The signatories spent years distinguishing what they meant from what was being done in their name.
That cycle will probably repeat with AI-assisted development. The genuine insights, whatever comes out of workshops like the one in Deer Valley, will get encoded into tools and processes and certifications that lose the thread. The useful signal will be in the values underneath, not the practices on top.
What those values should be is genuinely unclear, which is what makes the question interesting. The 2001 manifesto had a clear enemy: heavyweight process that prioritized documentation over delivery. The enemy in 2026 is less legible. It might be speed without judgment, or automation without understanding, or throughput metrics that measure the wrong thing. Identifying it clearly enough to write four value statements about it is hard work.
The fact that people are gathering in Utah’s mountains to try is not nothing.