We need some way to make AI-driven coding strive for parsimony.
A meaningful risk of course is that the tools available to the model (ripgrep + fancier semantic approaches) allow it to do a good job of reasoning over things much larger than its context window, and so it doesn't pay the penalty sufficiently to fix it.
What's more profitable, optimizing for inference time or optimizing to increase inference time by increasing token count?
Maybe for simple one-person projects. We've long since developed methods and models to allow us to make things bigger than ourselves. Linux, SAP, etc. These software projects are not held in the mind of a single developer. But we use structure, rules, and other tools so that the pieces still fit together.
It's the infinite AI monkeys at a computer keyboard phenomenon.
Or the car on the highway that bumps left and right on the guardrails until, eventually, it arrives at its destination and nearly everybody is amazed at that great success.
The AI kool-aid drinkers are going to answer: "but that's how human code too".
And I'm really not sure about that.
That isn't to say software is perfectly built, but it's usually pragmatically built to balance costs of development and correctness - well chosen abstractions let us push up both qualities at once.
I assume one can't benchmaxx multi-year long efforts, clean architecture, taste etc as easily as these "make tests pass" tasks
Sorry, the lines have to clear what? Surely there must be some kind of constraint on "lines" that they have to overcome.
In code the thing has to become stable, can't just keep packing more and more noise onto it.
In other words, if you can’t design a modular monolith, you can’t design a set of microservices.
The codebases using technologies I have no idea about tend to quickly become unmaintainable and buggy, because the LLM still doesn't make good architectural choices, but the codebases that use technologies I'm familiar with basically never devolve into unmaintainability.
The difference between the two is massive, and that's why I think that a competent engineer steering an LLM in their area of expertise gets two orders of magnitude more productive, whereas someone steering an LLM in an area they know nothing about are basically producing tech debt at the speed of thought.
Shipping 100x more features per day?
I've written up my process here:
https://www.stavros.io/posts/how-i-write-software-with-llms/
The biggest thing to get right is to let the LLMs do what they're great at (code implementation from very detailed specs, and code review), and you do what humans are great (architecture and making sure the high level of the implementation is sane). That way, you get the best of both worlds, and a lot of speed at high quality.
Although I suspect models from Google, Facebook and Microsoft can be trained on their massive internal codebases. Whether they are is another question.
But, you would probably see a difference of scale and architecture. Larger projects that need better organization are probably more likely to be in private codebases (Linux excluded). So you might be right about the lack of private code in LLM being an issue.