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:
- Write a specification
- Have the customer agree to the specification
- Build the application with a coding agent
- Get customer feedback on the resulting application
- Update the specification based on that feedback
- Go to Step 2
- 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:
- Write a specification
- Build the application with a coding agent
- Get customer feedback on the resulting application
- Update the specification based on that feedback
- Go to Step 2
- 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 application, do we need to apply version control to the document? Do we do pull requests and code reviews before changing it? If we choose to do a fresh implementation upon every iteration of the specification, do we even need version control on the resulting code?
And after customer feedback and an updated specification, do you have the coding agent update the code that it has already generated, or do you have it redo the whole application from scratch?
I can see the implementation part playing out in three or four ways. First, you could simply abandon each implementation and have the agent rebuild the application from scratch every time. This might be the riskiest option, because of the non-deterministic nature of coding agents, but it could work.
Second, you could apply the new specification to the previous implementation, updating it with the changes. The coding agent could continue on the same path, modifying as it goes along. This is similar to what we do today.
Third, you could take a hybrid approach. You could ask the agent to take a look at its previous implementation, then read the new specification, and completely redesign the application based on its previous learning and the new feedback.
Or fourth, you could try all three approaches and see which you like best. Remember, you have a limitless number of developers who will work tirelessly and relentlessly to implement software for you. A bake-off of all the ways it might be done could generate the best solution.
And what about testing? Your relentless coding agents could write massive test suites to cover every aspect of the implementation, meaning you could create something from scratch every iteration, as long as the tests pass. If we instruct the agent to write tests that cover the entire specification — unit tests, integration tests, and even end-to-end tests — could that become the definition of the application? Does agentic coding finally bring to fruition the dream of test-driven development?
I mean, can you, at this point, think of a reason not to have your coding agent write a complete test suite? If you have complete test coverage — the very thing Uncle Bob Martin and Kent Beck dream about in their sleep — do you even need to worry about new implementations? A complete test suite will obviously make the transition from the development phase to the maintenance phase much smoother. And a coding agent will never balk at writing more tests.
An Agentic manifesto
And if we are developing a new methodology, what becomes the bottleneck? You might think that updating the specification based on feedback would become the choke point. But I could envision having extensive discussions with the customer, recording those sessions, then having AI listen to the recordings and update the specification based on what it hears.
Using AI would dramatically speed up the writing of the specification, so getting the customer’s feedback would become the new bottleneck. Imagine a world where things are happening so fast that your customers get frustrated because you are going too quickly and taking up too much of their time!
There are, of course, concerns. In “On the foolishness of ‘natural language programming’”, Edsger W Dijkstra argued that English is far too ambiguous to be able to properly specify a software application. The specification is necessary, but it is probably not sufficient for defining software.
At some point, we will have to worry about the fact that nobody actually wrote any code. At 2 o’clock in the morning, when an emergency bug is found, not knowing the code might be a problem. Or maybe your coding agent could fix it faster than any human.
And all of this really works only for greenfield applications. If you have a huge existing codebase, coding agents probably won’t have as radical an effect on your methodology as they will with a new project. But that remains to be seen, I suppose.
Sure, we can have as many coding agents as we want, but they aren’t free. There will still be costs involved, and those will need to be captured and quantified. However, I suspect that the cost of coding agents will only go down. Moore’s law and its derivatives are undefeated.
The separation of the front end from the back end would have to be refined. Customers probably wouldn’t like it if the application looked different every time the team iterated on it. I can already foresee thin clients getting even thinner (if that is possible) and the back end becoming even more important. In addition, front ends are much more subject to human whim and fancy, and thus would need to be both flexible and consistent. (I think we actually do a pretty good job of that now, however.)
Finally, there are always things that are hard to put into a specification. Look and feel, security, performance, and accessibility aren’t easy to write down and make precise. This is where much of the human work will have to go.
The implications of all of this are mind-boggling. What will it even mean to be a software developer? Will human programming even exist anymore? I can see this all turning into some new “Agentic manifesto” that describes how we will write software in the world of coding agents.
If so, I’d sure love to be in that room.