I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear.

I feel like that gives an even more literal tower-rising metaphor, and that's what it feels like people using agents naively (and software engineers of lower skill or earlier-career), end up violating.

Agents are getting better at folding things into themselves, especially if you direct them to... but unfortunately I've found that the architectural instincts, even of Fable and 5.6 Sol, are still wildly behind what I reflexively achieve, say.

For sure there is an ability to have agents go back over work and try to fold it into better and better abstractions until it's sort of annealed into something good. I've done something similar on codebases that I have, but the 'high reaches' of architecture with great _prediction of how the software will evolve in the future_ in _subtle_ ways – those are, for now, out of reach of agents.

There is a part of me that wonders if it's partly just how much they can hold in their head right now, though. Even with the greatest articulation and high density of feeding them, the current setups don't allow them to hold a high-quality, sparse, 'zoomable' model of the world in their head that well yet, which we can do pretty well.

But the fact that I'm talking about it in terms of that kind of subtlety is itself promising, I guess?

The upper bound on program complexity used to be the power of the human mind. "Vibe coding" can break through that barrier. But not because the problem being solved needs that complexity. Because the process does not drive itself towards compact abstractions. It's the AI-powered version of the scaling problem Brooks described back in "The Mythical Man-Month". The combinatoric problems get worse with scale. Concretely, multiple similar implementations of roughly the same thing appear in different parts of the project. This is a known problem of vibe coding now.

We need some way to make AI-driven coding strive for parsimony.

Isn't this just an effect of what the LLMs are RL'ed for? Solving short-horizon tasks.

I assume one can't benchmaxx multi-year long efforts, clean architecture, taste etc as easily as these "make tests pass" tasks

> the lines have to clear.

Sorry, the lines have to clear what? Surely there must be some kind of constraint on "lines" that they have to overcome.

Do you believe "micro services" can make a comeback? local daemons with an exposed API, each daemon vibe coded?

Agreed, and ever since LLMs started being able to write competent code, I've noticed a massive difference in quality on codebases where I knew the technology, and ones I didn't. This is because I can much more efficiently steer the LLM on e.g. backend code, which is my expertise, vs yoloing everything on mobile, where I have no idea.

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.