> Giving enough info about the project (including user stories, tech design requirements, filesystem structure and meaning, core interfaces/models, functions, etc)

What's not waterfall about this is lost on me.

Sounds to me like you're arguing waterfall is fine if each full run is fast/cheap enough, which could happen with LLMs and simple enough projects. [0]

Agile was offering incremental spec production , which had the tremendous advantage of accumulating knowledge incrementally as well. It might not be a good fit for LLMs, but revising the definition to make it fit doesn't help IMHO.

[0] Reminds me that reducing the project scopes to smaller runs was also a well established way to make waterfall bearable.

▲

dtech 8 hours ago | parent | next [-]

Waterfall with short iteration time is not possible by definition.

You might as well say agile is still waterfall, what are sprints if not waterfall with a 2 week iteration time. And Kanbal is just a collection of indepent waterfalls... It's not a useful definition of waterfall.

	▲	makeitdouble 5 hours ago \| parent \| next [-]
		Just as most agile projects aren't Agile, most waterfall projects weren't strict Waterfall as it was preached. That being said, when for instance you had a project that should take 2 years and involve a dozen team, you'd try to cut it in 3 or 4 phases, to even if it would only be "released" and fully tested at the end of it all. At least if your goal was to have it see the light in a reasonable time frame. Where I worked we also did integration runs at given checkpoints to be able to iron out issues earlier in the process. PS: on agile, the main specificity I'm seeing is the ability to infinitely extend a project as the scope and specs are typically set on the go. Which is a feature if you're a contractor for a project. you can't do that with waterfall. Most shops have a mix of pre-planning and on-the go specing to get a realistic process.
	▲	RealityVoid 5 hours ago \| parent \| prev [-]
		> Waterfall with short iteration time is not possible by definition. What definition would that be? Regardless, at this point it's all semantics. What I care about is how you do stuff, not the label you assign and in my book writing specs to ground the LLM is a good idea. And I don't even like specs, but in this instance, it works.

▲

podgorniy 8 hours ago | parent | prev | next [-]

> What's not waterfall about this is lost on me.

Exactly. There is a spec, but there is no waterfall required to work and maintain it. Author from the article dismissed spec-based development exactly because they saw resemblance with waterfall. But waterfall isn't required for spec-centric development.

▲

laserlight 8 hours ago | parent [-]

> There is a spec, but there is no waterfall required to work and maintain it.

The problem with waterfall is not that you have to maintain the spec, but that a spec is the wrong way to build a solution. So, it doesn't matter if the spec is written by humans or by LLMs.

I don't see the point of maintaining a spec for LLMs to use as context. They should be able to grep and understand the code itself. A simple readme or a design document, which already should exist for humans, should be enough.

▲

wiseowise 7 hours ago | parent [-]

> I don't see the point of maintaining a spec for LLMs to use as context. They should be able to grep and understand the code itself.

“I don’t see the point of maintaining a documentation for developers. They should be able to grep and understand the code itself”

“I don’t see the point of maintaining tests for developers. They should be able to grep and understand the code itself”

“I don’t see the point of compilers/linters for developers. They should be able to grep and find issues themselves”

	▲	skydhash 7 hours ago \| parent \| next [-]
		The thing is that the parallels you are drawing is for things that is very explicitly not the source of the code, but exists alongside it. Code is the ultimate truth. Documentation is a more humane way to describe it. Tests are there to ensure that what is there is what we want. And linters are there to warn us of specific errors. None of these create code. To go from spec to code requires a lot of decisions (each introducing technical debt). Automating the process remove control over those decisions and over the ultimate truth that is the code. But why can't the LLM retains the trace of the decisions so that it presents control point to alter the results. Instead, it's always a rewrite from scratch.
	▲	laserlight 5 hours ago \| parent \| prev [-]
		> “I don’t see the point of maintaining a documentation for developers. They should be able to grep and understand the code itself” I cannot think that this comment is done in good faith, when I clearly wrote above that documentation should already exist for humans: > A simple readme or a design document, which already should exist for humans, should be enough.

▲

midnitewarrior 8 hours ago | parent | prev [-]

I see rapid, iterative Waterfall.

The downfall of Waterfall is that there are too many unproven assumptions in too long of a design cycle. You don't get to find out where you were wrong until testing.

If you break a waterfall project into multiple, smaller, iterative Waterfall processes (a sprint-like iteration), and limit the scope of each, you start to realize some of the benefits of Agile while providing a rich context for directing LLM use during development.

Comparing this to agile is missing the point a bit. The goal isn't to replace agile, it's to find a way that brings context and structure to vibe coding to keep the LLM focused.

▲

Fargren 8 hours ago | parent [-]

"rapid, iterative Waterfall" is a contradiction. Waterfall means only one iteration. If you change the spec after implementation has started, then it's not waterfall. You can't change the requirements, you can't iterate.

Then again, Waterfall was never a real methodology; it was a straw man description of early software development. A hyperbole created only to highlight why we should iterate.

	▲	Jtsummers 2 hours ago \| parent [-]
		> Then again, Waterfall was never a real methodology; it was a straw man description of early software development. A hyperbole created only to highlight why we should iterate. If only this were accurate. Royce's chart (at the beginning of the paper, what became Waterfall, but not what he recommended by the end of the paper) has been adopted by the DOD. They're slowly moving away from it, but it's used on many real-world projects and fails about as spectacularly as you'd expect. If projects deliver on-time, it's because they blow up their budget and have people work long days and weekends for months or years at a time. If it delivers on budget, it's because they deliver late or cut out features. Either way, the pretty plan put into the presentations is not met. People really do (and did) think that the chart Royce started with was a good idea, they're not competent, but somehow they got into positions in management to force this stupidity.