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.
If the "soul" of a program (which is a vague term but I think I get what you mean) changes daily, that's indicative of a lot of churn, and a lot of churn is not a good idea in any project.
it's like changing how the tower of babel should be built daily. Just because you can doesn't mean you should.
This isn't really a good way to judge things. In the future, the fondest memories someone else has about technology will be about the present. The past is not better, you're just nostalgic for it.
> 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.
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'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?
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.
I have a theory (armchair take here lmao) that AIs are trained on public code, but the biggest codebases are not public.
Although I suspect models from Google, Facebook and Microsoft can be trained on their massive internal codebases. Whether they are is another question.
I think part of the problem is the context windows for humans are actually much smaller than what an LLM can keep track of today. The small context window of humans is a feature that forces modularity and abstraction in software engineering so that you can decompose what you're working on into something that can fit into your head. But since LLMs can fit so much more in their head, so to speak, they don't have this same incentive, and you get the unorganized mess of spaghetti code that current agents often produce.
Just a matter of time. Go download gpt2 or llama2 and be shocked at how bad they are compared to today. They were entirely "useless" yet we marveled at them. Go examine GPT3.5/gpt4 out which was all the rage and then marvel at how a qwen27b or gemma31b model mops the floor today. My point is that the models will eventually learn to have a great model of software system in their head, just a matter of time and proper RL.
I can't prove it but I have strong beliefs that the logic and intuition required for abstracting for future changes is not possible in a stream of predicted tokens. Mental models aren't built from text. Something's missing that can't be measured.
> 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.
My personal experiments show that giving them tools to access to all past sessions over a codebase helps a lot. When I coded "feature X" 2 months ago i likely specifically mentioned some constraints expressed as abstractions and, if the coding agent checks not only the code/feature it needs to implement/change but also the past sessions over that, it picks them up, and ships code that better fits the overall project.
At least, more than "architectural/design guidelines", since they are more "concrete", to the point for the task at hand.
Sessions self-preserve them for following sessions, which helps, but might also carry over stale things, so some "pruning" helps, and can be automated. Overall, as long as corrections were also made via agents and hence in sessions, they are picked up automatically.
It's not the "human zoom" you refer to, which as humans we can drive/control, but the effect seems to be similar: I read autonomous sessions where it picked up from the past the very design/architecture/abstraction points i would have driven, had I been in the loop.
In team contexts it should not be impossible to share sessions, but I not working in teams right now :D
So maybe it's also a "single dev quirk".
Another point is that in a sense, learning to code goes from being told "you are using the_wrong_abstraction/this_abstraction_the_wrong_way/no_abstraction_where_you_should_have", to telling it to others/ourselves.
Since the number of knowable abstractions seems to be "at least one more than I already know", agents can actually be helpful in learning.
After a certain threshold, it basically zeros in a specific domain, but on novel domains agents taught me abstractions, when nudged towards doing that.
> I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear.
I love this analogy, and I find it darkly hilarious that most sibling commenters don't seem to understand. Maybe you need to have worked within a million-line codebase to get it.
The only way to "clear the lines" in software is to eject them from the main codebase and into imported libraries with stable, well-documented, well-tested APIs that you very rarely if ever (security vulnerabilities?) need to touch after "stabilizing" them. Great public examples: the Go standard library, https://github.com/spf13/viper , https://github.com/uber-go/zap . Viper and zap combined are more than 20,000 lines of code (according to cloc) that I don't need to read or understand how they work - their lines have been "cleared" and all I need to know is the abstraction.
Half the joy to be found when working within massive codebases is successfully clearing lines.
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.
We can say that about programmers, most ICs don't understand what's going on in the layers beneath were they work. Most have no idea what's going on with libraries, frameworks, remote APIs, it's all abstractions. Most people can't tell you how system calls are implemented or function. They don't have the time, bandwidth to understand it all, they just operate at their own layer to get the job done.
While this is true to a point, the other factor is that developers are hired and tested for having certain skills and specializations. While I'm sure LLMs can be good at things, the question is whether their manager can accurately judge the output. I suppose this problem applies to developers too, but developers have peers and processes.
So as someone managing LLMs you need to put those processes in place too. The risk is that one tries to do too much and loses overview / insight. Focusing on getting the tower tall instead of sturdy, if you will.
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.
this doesn't work in any truly complex system. If the entire organization's shared understanding could be captured in a few documents, software engineering would've been a solved problem ages ago.
> 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.
Would be interesting to see an example. I heard a couple times that code maturance is very similar on how a city grows naturally, but never seen an example.
I haven’t really battle tested these so hard yet but it’s a fun concept and really should get back to organizing them more intentionally. Happy to share this early phase just cause it’s cool to see the interest.
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.
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
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.
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.
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?
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.
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.
> 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.
76 comments
[ 7.1 ms ] story [ 80.8 ms ] threadit's like changing how the tower of babel should be built daily. Just because you can doesn't mean you should.
Is that because of the technology or because of who you were at the time?
So true.
Since Nov 30, 2022 everything has become… more complex.
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.
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 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 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.
Sorry, the lines have to clear what? Surely there must be some kind of constraint on "lines" that they have to overcome.
I assume one can't benchmaxx multi-year long efforts, clean architecture, taste etc as easily as these "make tests pass" tasks
Although I suspect models from Google, Facebook and Microsoft can be trained on their massive internal codebases. Whether they are is another question.
My personal experiments show that giving them tools to access to all past sessions over a codebase helps a lot. When I coded "feature X" 2 months ago i likely specifically mentioned some constraints expressed as abstractions and, if the coding agent checks not only the code/feature it needs to implement/change but also the past sessions over that, it picks them up, and ships code that better fits the overall project.
At least, more than "architectural/design guidelines", since they are more "concrete", to the point for the task at hand.
Sessions self-preserve them for following sessions, which helps, but might also carry over stale things, so some "pruning" helps, and can be automated. Overall, as long as corrections were also made via agents and hence in sessions, they are picked up automatically.
It's not the "human zoom" you refer to, which as humans we can drive/control, but the effect seems to be similar: I read autonomous sessions where it picked up from the past the very design/architecture/abstraction points i would have driven, had I been in the loop.
In team contexts it should not be impossible to share sessions, but I not working in teams right now :D So maybe it's also a "single dev quirk".
Another point is that in a sense, learning to code goes from being told "you are using the_wrong_abstraction/this_abstraction_the_wrong_way/no_abstraction_where_you_should_have", to telling it to others/ourselves.
Since the number of knowable abstractions seems to be "at least one more than I already know", agents can actually be helpful in learning.
After a certain threshold, it basically zeros in a specific domain, but on novel domains agents taught me abstractions, when nudged towards doing that.
Great metaphor. When I hear people claim 20x productivity with AI assistance, I imagine a Tetris game where pieces fall 20x faster.
As you say, those lines still have to clear.
That probably would not be a fun game to play lol
I love this analogy, and I find it darkly hilarious that most sibling commenters don't seem to understand. Maybe you need to have worked within a million-line codebase to get it.
The only way to "clear the lines" in software is to eject them from the main codebase and into imported libraries with stable, well-documented, well-tested APIs that you very rarely if ever (security vulnerabilities?) need to touch after "stabilizing" them. Great public examples: the Go standard library, https://github.com/spf13/viper , https://github.com/uber-go/zap . Viper and zap combined are more than 20,000 lines of code (according to cloc) that I don't need to read or understand how they work - their lines have been "cleared" and all I need to know is the abstraction.
Half the joy to be found when working within massive codebases is successfully clearing lines.
So as someone managing LLMs you need to put those processes in place too. The risk is that one tries to do too much and loses overview / insight. Focusing on getting the tower tall instead of sturdy, if you will.
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.
It’s mostly AI-written patterns based on my personal prompts/observations.
And here is the skill for organizing the pattern languages for a single project:
https://github.com/apinstein/skills/tree/main/skills/pattern...
I haven’t really battle tested these so hard yet but it’s a fun concept and really should get back to organizing them more intentionally. Happy to share this early phase just cause it’s cool to see the interest.
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...
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.
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
"we can, so we should".
It ended badly.
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
https://blog.est.im/2026/stderr-06
https://news.ycombinator.com/item?id=46669591
Padmé: "For the better, right?"
Anakin: (gazes in silence)
Padmé: "For the better, right?"
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?
Why being one (I see as collaborative) was it not desired? Interpretations? Why is it seemed *more* harmful rather than good?
1. Perhaps with a handful of skyscrapers sprinkled in.
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.