4 ms·
Unless the specification is also free of bugs and side effects, there is no guarantee that a rewrite would have fewer bugs. Plenty of rewrites out there prove
by manuelabeledo 7mo ago
Unless the specification is also free of bugs and side effects, there is no guarantee that a rewrite would have fewer bugs.
Plenty of rewrites out there prove that point.
- jimbokun 7mo agoSeems relevant again: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/ https://www.joelonsoftware.com/2000/04/06/things-you-should-...
- skinner_ 7mo agoI think the nuanced take on Joel's rant is this: it was good advice for 26 years. It became slightly less good advice a few months ago. This is a good time to warn overenthuastic people that it’s still good advice in 2026, and to start a discussion about which of its assumptions remain to be true in 2027 and later.
- neilwilson 7mo agoYes, but that's the point. We're not writing code in a computer language any more, we're writing specs in structured English of sufficient clarity that they can be generated from. The debugging would be on the specs.
- manuelabeledo 7mo ago> writing specs in structured English of sufficient clarity What does "sufficient clarity" mean? And is it english expressive enough and free of ambiguities? And who is going to review this process, another LLM, with the same biases and shortcomings? I code for a living, and so far I'm OK with using LLMs to aid in my day to day job. But I wouldn't trust any LLM to produce code of sufficient quality that I would be comfortable deploying it in production without human review and supervision. And most definitely wouldn't task a LLM to just go and rewrite large parts of a product because of a change of specs.