The detailed design spec is an issue hence Agile's "working code over comprehensive documentation". Your two points are consequences of this.

"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.

▲

4ndrewl 8 hours ago | parent [-]

It's often forgotten that the last part of the agile manifesto states that the eg 'comprehensive documentation' _is_ valuable.

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.

▲

mytailorisrich 8 hours ago | parent [-]

The Agile manifesto states exactly what I wrote. It's not that comprehensive documentation isn't valuable, it's that working software is more valuable.

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.

	▲	skydhash 5 hours ago \| parent [-]
		> 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 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.