I've been spending a lot of time thinking about where all the recent advancements in AI are going to take the software industry.

Not just what AI coding agents mean for developers today, or how much faster we can write code, but what happens when these capabilities fundamentally change the economics of building software.

Over the last few months, I've written about several aspects of this transformation:

Each article explores a different part of the same transformation. Together, they've led me to a bigger question.

If AI agents fundamentally change how we build software, should we reconsider the principles that guide how we develop it?

I think the answer is yes.

And I thought it would be interesting to start a conversation about what the Agile Manifesto might look like today, in a world where AI agents are becoming increasingly capable of building software autonomously.

This is an attempt to start that conversation. It's not a declaration that I've figured everything out, and it's certainly not an argument that everything Agile taught us is suddenly wrong.

Quite the opposite. I think many of the original Agile values remain as relevant as ever. But the context in which we apply them is changing.

Why revisit the Agile Manifesto?

The Agile Manifesto was written in 2001, when software development was a very different activity.

Its authors challenged heavyweight processes, excessive documentation, rigid plans, and organisational structures that often got in the way of delivering working software.

They established four values:

Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.

These values helped shape how an entire generation of engineers and organisations approached software development.

But consider what happens when AI agents can implement features, modify existing systems, generate tests, refactor code, and work across entire codebases with increasingly little human intervention.

The bottleneck starts to move.

Writing code becomes cheaper. Producing multiple implementations becomes easier. Experimenting with different approaches becomes more affordable.

But we still need to know whether the software does what we intended, whether it introduces vulnerabilities, whether it behaves correctly in production, and whether it actually solves the customer's problem.

In many cases, the harder problem is no longer producing a solution. It's establishing that the solution is worth trusting.

When code gets cheap, verification becomes expensive.

This is not simply a tooling change. It has consequences for team structures, software architecture, engineering practices, product discovery, and the economics of custom software.

If we can produce software at a rate that exceeds our ability to verify and maintain it, then increasing development capacity alone will not solve our problems.

We need to rethink the system in which software is produced.

From Agile to Agentic

I don't think the answer is to discard Agile and replace it with a methodology that prescribes how to use AI coding agents.

That would miss the point.

The more interesting question is whether the underlying values and principles of software development should evolve to reflect this new reality.

Here are some of the shifts I believe deserve our attention.

1. From producing software to verifying outcomes

Working software was a major improvement over plans and documents as a measure of progress.

But in an agentic world, generating working code is becoming easier. Even passing tests does not necessarily mean we've built the right thing.

We need to focus on verified outcomes: software that demonstrably satisfies its requirements, behaves within its intended constraints, and delivers value to customers.

2. From implicit assumptions to explicit intent

AI agents can operate with considerable autonomy, but they need to understand what they are trying to achieve and what they must not do.

Constraints, specifications, architectural boundaries, acceptance criteria, and executable policies become increasingly valuable because they make intent easier to interpret and verify.

Explicitness isn't the ultimate goal. It's a means of achieving more reliable outcomes while enabling greater autonomy.

3. From supervising implementation to designing autonomous systems

When humans perform most implementation work, we organise teams around people writing, reviewing, and integrating code.

When agents can do much of that work, we need to think differently about the development system itself.

How much autonomy can we safely support? Which decisions require human judgment? Where should verification happen? How do we prevent failures from propagating?

The goal should not be to remove humans from software development. It should be to use human judgment, creativity, and ownership where they matter most.

We may end up with fewer engineers who can accomplish significantly more, but also carry greater responsibility for the systems they create and operate.

4. From optimising implementation to optimising the whole system

The Toyota Production System offers a useful perspective here.

Improving the productivity of an individual step does not necessarily improve the performance of the entire system.

If agents produce code ten times faster but verification, integration, and maintenance remain unchanged, we may simply create a larger queue of work waiting for those activities.

We need to optimise the flow of verified value, not the volume of code generated.

With these ideas in mind, I started wondering what a new manifesto might look like.

The Agentic Manifesto

We are uncovering better ways of developing software by building with intelligent agents and learning from the systems in which they operate.

Through this work, we have come to value:

Verified outcomes over generated output

Explicit intent over implicit assumptions

Human judgment and ownership over human supervision

Safe, continuous flow over controlled, sequential handoffs

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Agentic Manifesto

We follow these principles:

1. Our highest priority is to deliver valuable, verified outcomes to customers through early and continuous delivery.

The goal is not to produce more code, complete more tasks, or deploy more agents. It is to solve meaningful problems and establish that we've solved them.

