Since when we accepted that we can’t go fast and offer stability at the same time?
Time is highly correlated with expertise. When you don’t have expertise, you may go fast at expense of stability because you lack the experience to make good decisions to really save speed.
This doesn’t hold true for any projects where you rely on experts, good processes and tight timelines (aka: Apollo mission)
IME there's a reason it's "move fast and break things" and not "move fast and don't break anything," because if the second was generally possible, we wouldn't even need this little aphorism.
And again, I'm not making a claim that the slow and steady tradeoff is best for all situations. Just that it is a great tradeoff for foundational platforms like a runtime. On a platform like postgresql or the JVM, the time from initial proposal to being released as a stable feature is generally years, and this pace I think has served those platforms well.
But I'm open to updating my priors. Do you think there are foundational platforms out there that iterate quickly and do a good job of it?
"Correct" usually means "exactly matches the specification" .... these systems do not do that based on what's been indicated on a bunch of articles, HN discussions, etc. etc. documenting people's collective experiences. It often doesn't one-shot tasks, it requires hand-holding. Oftentimes to a significant degree. Especially if not working on a CRUD webapp with a lot of boilerplate which heavily skew the training data. LLMs return the most likely sequence of individual elements of code, not the most correct code.
So, it's fast if you get lucky and are able to one-shot it, affordable-ish if you get lucky and are able to one-shot it and correct if you get lucky.
And that tends to happen if you're working on a specific set of codebases which are close to the most commonly occurring codebases in the training data set -- i.e. CRUD webapps / heavy boilerplate usage. Most FOSS projects probably don't fit in that camp (i have no data to support this, it's just my gut experience).
Time is highly correlated with expertise. When you don’t have expertise, you may go fast at expense of stability because you lack the experience to make good decisions to really save speed. This doesn’t hold true for any projects where you rely on experts, good processes and tight timelines (aka: Apollo mission)