> Instead, the right train of thought is: "what would perfect code look like?"
That's the classic 2nd-system effect - "let's rewrite it from scratch, now that we know what we want". And you throw away all the hard-learned lessons.
Not really the case; you're misunderstanding the term second system effect.
> The general tendency is to over-design the second system, using all the ideas and frills that were cautiously sidetracked on the first one. The result, as Ovid says is a "big pile". For example, consider the IBM 709 architecture, later embodied in the 7090. This is an upgrade, a second system for the very successful and clean 704. The operation set is so rich and profuse that only about half of it was regularly used. (p.55)
>
> The second-system effect has another manifestation somewhat different from pure functional embellishment. That is a tendency to refine techniques whose very existence has been made obsolete by changes in basic system assumptions. (p.56)
It's the exact opposite: by explicitly dictating what is correct, perfect, and standard in this codebase, we achieve very high consistency and quality with very little "embellishment" and excess because the LLM is following a set of highly curated instructions rather than the whims of each developer on the team.
Suggest that you re-read what Brooks meant by "second system effect".
Not really the case; you're misunderstanding the term second system effect.
It's the exact opposite: by explicitly dictating what is correct, perfect, and standard in this codebase, we achieve very high consistency and quality with very little "embellishment" and excess because the LLM is following a set of highly curated instructions rather than the whims of each developer on the team.Suggest that you re-read what Brooks meant by "second system effect".