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.
Intelligence is learning to avoid using childish cliches, unless your intention was to mislead. Categorisation and understanding dependencies are hard enough problems already.
At the supermarket or taxation (Nix v. Hedden) tomatoes are a vegetable.
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
What made Lisp cool and powerful goes away when you do it through an LLM.
It is not clear at all to me that other languages "demand much more effort" for the same end result.
It is clear that many non-lisp programmers value syntax, and many lisp programmers don't. Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp. I'm still awaiting psychological studies on this, but the rift is so large, I think there may be some significantly different brain processing going on between the two groups.
To your point, yes, it is also clear that, to the extent that lisp can match the productivity of other languages, whether it exceeds them or not, one of the tools that is needed to achieve this productivity boost in lisp is heavy usage of homoiconicity, and this results in every serious lisp program being a collection of DSLs, each of which is only understood by one person or very few people.
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.
Catch-22 is it's still important to know the fundamentals so you know what to ask for, but if you don't know the esoterica, the model is eventually going to make an assumption and screw things up. And the models don't have much taste either in prose, or in coding/comment style.
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.
Thanks for mentioning Peter Naur’s Programming as Theory Building (1985).
I would add Fred Brooks and his The Mythical Man-Month.
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.
Which ones? PostgreSQL doesn't have HA in core.
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?
I think the next time I see "LLMs" and "Understanding" in the same sentence, I am going to lose it....
Then I think you should check in with your favorite mental health provider before you become a danger to yourself or others.
Simply put LLMs do understand some things within their crystalized intelligence. Your anthropocentric mind may not accept this, but one day it will. As LLMs have a very short context window in relation to their stored knowledge they have very limited plastic intelligence to change their minds or adapt. All of which is flushed away at the end of a session. It would be like living without the ability to turn your short term memory into new long term memories.
I would gladly use another word for what LLMs can do, but the world at large has not adopted any. The definitions we use around intelligence, comprehension, understanding, consciousness, and sapitence have already been failing us for some time before LLMs as our scientific understanding of biology has increased over the decades as it is. I am one for more exacting definitions when they exist, but humans seem to barely understand the inner workings of our own minds, in large such words escape us.
An LLM has zero understanding of "my", "want", or "cookie" because an LLM has no id/ego, has never felt desire, and has never eaten a cookie.
HN would commonly recommend reading the book Blindsight here.
Moreso, all you've done is recreate the Searle Chinese Room thought experiment which gets bounced around with no means of deciding if it reflects reality or not.
How'd your toddler do at IMO last year?
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.
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.
Padmé: "For the better, right?"
Anakin: (gazes in silence)
Padmé: "For the better, right?"
For example, yesterday I came across some unit tests that didn't have error messages in their assertions. Normally, it takes me ~10 minutes to fix a handful of tests in this situation. In this case, I gave a 2-3 sentence prompt, went to the bathroom, and reviewed the result after I washed my hands. Saved me a bunch of time!
I encourage you to accept a feeling of "imposter syndrome" when using it, and keep trying new things with it. Don't feel like you have to be hands off, except when you're confident that you can be. (IE, if you think you need to spend 30+ minutes on mindless refactoring, see if you can explain it to an agent and then look at HN while it runs. You might get a good result, otherwise, it probably was time for a break anyway.)
BTW: It's important to try different models. The Claude 5.0 models are slow and give me bad results, so I'm sticking with 4.x for now.
I finally learned to let go of the code. I dont even run my C++ editor anymore.
I run frequent code and architectural reviews. Its awesome.
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.
Your test suite doesn’t cover all workflows. It doesn’t cover every combination of actions a user can take. So every big AI refactor while change some of those.
If this is happening frequently, your software will feel like a janky piece of unusable crap.
But this is just bad vibecoding? This would be bad if humans did it too. With agents or humans, you need to coordinate.
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
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?
Is that because of the technology or because of who you were at the time?
The tricky part here is that you can't tell if a once-topmost part of the tower is sturdy until a great deal more tower is resting on it. Well, now a lot the economy is resting on little other than AI dreams. Your move, rational people.
1. Perhaps with a handful of skyscrapers sprinkled in.
Why being one (I see as collaborative) was it not desired? Interpretations? Why is it seemed *more* harmful rather than good?
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.
"we can, so we should".
It ended badly.
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.
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 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?
We need some way to make AI-driven coding strive for parsimony.
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.
What's more profitable, optimizing for inference time or optimizing to increase inference time by increasing token count?
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.
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.
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.
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.