2. Welcome changing requirements and new information. Design systems that make change cheap, verifiable, and reversible.

AI makes experimentation and implementation cheaper. We should take advantage of that flexibility while ensuring that changes can be evaluated and corrected without creating unnecessary risk.

3. Deliver working software frequently, with automated verification integrated throughout development.

Short feedback loops remain essential. Agents should be able to implement, test, evaluate, and refine changes continuously rather than generating large quantities of code that must be reviewed later.

4. Make intent explicit enough for humans and agents to understand what must be achieved and what must never be violated.

Requirements, constraints, invariants, acceptance criteria, and architectural boundaries should be expressed clearly and made executable wherever practical. Explicitness enables autonomy; it does not eliminate the need for judgment.

5. Build verification into the development process, and require evidence proportional to the consequences of failure.

Quality should not depend on hoping that generated code is correct or relying exclusively on human review. Use automated tests, static analysis, security checks, formal methods, runtime monitoring, and independent evaluation where appropriate. Higher-risk changes require stronger evidence.

6. Build quality into the production system rather than relying on inspection at the end.

Detect abnormalities as early as possible, prevent defects from propagating, and stop work when critical verification fails. A system that produces code faster but allows defects to accumulate is not a better system.

7. Give agents the maximum autonomy that can be safely supported by explicit boundaries, reliable feedback, and effective controls.

Autonomy should be earned through evidence and constrained by risk. Agents should be able to make routine decisions independently while respecting permissions, architectural rules, operational limits, and escalation requirements.

8. Preserve human judgment, creativity, and ownership as the capabilities of autonomous systems increase.

Delegate implementation, not responsibility. Humans should focus on defining problems, resolving ambiguity, making consequential decisions, and taking accountability for outcomes. Greater leverage demands greater responsibility.

9. Learn continuously from customers and from the behaviour of software in production.

Specifications and tests cannot anticipate everything. Real usage, operational signals, incidents, and customer feedback must inform both the software and the system that produces it.

10. Prefer simplicity and maintainability over unnecessary complexity, even when implementation is cheap.

The fact that an agent can generate a feature quickly does not mean we should build it. Every additional feature, abstraction, dependency, and architectural decision creates potential costs that extend beyond implementation.

11. Optimise for the flow of verified value, not the utilisation of people, the volume of generated code, or the number of agents deployed.

A productive system minimises unnecessary queues, handoffs, rework, and delays between an idea and a verified outcome. Increasing output without improving the entire system merely moves the bottleneck.

12. Continuously improve the system that produces software.

Every defect, failed verification, production incident, and unexpected agent behaviour is an opportunity to improve our specifications, constraints, tests, architecture, and feedback loops. The production system itself must evolve as our capabilities change.

What does this mean for the future of software development?

I believe AI is changing more than the productivity of individual developers.

It is changing the economics of software itself.

If code becomes a common good, the ability to produce an implementation becomes a weaker competitive advantage. The value shifts towards understanding problems, delivering differentiated outcomes, possessing valuable data and distribution, operating reliable services, and establishing trust.

This could fundamentally change enterprise software.

Organisations may increasingly build and adapt software around their own needs instead of accepting the limitations, complexity, and cost of generic products. Custom software that was previously too expensive to justify could become economically viable.

But this future won't be realised simply by giving everyone access to coding agents.

We need production systems that can support the resulting increase in output without sacrificing correctness, security, maintainability, or human accountability.

That's why I think verification should sit at the centre of an Agentic Manifesto.

Not because every line of code needs a formal proof, or because humans should spend their days supervising machines, but because the ability to produce software is becoming less scarce while the ability to establish that software is correct, valuable, and safe remains essential.

The opportunity is to build systems that let us produce more valuable software with less unnecessary effort, while increasing our confidence in what we deliver.

What do you think?

This is a first attempt, and I'm very interested in hearing what others think.

A few questions I'd particularly like to explore with the community:

Are we approaching a point where the Agile Manifesto needs a successor, or are its original values sufficient for the agentic era?
Is verification the right centre of gravity for a new manifesto, or am I overestimating its importance?
What should happen to team structures and engineering roles when a smaller number of engineers can direct much larger amounts of autonomous work?
If code becomes a commodity, where will the sustainable competitive advantage in software actually come from?
Which of these 12 principles would you change, remove, or add?

I'm especially interested in disagreements and alternative perspectives. I'd rather have these ideas challenged now than present a polished manifesto that fails to address the real problems we will face.

The Agentic Manifesto isn't a finished answer. It's an invitation to work out what software development should become next.

What would you change?