Continuous Specification for the Agent Era

Over the last year, we have seen the capabilities of agents grow and their difficulties dissolve rapidly. Since starting this project, the problems that once tested frontier models can now be solved by their smaller siblings with ease.

In day to day work, agentic coding has improved on almost every metric but PLAN.md files are still an area that needs significant improvement. I was fascinated by SpecKit and agent plan modes when they were first released. The workflow of taking a ticket description, planning the implementation and writing a detailed discussion of background, what to do and even what functions or scripts were needed was a huge step forward.

There were however some big problems with these sprawling plan files. Firstly, they are very difficult to read. Partly because of the sheer volume, even after prompting “be concise”, and partly because they are repetitive and restate obvious facts about the codebase.

This means we skim and make assumptions!

If something is in the plan, the agent treats it as important. This includes the outdated or incorrect information hidden in the mountains of text and tables. The misalignment between your intentions and the agent's understanding leads to more iterations, slower development time and a worse overall experience.

The other weakness, even more evident in plan mode, is the focus on the tactical delivery rather than developing an overall strategic solution. Planning upfront can often force the agent to take a particular direction too early and can lead to repetitive code, poor cohesion and brittle implementations. Plan mode also tends to create discrete units of change which act like jagged steps forward rather than an evolving, growing and cohesive system.

Continuous Specification in practice

Continuous Specification is about creating a living model of your system that can evolve from within rather than queuing up plans and requirements from the outside. Software systems are complex, so the specification system needs to be explorable and easily viewed from different perspectives and different levels of abstraction.

Workstreams give you a space to set goals and guardrails up front so that everyone can agree to the project at hand. They also allow multiple streams to continue alongside each other with small batches merged to the main spec incrementally, mirroring Continuous Integration.

Product and engineering focus on the behaviour and requirements but because they are now working within the system itself the software design shifts left and creates a more cohesive team. Agents are involved in every stage, they propose both the strategic and tactical designs and the implementation decisions. When a consensus is reached, tasks of deliverable work naturally emerge and can immediately be picked up for development and testing. Testing seamlessly loops back to the specification and any drift can be amended and reconciled so the expected state of the system is always aligned with production.

Specbench is the collaborative platform that brings your whole team, and their agents, together to create this living model. It is grounded in Domain Driven Design and Behaviour Driven Development and gives everyone the tools they need to express their intent, draw clear boundaries, define business rules and ratify a specification that everyone agrees on.

Changes to the specification are continuous and agents are an integral part of the overall team.

Won’t this spec still drift?

The beauty of Specbench is that the specification produced isn’t just a document to be skimmed over or ignored. It is the heart of the application and the work is built around the spec itself, and the output lives in your codebase. Changes are agreed, implemented and tested against the model frequently and drift is highlighted before it can diverge.

Isn’t this just waterfall?

No. Continuous Specification is the practice of defining a consistent model of your system which can evolve with the changing demands of your business. Agile didn’t beat waterfall because clear requirements don’t work. It won because fast feedback loops let you learn and improve.

A specification should be the source of truth for your system but that doesn’t mean it has to be rigid. The important part is for everyone and every agent to have the tools to understand and agree on that specification as early as possible.

Why not just let them cook?

Whilst I hugely respect the work we see from this style of agentic development, not all companies have the token budget, or customers with the early adopter mindset that would accept this supercharged Ship Fast and Break Things style of development.

Additionally, even though agents are getting better at shipping bigger pieces of work without breaking stuff I still believe that multidisciplinary product teams working together, empowered by their agents, deliver the best outcomes for their customers and users.

Can’t my agent just work from a Jira ticket?

The models, harnesses and tooling for gathering context, reading ticket descriptions from different sources and dealing with the noise surrounding a large project have improved recently. But Specbench isn’t trying to replace established project management tools. What if the ticket was no longer the requirements but an artefact of delivered work instead? Just think, a Kanban board with an “In Progress” column makes less sense now when delivery takes a few hours instead of a few days.

The Future

Predicting where the industry will go next is hard. Labs are pushing model capabilities at all tiers and the supporting tooling continues to rapidly improve. Agents have proven that they can accelerate software development, but they act as an amplifier. Good practices compound to great things and bad practices cause progress to grind to a halt.

Good engineering discipline, agile delivery, and putting the customers and users first are more important than ever, and now you don’t have any excuse to cut corners. I believe Product, Engineering and agents will continue to work even more closely together and using a tool like Specbench is key to managing that relationship. We know that coding agent capabilities will continue to improve but product focused engineering companies with good understanding of their customers and their software will be best placed to take advantage of this super-charged acceleration.

So if you’re looking for a collaborative tool that helps agents make better design choices, ratifies decisions with everyone on the team and gives an explorable, domain-specific specification for your software please check out Specbench.