Software developers need an Agentic manifesto

I can’t decide whether Agile development is completely dead or about to make a huge comeback. Or maybe Waterfall will. Who knows? 

Coding agents are changing everything — and I don’t think we’ve quite figured out how they are going to update our methodology, or how we are going to organize ourselves to take advantage of them. We have barely scratched the surface.

Folks who have been around a while will remember the Waterfall method for developing software. Because coding was the hardest part of any project, Waterfall called for figuring everything out before you even started writing code. You would write a huge specification, detailing everything, then turn it over to the development team. The development team would build to the spec and pass the software on to the testing team who would verify it, and finally the project would be delivered to customers. 

Never mind that by the time the thing was built and tested, what the customer wanted had probably changed dramatically. And if the customer decided they wanted a widget here and a sprocket there after the specification was written? Well, that would be a formal change request and would require a whole lot more time and money, thank you very much.

Yeah, they really did it that way.

Waterfall bad, Agile good

It didn’t take long for everyone to figure out that the Waterfall way wasn’t going to cut it. Projects were almost always late and not at all what customers wanted. There had to be a better way, and eventually a bunch of software luminaries quite literally got together in a room and wrote the Agile manifesto. They argued that you didn’t have to be so rigid to actually get things done. It was quite revolutionary at the time.   

The Agile manifesto helped popularize methods like Scrum and other implementations of Agile, which of course have been much debated. We software developers like to kibitz about how to write software, but despite petabytes of bits dedicated to what Agile is and isn’t, we all generally agreed that Waterfall needed to be relegated to the Recycle Bin of history. 

But now? I wonder. One of the reasons Waterfall was developed was that implementation was so hard — and the biggest bottleneck. Now that implementation is easy, and no longer the bottleneck, how does that change how we should develop software?

I’m going to say it has to completely change how we view the process. But how?

It might just be that Waterfall makes a big comeback. If the specification becomes the definition of the application, and the code can be generated in a trivial amount of time, would it not make sense to write a complete and thorough specification, then let the coding agent produce it in a matter of hours or days?

If coding is trivial, might we iterate on the specification rather than the implementation? In other words, how about we use the Agile methodology on the specification, updating the spec based on customer feedback and how the software is implemented by the coding agent?

What if the development process looked like this:

1. Write a specification
2. Have the customer agree to the specification
3. Build the application with a coding agent
4. Get customer feedback on the resulting application
5. Update the specification based on that feedback
6. Go to Step 2
7. Repeat until the customer is happy

Here the customer signs off on the specification changes and the implementation.

Or maybe the iteration goes like this:

1. Write a specification
2. Build the application with a coding agent
3. Get customer feedback on the resulting application
4. Update the specification based on that feedback
5. Go to Step 2
6. Repeat until the customer is happy

In this version, the customer never sees the specification and only sees a working application, but you treat the specification, not the code, as the real source of truth. 

Soul of a new methodology

Taking a step back, what the heck is this thing? You are focusing on the specification — basically getting it right before delivering the software. That’s Waterfall. But you are iterating over things and getting customer feedback along the way, and that is the basis of Agile. 

We already are calling this kind of thing “spec-driven development”. Interestingly, this notion violates one of the values of the Agile manifesto, namely “Working software over comprehensive documentation”. But if working software can be generated in short order, is that value even necessary anymore? At some point, can we even distinguish between the working software and the comprehensive documentation? 

If the specification becomes the thing iterated on, doesn’t it become the source code for the application? You keep fine-tuning the specification, and it becomes the definition of the application. The code generated by the agent becomes the equivalent of machine code — not something you generally worry about.

If the specification becomes the definition of the

Read the original article:

Software developers need an Agentic manifesto