> what "maintainable" is is probably some high dimensional space described by these signals; it'd probably require some human labeling to figure out where this space is
Maybe, but "maintainable" has a simple definition: minimising the effort to incrementally grow a software system as its size grows to infinity (while maintaining some defect ratio). Humans (called senior software engineers) figure this out over decades by working on a number of large software systems.
So far models haven't figured the same thing out. I can only guess why. All their learning comes from examining code on the internet. Somehow whatever the patterns are that make large software projects like the OSs maintainable by large groups of people working independently has escaped them. Maybe the bulk of code they look at is in the small so they miss it, maybe the patterns are just hard to discern in big systems.
My theory is there are anti-patterns which the larger projects somehow manage to keep to a minimum. It's hard to learn something that's not there. Instead, you learn these anti-patterns by doing them, and watching a system all fall apart over the course of years, and if you're good you manage to pin the blame on the right thing.
If you want to wrap it up neatly in a package, models have learnt how to program, but programming is not the same as design. Design requires very different skills to using a programming language. At a very high level, big systems are sets of interconnected modules. The things that matter are narrow APIs with minimal coupling, and where coupling is unavoidable making it explicit and easy to reason about. Concrete examples of the anti-patterns to be avoided are global variables, leaky abstractions and APIs that require complex sequences of interconnected calls.
Those things don't bite hard until you program in the large. The current crop of LLM's seem to be useless at all of them. If you've got a big context window and you are only writing 100s of kloc, a budget of kilowatts to understand the complexity, it doesn't matter. But humans don't have a budget like that, and so far everyone I've seen who reads large chunks of vibe coded software recoils in horror, gives up, and walks away.
Even with that budget, the models fail anyway once the size gets way beyond their context window - it's just that they fail much later than humans. Which I guess makes learning the lesson so much harder - perhaps near impossible as your "they need labeled examples" hints at. Oddly the solution would be to train with smaller context windows (a less powerful model in some ways), so the failures become apparent much earlier.
It looks like they have been going with your solution for now - giving engineers cheap tokens via flat-rate plans, and watching how they do things. I don't think that will work. Engineers who chew through the billions of tokens offered by these plans are vibe coding. The code they produce is so poor it can't cross the threshold from small to large. There is nothing to see there about programming in the large.
:( what a rant - it looks like an LLMs CoT as it thinks through things. Which is what I was doing, I guess.