So the end game for this is, to a certain extent, does the code quality matter if it does what it is needed?

In the past the quality mattered because maintenance and tech-debt was something that we had to spend time and resources to resolve and it would ultimately slow us down as a result.

But if we have LLMs do we even have "resources" any more? Should we even care if the quality is bad if it is only ever LLMs that touch the code? So long as it works, who cares?

I've heard this positioned in two different ways, from two different directions, but I think they both work as analogies to bring this home:

- do engineers care what machine code a compiler generates, so long as it works? (no, or at least very, very, very rarely does a human look at the machine code output)

- does a CEO care what code their engineers generate, so long as it works? (no)

Its a very very interesting inflection point.

The knee jerk reaction is "yes we care! of course we care about code quality!" but my intuition is that caring about code quality is based on the assumption that bad code = more human engineer time later (bugs, maintenance, refactoring etc).

If we can use a LLM to effectively get an unlimited number of engineer resources whenever we need them, does code quality matter provided it works? Instead of a team of say 5 engineers and having to pick what to prioritise etc, you can just click a button and get the equivalent of 500 engineers work on your feature for 15 minutes and churn out what you need and it works and everyone is happy, should we care about the quality of the code?

We're not there yet - I think the models we have today kinda work for smaller tasks but are still limited with fairly small context windows even for Gemini (I think we'll need at least a 20x-50x increase in context before any meaningfully complex code can be handled, not just ToDo or CRUD etc), but we'll get there one day (and probably sooner than we think)