My experience is the same. That is why I write technical specifications for the LLM to follow, and treat the actual code they generate in the same way I treat the assembly produced by a compiler: a black box I rarely peek into.
If the code passes the (extensive) tests, I don't need to read or understand it. That said, I retired before LLMs became popular, so my experience is limited to vibe coding at home.
We (at least some of us) sort of figured out 30ish years ago that waterfall-style software development doesn’t quite work in practice. I don’t think LLMs have substantially changed that.
Did I mention waterfall at all? You are fighting a strawman.
You can write specs for a MVP, write a test plan, yadda yadda, then progressively iterate. I have no idea where you got the idea that I was proposing a waterfall lifecycle.
Comments
My experience is the same. That is why I write technical specifications for the LLM to follow, and treat the actual code they generate in the same way I treat the assembly produced by a compiler: a black box I rarely peek into.
If the code passes the (extensive) tests, I don't need to read or understand it. That said, I retired before LLMs became popular, so my experience is limited to vibe coding at home.
We (at least some of us) sort of figured out 30ish years ago that waterfall-style software development doesn’t quite work in practice. I don’t think LLMs have substantially changed that.
Did I mention waterfall at all? You are fighting a strawman.
You can write specs for a MVP, write a test plan, yadda yadda, then progressively iterate. I have no idea where you got the idea that I was proposing a waterfall lifecycle.