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?

> There is the appealing idea that AI-assisted programming means better tools which lets us build more ambitious software. That is certainly true at the level of the individual and without doubt a developer with an agent will be dramatically more capable of changing a codebase. But large software projects have never been limited only by how quickly an individual can produce code. They are limited by how well people can coordinate their understanding of the system they are changing.

So true.

Since Nov 30, 2022 everything has become… more complex.

The core thesis of this essay is reminiscent of the Lisp Curse [1] / Bipolar Lisp Programmer [2].

It's been a few years since I read these, but if I recall the argument there, it was that Lisp makes it so easy to build stuff and scratch exactly your own itch, that there's no real strong push for lisp programmers to come together and collaborate to build non-trivial and general purpose artifacts. And that is why the landscape of public lisp software is poorer as a result, compared to languages which demand much more effort to get anything substantial done.

Armin seems to be making a very similar point about AI coding.

[1] https://www.winestockwebdesign.com/Essays/Lisp_Curse.html

[2] https://www.marktarver.com/bipolar.html

> The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does. This language is rarely written down in one place. It lives partly in documentation and code, but also in code review, conversations, arguments, and the experience of having to explain a change to somebody else.

This is so true. I am a big fan of Christopher Alexander’s “Pattern Language” concept, which addresses this exact problem! In fact he recommends developing your own pattern languages for your own domains (which of course led to the famous GoF Design Patterns book).

I have been experimenting with a “Pattern Language” skill which instructs the AI to maintain 3 pattern languages for every project. One in the business domain, one in the product domain, and one in the technical domain. It is working really well. It is always super cool to see it reference the pattern languages during planning and curate them during implementation and review.

I credit using it with keeping my 100% ai-coded projects well organized, aligned across domains, and easy to work on.

> the people is one, ... one language, ..., nothing will be restrained from them

Why being one (I see as collaborative) was it not desired? Interpretations? Why is it seemed *more* harmful rather than good?

Three or so years ago, Omar, the creator of DSpy pointed out on Twitter that ~LLMs get better most by better internal collaboration. Wish I could find it.

It seems to me that LLMs and particularly chatbots have already allowed for bigger scale collaboration within the LLM companies versus what was possible within the prior cohort of big platform companies.

Has the result just been taller towers, or actually a change of what is possible?

Anakin: "a developer with an agent will be dramatically more capable of changing a codebase"

Padmé: "For the better, right?"

Anakin: (gazes in silence)

Padmé: "For the better, right?"

My comment is not directly responding to the essay, but it got me thinking about about how agentic programming is much more akin to management than it is to actual programming. Managers generally only have a high level idea of what ICs are working on and often don't have the time, bandwidth, and in some cases ability to understand everything the ICs they're supervising are doing. As more and more software gets written agentically the role of software engineer becomes less technical and more managerial.

I come back to Babel and the Bruegel image too, although taking from it a little less optimism.

I feel these systems rising and sprawling with wee myopic agents developing out their little corners of this unknowably vast whole… a tower with 50 parapets on one side and some wacky cantilevered maiden tower on the other, and a very serviceable adobe roof over some patio for god-knows-why, and thatch over the landing next to it…

Some grotesque fatberg of designs that make sense at the level of individual design efforts, but that lack the fractal sort of levels of policy and judgment that unify the overall enterprise.

The overall language, as it were.

And language takes discipline to establish and maintain through any sufficiently large group of people—witness the company-speak or army-speak of pretty much any successful organization.

We feel like we’ve conquered the problem of talking the same language as our “Gastown Mayors” (who in turn are talking the same language as their “polecats” and so on all the way down the chain of golems)… but it’s only when it’s all built that the good Lord will humble us… that we’ll realize the understanding we thought we’d transmitted perfectly from our thrones wasn’t quite so shared as we’d imagined.

This could've been a much better article without the strained Tower of Babel article.

It used to be that you need a good reason to make huge refactorings, because it’s often so much work. Now agent can rewrite half of your code if your prompt is vague enough and you don’t actual try to review it all. And so the “soul” of a program can change dramatically every single day. It’s both great and very much not so.

