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?

> But it’s not the biblical story. At Babel, the loss of common language stops construction whereas in AI-assisted engineering, construction can continue after shared understanding has already collapsed. The lack of an immediate failure is what makes it curious and a bit disorienting. The tower does not fall, and so we do not notice what was lost. It just keeps rising.

I don't know whether the author thinks this is a good or a bad thing, but in my eyes it's clearly a bad thing. Intelligence is knowing that a tomato is a fruit, wisdom is knowing not to put it in a fruit salad. AI is the the ultimate form of intelligence with zero wisdom. Actually, it's not even intelligence, it's an illusion of intelligence. If there is no human who can understand what the AI is doing it's time to stop and accept that we do not have the wisdom to contain what we are building.

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

> 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 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.

If humans are still around by the end of the century: previously shunned philosophical movements such as pragmatism will actually become mainstream again.

The most interesting problems arise when you don't try and force one shared standard upon everybody yet still try and play nice.

Alternatively, power could concentrate and the winners get to decide what is valuable and not, thus cutting down the space of possible complexity by construction.

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?"

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.

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.

the tower keeps rising but the elevator pitch for every new floor is 'it solves the problems created by the floor below it'

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.

Douglas Adams basically predicted Wikipedia on smartphones, and I suspect we are only a few years away from babelfish ear buds.

> I can ask an agent to add OAuth, you can ask one to add caching, and somebody else can ask one to rebuild the database from first principles and make the UI pink. Each change can be reasonable in isolation.

But this is just bad vibecoding? This would be bad if humans did it too. With agents or humans, you need to coordinate.

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

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?

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

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.

AI replaces a single tower with millions of 5-over-1s[1]. The aggregate height, and speed of construction mind-boggling, but when each building is considered individually, not very impressive.

1. Perhaps with a handful of skyscrapers sprinkled in.

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

This reminds me of Ted Chiang's "Tower of Babylon". You really should read it (and all of TC's works)!

> 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?

This is exactly what Marx meant by labourers being alienated from their work because none of them understood anymore how the repetitive task they did factored into the product sold.

We are going through a transition from a guild based software production with primitive division of labour to a machinery based one where AI is the steam engine and the job of the engineer is to build the production line, be the mechanic fixing the line, and also the assembly line worker.

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

at one point - future generations - will look at people who designed unix like tools - tools that do one thing well & compose with other tools as demigods.

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

Since GPT 5.2, AI has been writing code much better than I can. In 5.6, it beat Tourlist in competitive coding. After seeing that, I only practice about an hour a day just to keep the feel of coding.

Honestly, rather than pointless debates about whether human coding is bad or AI coding is bad, I just think it's good to build tools that help me understand the world. I don't really care whether it's hand-coded or bad code.

Because most of my career has been spent as an on-site programmer. Staying at factories, visiting public institutions, deploying services for financial companies. My career is short, but I was lucky enough to work in various places.

When AI first came out, I thought I still wrote better code. But after the GPT 5 series, I've completely switched to AI and I'm now thinking about how to avoid errors and maintain larger codebases.

In the world I work in, it's common to see functions with 10,000 lines. Many people don't consider coupling or cohesion. So these days, instead of focusing on programming syntax, I'm studying programming theory and thinking about how to handle code when it becomes massive and turns into a black box through vibe coding. And I think this approach is right, because I believe I need to get used to using AI, so I keep coding with it.

But due to my cognitive limits, I've restricted myself to C# and TypeScript, which I'm comfortable with. C++ has too much to memorize and is hard to keep up with. In my region, there are very few C++ jobs, and those that exist are either extremely high-paying or garbage-tier jobs. There's nothing in between. So I stick with C# and TypeScript.

In practice, when building large programs, I often just set external configuration values I don't fully understand and code based on heuristics. I don't know the internals of Kafka, RabbitMQ, or PostgreSQL. I just know how to use them. And yet they work fine.

I feel the same way about AI code. Even if AI code is messy, if it runs, I use it. When bugs appear or performance is off, I just plug in debuggers or print statements and fix the necessary parts, like working with legacy code. Programming is so complex that if you try to understand everything, you can only design very small parts. Do the people who wrote Linux understand the entire codebase? They trust people they can rely on.

I've also reached an internal agreement to trust AI code. To support that, I'm spending time on creating rules for how to get good code from AI. Things like adding gates or CI, and seeing if that improves the code.

The problem is, I know this means no one will want to use other people's work or collaborate. The middle layer will disappear. There will be only highly admired projects or personal projects. In the past, even mid-sized projects had humans helping each other. But now mid-sized projects barely need human help. So I think projects will become increasingly polarized and become a zero-sum game.

Brooks divided complexity into two types in The Mythical Man-Month: Essential Complexity and Accidental Complexity. Personally, I think AI has greatly reduced Accidental Complexity. However, the essential difficulty, the problem of modeling, still needs to be done by humans. Because AI has no physical embodiment, it's inherently hard for it to understand domains the way humans do. Learning about something is different from experiencing it.

So I've decided to believe that vibe coding is also a valid approach. Supporters talk about compilers being deterministic, but LLMs are not deterministic. Critics say AI only produces garbage code, but I've seen that with high-quality prompts, the output becomes much better. Math PhDs say AI is good at things like theorem proving, and most of coding is similar to theorem proving.

It's not about good or bad. I've decided to believe it's just another approach. Yes, this is just a religion. My religion.

No matter how much people say vibe coding is bad, those who use it well do use it well. And there's no reason to criticize those who don't use it. I've just decided to treat this programming approach as a religion. Arguing about what's right or wrong is pointless anyway. Everyone has different values based on their environment, and convincing others is a waste of time.

People in open source communities might feel like AI code is destroying their communities. The code they used to communicate with, and the time they spent on it.

But for someone like me, who's been in delivery and on-site work, it feels like an escape hatch. It freed me from the hell of dealing with difficult people. So I've decided to rationalize it to myself: AI coding is just one way of doing things

I just think new methodologies will emerge. Instead of dividing code by functions or methods, people will think about how to divide things at a larger scale.

I'm just living to adapt to this era. I have nothing to lose anyway. I'm just waiting for the new era.

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.

[dead]