a) the mulyi-year lead time from starting the spec to getting a finished product
b) no (cheap) way to iterate or deliver outside the spec
Neither of these are a problem with SDD.
It's a bit funny to see people describe a spec written in days (hours) and iterations lasting multiple weeks as "waterfall".
But these days I've already had people argue that barely stopping to think about a problem before starting to prompt a solution is "too tedious of a process".
They both have issues but they are very different. A waterfall project would have inscrutable structure and a large amount of "open doors" just in case a need of an extension at some place would materialize. Paradoxically this makes the code difficult to extend and debug because of overdone abstractions.
Hasty agile code has too many TODOs with "put this hardcoded value in a parameter". It is usually easier to add small features but when coming to a major design flaw it can be easier to throw everything out.
For UI code, AI seems to heavily tend towards the latter.
Documentation gets out of date quickly!!!
The problems with waterfall come when much of the project is done and then you discover that your spec doesn't quite work, but the changes to your spec require half the requirements to subtly change, so that it can work at all. But then these subtle changes need to be reflected in code everywhere. Do this a couple of times (with LLM and without) and now your code and spec only superficially look like one another.
The detailed spec is exactly the problem with the waterfall development. The spec presumes that it is the solution, whereas Agile says “Heck, we don't even understand our problem well, let alone understanding a solution to it.”
Beginning with a detailed spec fast with an LLM already puts you into a complex solution space, which is difficult to navigate compared to a simpler solution space. Regardless of the iteration speed, waterfall is the method that puts you into a complex space. Agile is the one you begin with smaller spaces to arrive at a solution.
How can you even develop something if you don’t have a clear idea what you’re building?
That's the key benefit of starting small and of iterating: it allows you to learn and to improve. You don't learn anything about your problem amd solution by writing a comprehensive design spec upfront.
But, the statement "we don't even understand our problem well" is typically correct. In most cases where new software is started, the problem isn't well-defined, amenable to off-the-shelf solutions. And you will never know as little about the problem as you do on day one. Your knowledge will only grow.
It is more useful to acknowledge this reality and develop coping strategies than to persist in denial of it. At the time that the agile manifesto was written, the failure of "big up-front design" was becoming plainly evident. You think that you know the whole spec, and then it meets reality much as the Titanic met an iceberg.
Agile does not say "no design, no idea", it points out things that are more valuable than doomed attempts at "100% complete design and all the ideas before implementation". e.g. "while there is value in (comprehensive documentation, following a plan), we value (Working software, Responding to change) more. (see https://agilemanifesto.org/ )
In other words, start by doing enough design, and then some working software to flush out the flawed thinking in the design. And then iterate with feedback.
It's the ability to _change_ quickly (or be agile) in response to feedback that marks the difference.
The delay is just irrelevant. It has nothing to do with it working ot not.
>b) no (cheap) way to iterate or deliver outside the spec
You could always do this in a waterfall project. Just make whatever changes to the code and ship. The problem is the same for SDD, as soon as you want quick changes you have to abandon the spec. Iterating the spec and the code quickly is impossible for any kind of significant complex project.
Either the spec contains sufficient details to make implementation feasible and iteration times become long and the process of any change becomes tedious and complex or the spec is insufficient in describing the complexity of the project, which makes it insufficient to guide an LLM adequately.
There is a fundamental contradiction here, which LLMs can not resolve. People like SDD, for a exactly the reason Managers like waterfall.
"Heavy documentation before coding" (article) is essentially a bad practice that Agile identified and proposed a remedy to.
Now the article is really about AI-driven development im which the AI agent is a "code monkey" that must be told precisely what to do. I think the interesting thing here will be do find the right balance... IMHO this works best when using LLMs only for small bits at a time instead of trying to specify the whole feature or product.
The key to Agile isn't documentation - it's in the ability to change at speed (perhaps as markets change). Literally "agile".
This approach allows for that comprehensive documentation without sacrificing agility.
In addition, the big issue is when the comprehensive documentation is written first (as in waterfall) because it delays working software and feedback on how well the design works. Bluntly, this does not work.
That's why I think it is best to feed LLMs small chunks of work at a time and to keep the humam dev in the driving see to quickly iterate and experiment, and to be able to easily reason with the AI-generated code (who will do maintenance?)
The article seems to miss many of those points.
IMHO a good start is to have the LLM prompt be a few lines at most and generate about 100 lines of code so you can read it and understand it quickly, tweak it, use it, repeat. Not even convinced you need to keep a record of the prompt at all.
REPL development and Live programming is similar to that. But when something works, it stays working. Even with the Edit-Compile-Run cycle, you can be very fast if the cycle is short enough (seconds). I see people going all in with LLMs (and wishing for very powerful machines) while ignoring other tools that could give better return on a 5 year old laptop.