If you can really get a good set of requirements, go and write all of your test cases out, and then throw it at an AI that will one shot it. Its perfect.
If you can really get a good set of requirements, go and write all of your test cases out, and then throw it at an AI that will one shot it. Its perfect.
I've tried this out. Even with relatively small applications and with spending hours reviewing the spec documents, there was always something I missed or something that wasn't quite right when seeing it live.
But today you can do even better, with AI can do true waterfall by rewriting from scratch many times.
This does nothing other than ensure you end up in the "joy" of running a v0.0.1 product but for years on end instead of for a few months.
I hear this sort of thing a lot, and I can't help but internally translate it to "I've never had to take oncall for a product directly after a rewrite". It will be broken; not even because the AI is "wrong", but because the rewrite has new edge cases. No one rewrites a project to have the exact same edge cases. Those edge cases will become outages. No one will learn anything, because a month from now it will be rewritten and those edge cases will get swapped for something else; you can pick which edge of the CAP theorem you want to live on, but you can't pick "none of them".
Really I was thinking about exact example announced recently on HN: Postgres rewirte in Rust, it has 3 versions looks like each one generated from scratch https://github.com/malisper/pgrust