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.