I’m starting to realize that LLMs are really good at building low-stakes projects. Your questions mostly presume that the stakes are higher. The software will last a long time; the requirements will evolve; we can’t tolerate mistakes; etc.
The trick to getting good at using LLMs for software is to learn how to make _all_ projects low-stakes.
This is really insightful, but I think it also extends to making the project either low stakes or low complexity. I have this lurking feeling that the preferable architecture for software will change as a result of LLMs because they're good at working on low complexity modular components more than they are on high complexity million-line code bases.
> The trick to getting good at using LLMs for software is to learn how to make _all_ projects low-stakes.
this doesn't really work in the real world. There are many things that actually matter, engineering is fundamentally about handling them.
You don't need LLM for that. You make _all_ projects low-stakes by working on green field project using (insert buzzword soup of the day) and leaving for a new green field opportunity (that requires experience with buzzword soup of the day) before the project ships.