The real value that AI provides is the speed at which it works, and its almost human-like ability to “get it” and reasonably handle ambiguity. Almost like tasking a fellow engineer. That’s the value.

By the time you do everything outlined here you’ve basically recreated waterfall and lost all speed advantage. Might as well write the code yourself and just use AI as first-pass peer review on the code you’ve written.

A lot of the things the writer points out also feel like safeguards against the pitfalls of older models.

I do agree with their 12th point. The smaller your task the easier to verify that the model hasn’t lost the plot. It’s better to go fast with smaller updates that can be validated, and the combination of those small updates gives you your final result. That is still agile without going full “specifications document” waterfall.

It’s a solid post overall and even for people with a lot of experience there’s some good ideas in here. “Identify and mark functions that have a high security risk, such as authentication, authorization” is one such good idea - I take more time when the code is in these areas but an explicit marking system is a great suggestion. In addition to immediate review benefits, it means that future updates will have that context.

“Break things down” is something most of us do instinctively now but it’s something I see less experienced people fail at all the time.