I don't know why people hold on to all this extra software and features when with the tools its easier than ever to strip that out and refactor the end product in to a much more compact deliverable. Maybe once upon a time it was useful to keep legacy parts of the software solution around, but it can be recreated with fresh eyes if needed given the power of the new LLM models. My philosophy is if its not needed, it needs to be removed.

Does it really keep rising? Many of my fondest memories of technology come from times past...

The agent will always fill in the gaps in your understanding. It's not a compiler. It's categorically different from any of the other ways we've built software.

I'm not sure reading code is coming back. The ritual of reading code must come back, because that's the only way to build products that don't collapse under their own incoherence, both technically and visibly.

"just ask Claude" is fine, but it's not the end state

Agents are very good at making us think the tower is rising, when in fact it is falling beneath our feet.

ai eliminating friction is eliminating learning and understanding. this is felt with more severe consequences in K-12 writing and music.

I feel like this is missing the ending of "until gravity wins"

No, the story of the tower of Babel was:

"we can, so we should".

It ended badly.

... and narrowing.

Where the "tower" was once a company (or team?) of human devs, it can now be a single dev and their agents.

The right engineer can likely replace non-technical co-founders with a couple LLMs. Geez, I can't wait to write that article...

You use a shared agents.md and an auto updated architecture doc but that is the one that needs to be heavily scrutinized and everyone gets a turn to review it.

I feel like with software, things have gotten way too complicated (just layer's upon layers upon layers). But to deal with that complexity, now we're using something that just creates WAY more complexity. I've been coding for a while, and I remember the 90s and early 00s where people could make pretty powerful applications with like visual basic or php with essentially no formal training. Those technologies weren't great, but they were really simple and easy to pick up. In contrast, if you try to pick up web development or desktop app development today, it's absolutely overwhelming. Like, something like React is useful but the amount of things you need to know to use it properly is pretty high.

I think introducing AI to deal with this is overall a mistake though. We're just adding more complexity on top of the existing complexity. At best, it's a massive waste of hardware. At worst, we'll probably have agents introducing as many bugs as they fix as they also drown in complexity, and a lot of stuff built using these techniques are going to be fragile garbage while the overall skillset of humanity diminishes because people aren't learning the skills anymore.

Fundamentally, software does not need to be this complicated and it's a solvable problem, but it does require people that care about craftsmanship.

> They are limited by how well people can coordinate their understanding of the system they are changing.

It's not really news, though. Programming as Theory Building (Peter Naur) was published in the 80s, I think?

Maybe the younger entrants to this field never came across it, but even if you never came across it, it was common knowledge amongst experienced devs that understanding of the system you are about to change is crucial.

I don't know. some stuff has gotten less. Major databases now ship effective HA tooling, microservices seem on their way out, structured databases seem to be back in instead of NoSQL.

HTML and pre-rendering are back in, HTMx, liveview

The degaussing of CSS and the hacks we did, hell i was trying to explain how we debugged web pages in IE6 to a younger staff member today.

Some things are more complex, some things got good enough to make them less complex.

>Since Nov 30, 2022 BC everything has become… more complex.

FTFY

Increasing complexity is the story of mankind. It's the story of civilization.

Someone from 20,000 BC would wander around the earth trying to find food, trying not to freeze, and trying not to get eaten. Someone from 5,000 BC would be trying to grow food, hoping it rains, and hoping disease didn't wipe out the village. The second one increases the complexity from all the systems required to manage people and keep the land growing. Today the vast majority of people on earth don't grow their own food at all, and instead are busy in some way managing the complexity of a large society.

Someone from 1970-80 would think our software from pre-llm days was vastly more complex. They'd just code directly to the hardware with no abstraction layer. Now almost no one does that. We abstracted the hardware away in most cases. With cryptography libraries for the vast majority of people it's complexity is abstracted away and mostly people are told "don't try to write your own crypto because you will fuck it up".

The question now becomes, how quickly will LLMs be able to coordinate their understanding of the system they are changing?