The Tower Keeps Rising(lucumr.pocoo.org)
lucumr.pocoo.org
The Tower Keeps Rising
https://lucumr.pocoo.org/2026/7/13/the-tower-keeps-rising/
272 comments
> 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.
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.
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.
We need some way to make AI-driven coding strive for parsimony.
Why would it? It has optimized what it was built to optimize: this is the token-selling industry. Take note that the people hawking the dream of a gold rush are not actually mining but selling shovels
Same issue happens in models trained by organizations who aren’t selling tokens. I believe it’s because being parsimonious is simply harder. Achieving the task at hand independently and declaring the job done is easier than building an abstraction and reconciling between every use case.
Agreed. I've noticed this happens without fail in any project driven primarily by "tickets" and "sprints". Finishing the immediate task ends up taking precedence over future concerns that cover a wider scope. On the other end of the spectrum it's easy to spend too much time at the beginning humming and hawing about the best, most future proof design, because you just know you're not going to be able to easily fix it later. As is often the case, the right approach is somewhere inbetween, which is partly why it's a hard process to automate. you're constantly making judgement calls.
I have a vaguely-relevant war story.
1998 - Huge business, re-writing some vital piece of the platform in the middle of Y2K. Contract coders are expensive but also the only available people to throw at this.
The architect had mapped out the entire system down to class/method level. They'd produced a huge list of classes and methods that needed to be built. So the company hired a bunch of contract coders to build said classes and methods, including your humble protagonist. We were each given a list of methods to write up - parameters, operation, expected output. We wrote them up, and ticked them off the list. We were not briefed on how they interacted. There were no tests that we could run. There was apparently no-one checking that what we wrote in the method actually matched the spec. This was before git, so version control was extremely rough, and also before JIRA (iirc the list was an Access database).
We all realised very quickly, like the first week, that this entire project was doomed. But we were getting paid a lot of money to do this, so we just did it. It got really boring really quickly. Every day we wrote a bunch of methods, and next day got a list of the next set of methods to write. The lists just kept coming, with no idea how long the master list was, or how the classes interacted with each other, or how the system actually worked, or anything.
I left after a month. The money was good, but the boredom was driving me insane.
I learned later from friends who stayed that the whole project was canned a couple of months later when it became obvious that this was a complete waste of money and would never work.
Whenever I see a project manager staring at JIRA instead of talking to their people or looking at the codebase, I'm reminded of this project. And your comment reminded me of that ;)
1998 - Huge business, re-writing some vital piece of the platform in the middle of Y2K. Contract coders are expensive but also the only available people to throw at this.
The architect had mapped out the entire system down to class/method level. They'd produced a huge list of classes and methods that needed to be built. So the company hired a bunch of contract coders to build said classes and methods, including your humble protagonist. We were each given a list of methods to write up - parameters, operation, expected output. We wrote them up, and ticked them off the list. We were not briefed on how they interacted. There were no tests that we could run. There was apparently no-one checking that what we wrote in the method actually matched the spec. This was before git, so version control was extremely rough, and also before JIRA (iirc the list was an Access database).
We all realised very quickly, like the first week, that this entire project was doomed. But we were getting paid a lot of money to do this, so we just did it. It got really boring really quickly. Every day we wrote a bunch of methods, and next day got a list of the next set of methods to write. The lists just kept coming, with no idea how long the master list was, or how the classes interacted with each other, or how the system actually worked, or anything.
I left after a month. The money was good, but the boredom was driving me insane.
I learned later from friends who stayed that the whole project was canned a couple of months later when it became obvious that this was a complete waste of money and would never work.
Whenever I see a project manager staring at JIRA instead of talking to their people or looking at the codebase, I'm reminded of this project. And your comment reminded me of that ;)
Crazy to think that if it was specced out so well, a modern LLM would make short work of the whole thing. The things we used to get paid for!
lolol you're joking right? as a joke it's funny. If you think thats really what it sounds like when a project's design is well-understood... ... ...
Poe's law continues to be a bitch...
There are things inbetween, like a mailing list.
Today we all can have those famous Torvalds rages, and that is very affordable.
Today we all can have those famous Torvalds rages, and that is very affordable.
Labs are trying to make long-horizon work. Even if you're a coding agent, adding more and more surface area is distracting to that goal. There is reason that RL over long traces should, at least in principle, optimize for building in ways that help the result fit in the model's context window.
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.
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.
Does that not sound a little silly to you when you say it? Should I invest in becoming a memory athlete as a way of becoming a better software engineer? ...or should I learn how to build and use tools?
While I don't disagree, memory certainly was more of a restrictions on us humans than it is on llms. Therefore, the answer may not be as obvious as it seems. We build abstractions to reduce (memory) footprint of features, right?
Humans built codebases many millions of lines long, well before LLMs existed. Human memory has not been a restriction on us in a long time.
Look at all the libraries full of books we've built. It's useful for more than mere training sets.
Look at all the libraries full of books we've built. It's useful for more than mere training sets.
I think the trick here is plural; I guarantee no single human knows all 1 million lines. Note this is different than knowing how to orient yourself in a million line codebase quickly.
The limit here I think the ancestor comments are getting at is cognitive load, which is real and measured. We only have so much memory to devote to a "stack" when executing, and it's usually quite constrained.
The limit here I think the ancestor comments are getting at is cognitive load, which is real and measured. We only have so much memory to devote to a "stack" when executing, and it's usually quite constrained.
Note this is different than knowing how to orient yourself in a million line codebase quickly.
Hence my library mention. Humans have been doing this for millennia: orienting ourselves within a library (the physical kind, full of books) and calling upon its information resources as needed to accomplish tasks (research). Ultimately, it's all just one big cache hierarchy. Your short term memory, your long term memory, the book in your hands, the desk at the library, the nearby shelves, the card catalogue, the stacks, the inter-library loan system.
To manage it all, we humans have developed our abilities for abstraction. When we build clean, tight abstractions we reduce our cognitive load. Perhaps the best abstraction we've built so far is the TCP/IP and web stack. We don't need to care at all about the hardware details of a server in order to talk to it. It's such a powerful and airtight abstraction that we take it for granted.
I'd like to hear from more people who have spent a lot of time building with LLMs, because so far what people are saying is that these models do not have the ability to reason about and build the kind of marvellous abstractions us humans have built.
Hence my library mention. Humans have been doing this for millennia: orienting ourselves within a library (the physical kind, full of books) and calling upon its information resources as needed to accomplish tasks (research). Ultimately, it's all just one big cache hierarchy. Your short term memory, your long term memory, the book in your hands, the desk at the library, the nearby shelves, the card catalogue, the stacks, the inter-library loan system.
To manage it all, we humans have developed our abilities for abstraction. When we build clean, tight abstractions we reduce our cognitive load. Perhaps the best abstraction we've built so far is the TCP/IP and web stack. We don't need to care at all about the hardware details of a server in order to talk to it. It's such a powerful and airtight abstraction that we take it for granted.
I'd like to hear from more people who have spent a lot of time building with LLMs, because so far what people are saying is that these models do not have the ability to reason about and build the kind of marvellous abstractions us humans have built.
Fair, my mistake.
I've built a lot with LLM's, my experience sort of but not really tracks that. I've had to course correct a few bad abstractions but the larger the code base becomes the better it seems to be at reusing things. Maybe this is because of types, or spec-first development (with OpenAPI), or black box integration testing - but also maybe not. But generally I have to think about the abstractions and let the LLM fill in the details with rare exception.
I've built a lot with LLM's, my experience sort of but not really tracks that. I've had to course correct a few bad abstractions but the larger the code base becomes the better it seems to be at reusing things. Maybe this is because of types, or spec-first development (with OpenAPI), or black box integration testing - but also maybe not. But generally I have to think about the abstractions and let the LLM fill in the details with rare exception.
I built a web-OS, a graphical IDE, and a version control system to replace git, all in about 40,000 lines of highly abstracted Javascript. If you're thinking about how important it is to be able to maintain million-line codebases, I suspect you might have substituted a metric for the actual end goal.
That looks like a nice feat, can you share a repo?
That said, reality at scale always come with details that will break the model, and the main roads when it happens are to ignore/reject any change proposal in the model, go in the mystic quest to reach a model that will fit it all including these new cases with an elegant simple solution, or accommodate special cases on the side until it grows too big or just percolate too fast in the main part to let it be sustainable.
That said, reality at scale always come with details that will break the model, and the main roads when it happens are to ignore/reject any change proposal in the model, go in the mystic quest to reach a model that will fit it all including these new cases with an elegant simple solution, or accommodate special cases on the side until it grows too big or just percolate too fast in the main part to let it be sustainable.
While you’re not wrong, this is also simply mechanical, the context window is the root problem here, if the llm doesn’t happen to have read implementation n of a thing that it needs that session, well now you have n+1 implementations.
All the open weight models, that are given away for free, across orgs and even nations, are using the same methods to achieve high performance.
What's more profitable, optimizing for inference time or optimizing to increase inference time by increasing token count?
What's more profitable, optimizing for inference time or optimizing to increase inference time by increasing token count?
The question is that if it can go beyond the upper limit of human mind complexity, would we be able to understand it or use it?
I cannot remember who it was but there was an author who was traveling with their dog. They noticed that their dog would always pee on various tree to mark them as their territory. On their travels they ended up need some giant Red wood trees and figured, "I want to give my dog the ultimate claim of territory."
So he took his dog up to the Red wood tree and it did nothing, instead the dog wandered over to a smaller sapling and peed on that instead. The problem was the Red wood was so big and alien to the dog, it didn't recognize it as a tree.
I do wonder how many things are like that in our universe, that even if we could see them, we just wouldn't be able to understand it because it just goes beyond what we are capable of understanding. We think we have a grasp of the universe and use models to codify it but that is no guarantee that we can truly 'get it'.
Could higher level AI code be like that, would we know when we see it?
I cannot remember who it was but there was an author who was traveling with their dog. They noticed that their dog would always pee on various tree to mark them as their territory. On their travels they ended up need some giant Red wood trees and figured, "I want to give my dog the ultimate claim of territory."
So he took his dog up to the Red wood tree and it did nothing, instead the dog wandered over to a smaller sapling and peed on that instead. The problem was the Red wood was so big and alien to the dog, it didn't recognize it as a tree.
I do wonder how many things are like that in our universe, that even if we could see them, we just wouldn't be able to understand it because it just goes beyond what we are capable of understanding. We think we have a grasp of the universe and use models to codify it but that is no guarantee that we can truly 'get it'.
Could higher level AI code be like that, would we know when we see it?
Excellent post.
If we would be able to act that consciously, humanity would be flourishing without anyone sent to war or starvation.
It doesn't look like we are that bright, at least collectively. And if they are individual which are really above everyone else on that matter and the rest, like maybe you but definitely not me, then their individual power seems to be unable to move us all away from our collective ill habits.
It doesn't look like we are that bright, at least collectively. And if they are individual which are really above everyone else on that matter and the rest, like maybe you but definitely not me, then their individual power seems to be unable to move us all away from our collective ill habits.
> The upper bound on program complexity used to be the power of the human mind.
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.
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.
They said "the" human kind, not "one" human mind. Even with structures, rules, and other tools, we are limited in the amount we can abstract, comprehend, and communicate. As projects get larger, we inevitably see a friction develop where coordination breaks down and we turn to isolation and responding to failures at the boundaries. This is where complexity in design of an individual system ends. Larger ecosystems aren't designed or coordinated - they emerge organically as each tries to adapt to the other. If only we could handle such complexity, we could design efficient systems that don't suffer from the same waste.
Fair enough.
I do worry what that will mean for projects such as Linux though. Not that I think it will die or anything, but rather that it will become so fragmented that forward movement ceases.
I do worry what that will mean for projects such as Linux though. Not that I think it will die or anything, but rather that it will become so fragmented that forward movement ceases.
We need programming languages that can express the problems at densities similar to the English language prompts.
So: better modularity.
https://blog.metaobject.com/2019/02/why-architecture-oriente...
So: better modularity.
https://blog.metaobject.com/2019/02/why-architecture-oriente...
A friend of mine built just built a project for doing something like that, although it's built on enforcing a spec rather than elegance: https://medium.com/@joeldg/architecting-out-of-the-vibe-how-...
That's an interesting question.
What happens if we take the most abstract libraries in any given field - and:
1. Bound to the llm to only use those as building blocks. Does it affect his reasoning ? Will it think more abstractly ?
2. Train the llm on those, so maybe it will get a feel for abstraction ?
What happens if we take the most abstract libraries in any given field - and:
1. Bound to the llm to only use those as building blocks. Does it affect his reasoning ? Will it think more abstractly ?
2. Train the llm on those, so maybe it will get a feel for abstraction ?
>We need some way to make AI-driven coding strive for parsimony.
This is the single reason why my experience with agentic development honestly kind of sucks, and wastes so much of my time.
The simplest prompt can result in the most verbose garbage ever produced, and scope-creep nobody's every seen before.
AI has a huge cognitive load problem right now. It's no wonder why so many devs say they're completely exhausted after a few hours, and not in ways they were before they picked up agentic dev.
This is the single reason why my experience with agentic development honestly kind of sucks, and wastes so much of my time.
The simplest prompt can result in the most verbose garbage ever produced, and scope-creep nobody's every seen before.
AI has a huge cognitive load problem right now. It's no wonder why so many devs say they're completely exhausted after a few hours, and not in ways they were before they picked up agentic dev.
The Allegorical Agent-Aeon?
[deleted]
> "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 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.
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.
It's perhaps how some humans code but frankly if you have those people employed to build software for you, you have big problems
That's some idealistic nostalgia. Software is generally poorly built today, and it's evidently not big enough a problem to fix.
Large companies that can keep themselves alive with regulatory capture - absolutely. For smaller companies that need to compete the software quality and ongoing cost of maintaining that software is a real consideration.
That isn't to say software is perfectly built, but it's usually pragmatically built to balance costs of development and correctness - well chosen abstractions let us push up both qualities at once.
That isn't to say software is perfectly built, but it's usually pragmatically built to balance costs of development and correctness - well chosen abstractions let us push up both qualities at once.
I think every type of company has ways to workaround software quality. B2B can tend to define the bug as the feature or too low priority.. B2C can often decide backwards compatibility simply doesn't matter and just replace things with other things with only some actual feature overlap, etc.
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.
Also a human has to explain the code. There is a social contract and producing slop gets you fired. Especially as you produce it much slower than an LLM.
And the human has to explain it at 2 tokens/sec (average speaking speed ~130-150 wpm). That's another constraint against slop - humans need to be able to explain their code succinctly.
> I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear.
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.
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.
Also through LLMs we now have pieces that are strangely-shaped and are 20x larger...
That probably would not be a fun game to play lol
That probably would not be a fun game to play lol
Yeah I would love to sit down and see what exactly one of the 20x people us doing. Either I spot the flaw (99%) or there is some utter magic they are doing (1%) which I could try to learn.
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.
I believe similar.
Maybe not exactly the same thing, but I think one related representation of this in any good codebase is documentations in the code: Good documentation always focuses on the why and not the what. i.e. things that are not represented by or representable in code. It may describe not only why a certain choice was made, but also why not something else. In general, the whole point of these documentation is to account for things that are beyond what can be understood from just reading the codebase including other existing documentation, that you may never even imagine with all the tokens in the world otherwise, which were yet a critical part of our coding choices.
If we are to believe that LLMs can build complex systems, then it's equivalent to saying that LLMs can make similar decisions equally well without any of that... which also then implies that we essentially never needed these documentation to begin with other than as redundancy for human needs.
Maybe not exactly the same thing, but I think one related representation of this in any good codebase is documentations in the code: Good documentation always focuses on the why and not the what. i.e. things that are not represented by or representable in code. It may describe not only why a certain choice was made, but also why not something else. In general, the whole point of these documentation is to account for things that are beyond what can be understood from just reading the codebase including other existing documentation, that you may never even imagine with all the tokens in the world otherwise, which were yet a critical part of our coding choices.
If we are to believe that LLMs can build complex systems, then it's equivalent to saying that LLMs can make similar decisions equally well without any of that... which also then implies that we essentially never needed these documentation to begin with other than as redundancy for human needs.
I can't really explain it but when I am working with a system in my head it's not represented as text. It has an almost physical dimension to it similar to imagining how an engine works or what have you. This is obviously beyond the grasp of an LLM.
Interesting! Makes me curious what you do for work.
The real understanding builds on not knowing. Once I realise I don't know something I cease thinking and start watching the thing. Then somehow I understand.
We do have a mechanism similar to LLMs but it provides existing knowledge; it's a search mechanism, basically. New knowledge happens when we turn that mechanism off.
We do have a mechanism similar to LLMs but it provides existing knowledge; it's a search mechanism, basically. New knowledge happens when we turn that mechanism off.
LLMs can learn but only by copy paste into that tiny context. Actually theoretically they could self fine-tune but it would be very expensive/slow.
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.
There is no Moore’s law for AI that shows that the previous rate of improvement will likely apply to the future. It’s all wishful thinking.
There is bunch of rich and powerful assholes trying to protect their investments.
I am pretty sure rate of improvement will be there quite long in the future — even if it will be smoke and mirrors ;)
I am pretty sure rate of improvement will be there quite long in the future — even if it will be smoke and mirrors ;)
> 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.
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.
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
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.
Sorry, the lines have to clear what? Surely there must be some kind of constraint on "lines" that they have to overcome.
The lines (rows) in Tetris have to become complete and then disappear to make room for the new falling pieces.
In code the thing has to become stable, can't just keep packing more and more noise onto it.
In code the thing has to become stable, can't just keep packing more and more noise onto it.
Absolutely this: and it needs to ideally become the kind of set of abstractions that mean that every new thing added uses less net-new surface area than it would without them.
[deleted]
I mean that at the bottom of the Tetris board, the lines need to vanish so that the Tetris board keeps moving downward and doesn't grow unbounded.
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.
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.
> two orders of magnitude more productive
Shipping 100x more features per day?
Shipping 100x more features per day?
100x faster towards becoming an email client
Yes.
Do you have specifics? It would be interesting to see what kind of improvements are possible.
I just see in my usage that I can release tens of features a day, whereas I'd be able to release one or two a day usually. I don't know if it's 100x, but it's definitely more than 10x.
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.
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.
Thanks for the detailed explanation of your process, I think I'll try it out.
Can you show us the 10s of features you’re releasing daily now?
I made this in two days:
https://www.writelucid.cc/
https://www.writelucid.cc/
Does this speed of development only apply to the early stages, or will it slow down as the codebase grows? I have yet to see these 100x improvements (and the claims themselves keep getting bigger) on anything more than prototype scale, rather than month-long projects.
No doubt AI boosters will claim we have found an O(1) productivity enhancer that is somehow two orders of magnitude better than anything else before. This is entering lunacy territory.
No doubt AI boosters will claim we have found an O(1) productivity enhancer that is somehow two orders of magnitude better than anything else before. This is entering lunacy territory.
To me, it applies as long as you can keep the state of the system in your head (so, same as we always did architecture).
For example, I built this over a month or so and never hit a slowdown or quality issue:
https://github.com/skorokithakis/stavrobot
For example, I built this over a month or so and never hit a slowdown or quality issue:
https://github.com/skorokithakis/stavrobot
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.
Although I suspect models from Google, Facebook and Microsoft can be trained on their massive internal codebases. Whether they are is another question.
I’m not sure you’d see that big of a difference in quality. There is quite a bit of cruft that can accumulate when you know the code will never be public.
But, you would probably see a difference of scale and architecture. Larger projects that need better organization are probably more likely to be in private codebases (Linux excluded). So you might be right about the lack of private code in LLM being an issue.
But, you would probably see a difference of scale and architecture. Larger projects that need better organization are probably more likely to be in private codebases (Linux excluded). So you might be right about the lack of private code in LLM being an issue.
I have another thought on this:
At least in the past (before LLM-based code contributions got socially acceptable in some circles), in open-source project you often got very direct comments on code that was of bad quality. Yes, this was always a little bit abrasive, but it did a lot for the code quality.
For internal applications used at companies, such an abrasive behaviour is typically not accepted ("not a team player" (as if this is something bad), offended snowflakes, "not socially adept" etc.). Thus the code quality suffers quite a lot for internal applications.
Have you ever thought why salespeople have such an easy time selling some LLM for coding to big companies? Because the code quality of many internal applications is so bad, which makes even shitty LLM slop code often better than what is there.
At least in the past (before LLM-based code contributions got socially acceptable in some circles), in open-source project you often got very direct comments on code that was of bad quality. Yes, this was always a little bit abrasive, but it did a lot for the code quality.
For internal applications used at companies, such an abrasive behaviour is typically not accepted ("not a team player" (as if this is something bad), offended snowflakes, "not socially adept" etc.). Thus the code quality suffers quite a lot for internal applications.
Have you ever thought why salespeople have such an easy time selling some LLM for coding to big companies? Because the code quality of many internal applications is so bad, which makes even shitty LLM slop code often better than what is there.
Do you believe "micro services" can make a comeback?
local daemons with an exposed API, each daemon vibe coded?
Microservices don’t reduce complexity, they just move it to the interactions between services. You have the same fundamental design problem.
In other words, if you can’t design a modular monolith, you can’t design a set of microservices.
In other words, if you can’t design a modular monolith, you can’t design a set of microservices.
> if you can’t design a modular monolith, you can’t design a set of microservices.
I somewhat disagree:
Yes, it is possible to design a modular monolith, but thinking about the system in terms of a "minimum viable service" (but keep an eye on "viable", otherwise you can easily get into the "interaction problem") makes it much easier.
This is very similar to how you can write programs with no implicit state in a imperative programming language, but doing this in a pure functional programming language such as Haskell is much easier.
I somewhat disagree:
Yes, it is possible to design a modular monolith, but thinking about the system in terms of a "minimum viable service" (but keep an eye on "viable", otherwise you can easily get into the "interaction problem") makes it much easier.
This is very similar to how you can write programs with no implicit state in a imperative programming language, but doing this in a pure functional programming language such as Haskell is much easier.
Unless we are planning to deploy them all individually to an expensive serverless platform like Lambda, the coordination challenges and overprovisioning are going to more than outweigh whatever architectural benefit you reap (in human-centred development, micro services are solving an entirely different problem - Conway's Law)
What problem would it solve? They're still part of a larger system ultimately. Sure, smaller codebases with more focused scope can be good for e.g. human individuals and LLMs, but there's multiple ways to achieve that that don't require a network boundary.
Microservices are about separate deployment. Regarding separating the development/maintenance of components, you can achieve that in a monolith by composing it out of corresponding modules/libraries with defined APIs. That’s good practice anyway.
Not microservices, but something more akin to FaaS into a mesh, with a backing domain logic library.
Sure, why not? The same reasons they succeeded originally will work just as fine now.
Please no.
Lemme guess, you were in favour of monolithic systemd too?
All have its space.
Small team, do monolith or you'll stop moving.
Big teams, be wary of Conway's law, and don't fight it, probably some services will emerge.
My laptops used to be lean, mean fighting machines until that happened.
Hah Tetris that really matches my "everyone has to draw their own line constantly".
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
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
I felt the same on Feb. Wrote a blog about it
https://blog.est.im/2026/stderr-06
https://news.ycombinator.com/item?id=46669591
https://blog.est.im/2026/stderr-06
https://news.ycombinator.com/item?id=46669591
Assembly programmers made the same argument. It seems that we revisit this same trope each time the practice of software engineering undergoes a paradigm shift.
Some have a harder time with the transition than others.
Some have a harder time with the transition than others.
Are you implying the author of one of the best, if not the best performing agentic coding harness is having a hard time with vibecoding as a new paradigm?
I’d look him up.
I’d look him up.
Someone could make the best agentic coding harness in the world and still have a hard time with the drastic changes that are happening in their profession. The two aren't mutually exclusive.
Is it really the same argument? I think there's enough of people that will argue that there will be no need to come together to collaborate, just rally a bunch of agents and you can build whatever non-trivial stuff you can imagine.
> compared to languages which demand much more effort to get anything substantial done.
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.
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.
> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp.
I can guarantee you that most of these simply didn't go far enough; they had their "minds blown" with too little. They latched onto a highlight or two, found a way of sort doing that in C++ or Javascript and moved on.
There are people who have had their "minds blown" by time/mass dilation of special relativity, or phenomena in quantum physics, who don't actually know anything about physics; they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.
For those of us sticking with the Lisp program, in one way or another, it was more of a sequence of small revelations in a progression of topics. Oh, that's a good way of representing that; that is pretty nicely thought out; that fits well with that; they had that how many decades ago? Sheesh; ...
Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.
I can guarantee you that most of these simply didn't go far enough; they had their "minds blown" with too little. They latched onto a highlight or two, found a way of sort doing that in C++ or Javascript and moved on.
There are people who have had their "minds blown" by time/mass dilation of special relativity, or phenomena in quantum physics, who don't actually know anything about physics; they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.
For those of us sticking with the Lisp program, in one way or another, it was more of a sequence of small revelations in a progression of topics. Oh, that's a good way of representing that; that is pretty nicely thought out; that fits well with that; they had that how many decades ago? Sheesh; ...
Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.
> I can guarantee you that most of these simply didn't go far enough;
And I can guarantee that I knew, when I wrote my comment, that I was summoning this very "No true Scotsman" argument.
> they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.
It always superciliously starts with how true lisp people are the most brilliant ever.
> Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.
And is eventually undermined by an admission of cognitive inflexibility, although not usually so quickly or in the same comment. Good job!
And I can guarantee that I knew, when I wrote my comment, that I was summoning this very "No true Scotsman" argument.
> they couldn't work out how far a canon ball will land fired at a 45 degree angle with a certain velocity, though they can crack jokes about Schrödinger's cat.
It always superciliously starts with how true lisp people are the most brilliant ever.
> Then once you start grappling with the Lisp issues, and kick the rock farther down the road, even in some small way, you are invested.
And is eventually undermined by an admission of cognitive inflexibility, although not usually so quickly or in the same comment. Good job!
> Even many people who programmed enough lisp to have their minds blown and expanded still prefer not to program in lisp
For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp
If you then optimize for employability, which I assume most developers do (not all, but a large percentage), you might end up with not that many people practicing lisp regularly
For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp
If you then optimize for employability, which I assume most developers do (not all, but a large percentage), you might end up with not that many people practicing lisp regularly
> For me, the answer to this is economics. Even if you love lisp, there are way more companies hiring for stacks that don’t include lisp
Certainly. But why would that be? It couldn't possibly be that the programmers already there built a system using the tools of their choice, and that system is now running well and deemed maintainable enough they require additional developers for the same language, could it?
Sometimes, of course, companies change their implementation language. The most famous cases I know of this are Viaweb and reddit, where the companies moved away from lisp. The company's main motive in this, of course, is making money. If they have a good product that is deemed maintainable, why would they piss off the original team, who probably chose the language, by switching languages?
Many programmers have worked in lisp. Studies have shown that programmers routinely learn new languages and somewhat forget old ones; older programmers are typically only currently proficient in as many languages as younger ones.
A company with a successful product is going to attempt to leverage that success. Whether leveraging it looks like incrementally improving it, or like treating it as a prototype and throw it out, will typically be a long conversation between developers and management. Typically incremental improvements are greatly preferred; it is only when all stakeholders become convinced that a fresh start is required that massive changes like implementation language will take place.
The calculus, of course is changing with LLMs. See, for example, the recent migration of bun away from zig. That rewrite was spearheaded by a massively effective lone developer, the exact persona that is claimed to always prefer lisp. Sadly, he chose rust.
Certainly. But why would that be? It couldn't possibly be that the programmers already there built a system using the tools of their choice, and that system is now running well and deemed maintainable enough they require additional developers for the same language, could it?
Sometimes, of course, companies change their implementation language. The most famous cases I know of this are Viaweb and reddit, where the companies moved away from lisp. The company's main motive in this, of course, is making money. If they have a good product that is deemed maintainable, why would they piss off the original team, who probably chose the language, by switching languages?
Many programmers have worked in lisp. Studies have shown that programmers routinely learn new languages and somewhat forget old ones; older programmers are typically only currently proficient in as many languages as younger ones.
A company with a successful product is going to attempt to leverage that success. Whether leveraging it looks like incrementally improving it, or like treating it as a prototype and throw it out, will typically be a long conversation between developers and management. Typically incremental improvements are greatly preferred; it is only when all stakeholders become convinced that a fresh start is required that massive changes like implementation language will take place.
The calculus, of course is changing with LLMs. See, for example, the recent migration of bun away from zig. That rewrite was spearheaded by a massively effective lone developer, the exact persona that is claimed to always prefer lisp. Sadly, he chose rust.
Au contraire if typescript and rust didn’t steal the whole show it’d be a great time to be a lisp LLM pilot: agents can explain pretty much everything without any confabulations nowadays, so the understanding problem essentially goes away, if you care, which is exactly the point of the article if you ask me.
But at that point why use Lisp (which LLMs have been so far still to struggle to get matching parens every now and then)
What made Lisp cool and powerful goes away when you do it through an LLM.
What made Lisp cool and powerful goes away when you do it through an LLM.
I have a web framework running with a lisp interpreter built in, and I think it unlocks a LOT for the LLMs.
lisp can do things that make the currently accepted as standard best practice software engineering processes redundant, but it needs a different set of processes which I’m not sure are written about anywhere since apparently nobody is running with e.g. hot patching of application code
I'm doing fully interpreted Lisp with the AST stored in Postgres. I can access the REPL remotely and I honestly dont know if I'm ever going to build an API or CLI again
This sounds super interesting. Do you have any blog or pointers where I could read more about this?
https://pricklypear.rocks/welcome
https://pricklypear.rocks/code
Just to be clear this is not a release, lol, I just made it to show a couple buddies. My one friend was saying he learned a lot just by reading code and pointing Claude at it and asking questions about what he didn't understand. It is provided as-is with no warranty, or installation instructions. If you really get stoked about it I could probably clean up multi user stuff a bit to get you logged on, but I think even just the idea is pretty neat.
Just to be clear this is not a release, lol, I just made it to show a couple buddies. My one friend was saying he learned a lot just by reading code and pointing Claude at it and asking questions about what he didn't understand. It is provided as-is with no warranty, or installation instructions. If you really get stoked about it I could probably clean up multi user stuff a bit to get you logged on, but I think even just the idea is pretty neat.
If you got it popular you could license it to AWS and sell it as an Elastic Lisp Machine or something
> 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.
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.
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.
I had a discussion with folks at work about what information is worth retaining in the face of AI doing everything for us. A lot of what we have in our heads to qualify as "domain experts" is pretty esoteric. How to invoke command line tools, gotchas because library A uses one convention over library B, AWS vs GCP; so much is specific to a tool rather than a method. There are also a lot of entrenched tools that are effectively unfixable due to the risk of breaking changes, so you have to shrug and accept + learn that's how it works.
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.
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.
Yes I think the problem is not that AI "has all the answers". It is that we don't have "all the questions". If we don't understand the whole of what AI produces for us, we can't ask it to make parts of it different. We are not in control any more of what exactly is produced, and we don't want to give AI all the control, because then it would not be doing what we want it to do.
Therefore it is critical that whatever AI produces is understandable to us humans. That is why we must demand that AI tools and agents produce "well designed" well-structured software. That's the bottlenexk to progress I think. Even AI can't deal with exponential complexity explosion.
Therefore it is critical that whatever AI produces is understandable to us humans. That is why we must demand that AI tools and agents produce "well designed" well-structured software. That's the bottlenexk to progress I think. Even AI can't deal with exponential complexity explosion.
And what's ironic is that a lot of those layers and complexity were added with the stated goal of making it easier for average developers to build applications.
That is the nominal motive, but I think that the real motive is that it makes it easier for average developers to pile on more complexity.
Back in the day we just accepted technical constraints that didn’t prevent us from doing anything mission critical. So the UIs weren’t paragons of personal expression, probably there was only one database which didn’t have any scale out features at all, and nothing scrolled infinitely. And I do think that tended to make things easier to fit into your head, because the number of distinct APIs and module interactions you needed to understand was much smaller.
But also none of it was integrated with Alexsirtanapilot, so everyday life was an endless misery.
Back in the day we just accepted technical constraints that didn’t prevent us from doing anything mission critical. So the UIs weren’t paragons of personal expression, probably there was only one database which didn’t have any scale out features at all, and nothing scrolled infinitely. And I do think that tended to make things easier to fit into your head, because the number of distinct APIs and module interactions you needed to understand was much smaller.
But also none of it was integrated with Alexsirtanapilot, so everyday life was an endless misery.
Amen.
Drowning in complexity. Paralysis of choice.
I read a comment (joke) that if you want to follow all LLM development you should have to be unemployed.
Drowning in complexity. Paralysis of choice.
I read a comment (joke) that if you want to follow all LLM development you should have to be unemployed.
> 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.
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.
The complexity of coordinating a project involving more than one entity is, of course, an issue across all industrial sectors—just look at the construction industry.
Thanks for mentioning Peter Naur’s Programming as Theory Building (1985).
I would add Fred Brooks and his The Mythical Man-Month.
Thanks for mentioning Peter Naur’s Programming as Theory Building (1985).
I would add Fred Brooks and his The Mythical Man-Month.
> It's not really news, though. Programming as Theory Building (Peter Naur) was published in the 80s, I think?
The news is that Agentic Programming has made this always challenging task even more challenging.
The news is that Agentic Programming has made this always challenging task even more challenging.
Challenging. Adventurous. And tiring.
It’s global madness fired up by continuous stream of news from LLM providers. It’s like The Verge that is almost about FAANG only, but multiplied as it is “magic” for most people, as vibe coding is “so easy” and dopamine-producing activity that it is similar to runners that don’t want to stop as it stimulates them (and in this case ofc it is healthy :)
It’s global madness fired up by continuous stream of news from LLM providers. It’s like The Verge that is almost about FAANG only, but multiplied as it is “magic” for most people, as vibe coding is “so easy” and dopamine-producing activity that it is similar to runners that don’t want to stop as it stimulates them (and in this case ofc it is healthy :)
I knew a runner that was wearing his body down. His joints where giving up. I predicted he would become a cripple. He wouldn’t stop running despite knowing. He was addicted. Some stories about prompting agents feel like that to me.
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.
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.
> Major databases now ship effective HA tooling
Which ones? PostgreSQL doesn't have HA in core.
Which ones? PostgreSQL doesn't have HA in core.
MySQL 8, but upon review that was 2018. 5.7 had some but it's certainly improved overall since then as well
A database with built-in HA is a significantly more complex system than one without it.
And one built without it and not coordinating with it is often much harder to reason about when you bolt it on later.
>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?
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?
>LLMs be able to coordinate their understanding
I think the next time I see "LLMs" and "Understanding" in the same sentence, I am going to lose it....
I think the next time I see "LLMs" and "Understanding" in the same sentence, I am going to lose it....
You should be less upset over semantics that everyone else has usefully settled on. LLMs understand things fine.
Right and my math textbook understands integration.
At least your math textbook was written by somebody who understood integration
Saying an LLM understands something is like saying my biology textbook understands biology. It's a complete category error.
pixl97(1)
For what it's worth, nomadism and agricultural systems are not necessarily more complex - that is, the complexity of a nomadic lifestyle can be quite high. Randomization, varied food sources, hybrid lifestyles, etc.
The hierarchy is certainly higher in agriculture societies it seems, but the complexity is up for some debate
The hierarchy is certainly higher in agriculture societies it seems, but the complexity is up for some debate
> IBM has entered the chat
https://en.wikipedia.org/wiki/VM_(operating_system)
https://en.wikipedia.org/wiki/VM_(operating_system)
> 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.
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.
Do you have any github examples publically available?
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.
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.
One thing that I have noticed somewhat cuts through the haze of prompt->change->prompt is to drop into the editor when I notice something that is not exactly bad but isn't exactly what I want. It doesn't even have to be a big change - infact smaller annoyances are better in this case because they itch more.
Don't let the agent scratch that itch - it is your hungry inner programmer expressing the need to eat i.e. do it correctly as per your taste. That morsel of work is sustenance.
It also activates the thinking gears that only kick in when I am writing the code. In the same process, the code sinks in better and becomes part of the mental model, even if I may not have paid attention to every single line.
I have also noticed that the mode switch puts me in a marginally better mood - sort of a recharge for the next bout of prompt->change->prompt.
Don't let the agent scratch that itch - it is your hungry inner programmer expressing the need to eat i.e. do it correctly as per your taste. That morsel of work is sustenance.
It also activates the thinking gears that only kick in when I am writing the code. In the same process, the code sinks in better and becomes part of the mental model, even if I may not have paid attention to every single line.
I have also noticed that the mode switch puts me in a marginally better mood - sort of a recharge for the next bout of prompt->change->prompt.
> 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.
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.
> 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.
I like that the author lets the image do the work, rather than preach at me even if I were to agree. History never repeats itself but it always rhymes.
I like that the author lets the image do the work, rather than preach at me even if I were to agree. History never repeats itself but it always rhymes.
I have this funny feeling that someone’s probably gonna ask their favorite frontier LLM about the fruit salad thing to refute your point.
Maybe a tomato would fit quite well in a fruit salad, and the only reason we do not do it is because of arbitrary learned "it's a fruit. But it is treated as vegetable"...
> Intelligence is knowing that a tomato is a fruit
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.
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.
Speaking of "categorisation and understanding dependencies" and "intelligence" and "fruit":
Interestingly, the Bible does not specify what kind of fruit was on the Tree of Knowledge. The association between the forbidden fruit and an apple was a derivative of later translations.
Imagine the consternation if the claim had become Adam and Eve ate of the forbidden tomato. Then this incessant controversy regarding the tomato's status would take on a biblical dimension... though then perhaps the Mormon claim that the Garden of Eden is to be found in the New World would actually have some credibility. Indeed, answers to some questions are not a matter of intelligence at all. Sometimes it seems to me intelligence is more about knowing what questions to ask in the first place.
Interestingly, the Bible does not specify what kind of fruit was on the Tree of Knowledge. The association between the forbidden fruit and an apple was a derivative of later translations.
Imagine the consternation if the claim had become Adam and Eve ate of the forbidden tomato. Then this incessant controversy regarding the tomato's status would take on a biblical dimension... though then perhaps the Mormon claim that the Garden of Eden is to be found in the New World would actually have some credibility. Indeed, answers to some questions are not a matter of intelligence at all. Sometimes it seems to me intelligence is more about knowing what questions to ask in the first place.
> knowing what questions to ask in the first place
That's my 2nd hardest skill when trying to use AI. 3rd hardest is better filtering.
I keep having flashbacks to learning how to use Google effectively.
I'm an arthiest, but I'm in a historically christian society so bible stuff comes up and I often delve in.
Whenever I do look into the bible, it amazes me just how extremely bullshitty vague the bible actually is. I don't understand why people argue about it, or pay attention to past arguments (many famous examples). If I wanted to argue about vague shit I'd be into philosophy or psychology or I could choose any of the many other branches of argument. Humans are not very logical. At least capitalism has a clearer scorecard.
Last nerdsniped look was about Angels due to Scott Alexander:
That's my 2nd hardest skill when trying to use AI. 3rd hardest is better filtering.
I keep having flashbacks to learning how to use Google effectively.
I'm an arthiest, but I'm in a historically christian society so bible stuff comes up and I often delve in.
Whenever I do look into the bible, it amazes me just how extremely bullshitty vague the bible actually is. I don't understand why people argue about it, or pay attention to past arguments (many famous examples). If I wanted to argue about vague shit I'd be into philosophy or psychology or I could choose any of the many other branches of argument. Humans are not very logical. At least capitalism has a clearer scorecard.
Last nerdsniped look was about Angels due to Scott Alexander:
(The Bible describes very clearly what angels look like. [snip] This is the highest-grade antimeme I feel comfortable using as an example; if you don’t see the fnords they can’t eat you.)
I am also not religious, but yes the Bible is everywhere. So like you, I acquaint myself for similar reasons.
Though I take issue with one statement you made - "If I wanted to argue about vague shit I'd be into philosophy..." though I do sympathize.
Modern analytic philosophy in particular, if it is good, is all about trying to be exceedingly precise, often in domains where objects like the Bible (as you noted) are exceedingly vague. Philosophy has some catching up to do, but ultimately one should not disparage it so cavalierly. After all, the best philosophers were usually also the members of society most against the sort of uncritical religiosity that seems to appeal to so many, as it does now and even more severely through the ages, before the efforts of such thinkers to enlighten their fellow human were realized.
If there is a subject that seeks to answer the question of "how to ask questions" it is surely philosophy. The best mathematicians were often well acquainted. In the most famous times of "human flourishing" the philosophers and the mathematicians were one and the same.
But yes, there is a lot of bad philosophy. And there is a lot of religion pretending to be science. Sad, but it has always been true.
Mundus vult decipi, ergo decipiatur
Though I take issue with one statement you made - "If I wanted to argue about vague shit I'd be into philosophy..." though I do sympathize.
Modern analytic philosophy in particular, if it is good, is all about trying to be exceedingly precise, often in domains where objects like the Bible (as you noted) are exceedingly vague. Philosophy has some catching up to do, but ultimately one should not disparage it so cavalierly. After all, the best philosophers were usually also the members of society most against the sort of uncritical religiosity that seems to appeal to so many, as it does now and even more severely through the ages, before the efforts of such thinkers to enlighten their fellow human were realized.
If there is a subject that seeks to answer the question of "how to ask questions" it is surely philosophy. The best mathematicians were often well acquainted. In the most famous times of "human flourishing" the philosophers and the mathematicians were one and the same.
But yes, there is a lot of bad philosophy. And there is a lot of religion pretending to be science. Sad, but it has always been true.
Mundus vult decipi, ergo decipiatur
Apparently, intelligence is to deliberately misunderstand the point being made
You picked a bad example because this is a thing where LLMs excel. A human doesn't know that tomato doesn't play well in a fruit salad until he learns it; not that different from LLMs.
What LLMs lack, from my experience, is two things: First, a long term memory (even a zoomed out one) and Second, the ability to execute a multi-step task without fizzling out. Upon adversity, LLMs breakdown and start making shit up. The newer models are better (and that's the difference between Fable/5.6 and GLM 5.2) but still have a very limited ability to execute any tedious planning tasks.
What LLMs lack, from my experience, is two things: First, a long term memory (even a zoomed out one) and Second, the ability to execute a multi-step task without fizzling out. Upon adversity, LLMs breakdown and start making shit up. The newer models are better (and that's the difference between Fable/5.6 and GLM 5.2) but still have a very limited ability to execute any tedious planning tasks.
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?"
Padmé: "For the better, right?"
Anakin: (gazes in silence)
Padmé: "For the better, right?"
A fallacy that a lot of people have is that productivity equals progress. Programmers (and their managers) using LOC as a target metric, writers using words/chapters written, etc. For some reason this fallacy is reinvented and repeated every so often.
Not to worry, we're still flying half a project.
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.
It comes down to trust. I trust that the people who mede the low level stuff I'm using.
I don't feel the need to code review every single line of the edior I'm using. I trust it to work as promised. Same with all other tools.
I don't feel the need to code review every single line of the edior I'm using. I trust it to work as promised. Same with all other tools.
It feels to me like I'm stuck doing code reviews for a junior dev all day so I use it as little as possible and mostly to look for things I may have missed.
It's great for "mechanical" changes.
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.
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.
Yes it's so useful for mechanical changes, refactors, and creating similar but slightly different components etc. It turns out that when you feed the word prediction machine a bunch of examples of what you want, and then some text that it can use to predict more text, it can do a good job!
The hard part is what text you feed it and how to judge the output.
The hard part is what text you feed it and how to judge the output.
Use the force Luke!
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.
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.
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.
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.
I increasingly feel that the reason vibe coding specifically prohibits reading the generated code is that it's impossible to forget the horror that lurks in these python files.
The code will do what you asked for in a broad sense but wherever choices arise on how to accomplish the goal it'll have made those choices incoherently.
There'll be strange validations applied inconsistently to some user inputs but not others. Data will be repeatedly sorted or converted to lower case for no reason at 3 stages. The column labels are all hard coded strings even though they are the first row of the input CSV. It'll create global functions taking data classes half the time and classes the other half.
If you look, and if you think you might one day need to update and maintain the code manually, then it's very hard to resist fixing this sort of thing, but fixing this sort of thing cancels a lot of the time saving out.
The code will do what you asked for in a broad sense but wherever choices arise on how to accomplish the goal it'll have made those choices incoherently.
There'll be strange validations applied inconsistently to some user inputs but not others. Data will be repeatedly sorted or converted to lower case for no reason at 3 stages. The column labels are all hard coded strings even though they are the first row of the input CSV. It'll create global functions taking data classes half the time and classes the other half.
If you look, and if you think you might one day need to update and maintain the code manually, then it's very hard to resist fixing this sort of thing, but fixing this sort of thing cancels a lot of the time saving out.
> reason vibe coding specifically prohibits reading the generated code
Wait what? Are there rules to vibe coding now? Are we no true Scotsmanning slop now?
Wait what? Are there rules to vibe coding now? Are we no true Scotsmanning slop now?
The term vibe coding actually originated from a tweet from Andrej Karpathy and so there is actually a sort of definition of the term. He said vibe coding is where you "forget the code exists":
https://x.com/karpathy/status/1886192184808149383?lang=en
So if you "read the diff" it isn't vibe coding, at least not by Karpathy's definition.
Obviously it's not a "rule" and you can still call it vibe coding if you want to. Maybe the meaning of the term has evolved since his tweet anyway.
https://x.com/karpathy/status/1886192184808149383?lang=en
So if you "read the diff" it isn't vibe coding, at least not by Karpathy's definition.
Obviously it's not a "rule" and you can still call it vibe coding if you want to. Maybe the meaning of the term has evolved since his tweet anyway.
Well, that's literally what "vibe coding means", no?
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.
The biggest obstacle to huge refactoring has always been minimizing the risk of bugs, not losing any features, and ensuring compatibility with the existing ecosystem. The reason it's become easier in the age of AI is because we stopped caring about these things.
Yep. That’s what people are forgetting. If you have an application that many people depend on to do real work, to make money, you won’t survive if you allow AI to constantly make huge changes.
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.
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.
Actually now we care even more. The reason people didn't write extensive test suites was was because it's super fucking boring to do so.
AIs don't care, they'll happily write 50 unit tests with slight variations and pair them with a full dockerized end to end test suite.
Now we have at least SOME tests. Are they good? Maybe, maybe not - but we have them. If one of them fails later on, we can check if it's an actual issue or the test being bad.
Which is infinitely better than having no tests because nobody can be arsed to write them or the customer isn't paying for the extra hours needed for a proper test suite.
AIs don't care, they'll happily write 50 unit tests with slight variations and pair them with a full dockerized end to end test suite.
Now we have at least SOME tests. Are they good? Maybe, maybe not - but we have them. If one of them fails later on, we can check if it's an actual issue or the test being bad.
Which is infinitely better than having no tests because nobody can be arsed to write them or the customer isn't paying for the extra hours needed for a proper test suite.
People didn't write tests not because it was boring, but because they didn't have time to do it because implementation is more important. That problem didn't go away - it's just instead of not having time to do tests, now we don't have time to review whether the AI wrote tests that make sense. And most of the time it doesn't. They're running the code but not asserting anything. Or they're asserting test inputs instead of implementation outputs. Or outright swallowing errors to make tests pass.
Having such tests is, in fact, worse than not having tests at all. Non-existent tests are just as useful as bad tests, and are much cheaper to maintain.
Having such tests is, in fact, worse than not having tests at all. Non-existent tests are just as useful as bad tests, and are much cheaper to maintain.
Having slop tests instead of no tests is definitely not the same thing as actually caring about avoiding bugs.
This is not about caring. This is about the real world where actual human programmers usually don't want to spend any extra time writing test suites or management doesn't give them the time to do so.
So if the starting point is "no tests", having a bunch of "slop tests" is better, right?
So if the starting point is "no tests", having a bunch of "slop tests" is better, right?
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.
it's like changing how the tower of babel should be built daily. Just because you can doesn't mean you should.
But if all the tests pass, does it matter what's inside?
Unfortunately the tests can't (usually) cover all behaviours.
And perhaps more importantly, they don't capture more abstract properties of the code like maintainability.
AI works best in well maintained code, but unless care is taken, the AI will (today, anyway) make the code less well maintained as it goes.
If the AI is allowed to introduce mess into the codebase faster than its ability to deal with the mess increases, the codebase will eventually run into a problem that it's hard to recover from.
And perhaps more importantly, they don't capture more abstract properties of the code like maintainability.
AI works best in well maintained code, but unless care is taken, the AI will (today, anyway) make the code less well maintained as it goes.
If the AI is allowed to introduce mess into the codebase faster than its ability to deal with the mess increases, the codebase will eventually run into a problem that it's hard to recover from.
And that's kind of the point, some manual testing is always needed - even when humans write the code.
But you can test things and behaviours to a sufficient degree. Nobody really does 100% test coverage on real world code (outside of medical, airplanes and space of course).
But you can test things and behaviours to a sufficient degree. Nobody really does 100% test coverage on real world code (outside of medical, airplanes and space of course).
Yes, of course it does. It's strange to me that this can be asked.
Why? How far do you take this, do you inspect the inside of every single thing and program you use?
Your microwave promises to heat your food at 800W for 1 minute, do you open it up and measure the magnetometer strength? Do you double-check the timer that it's accurate?
You want a program that takes in A and returns B within X milliseconds, I deliver it to you. Do you spend the time going through the whole program line by line to see how it was made or do you trust it?
Or when you buy a car do you take it to a garage and dismantle it to see whether it was correctly assembled in the factory? Or do you trust them?
Your microwave promises to heat your food at 800W for 1 minute, do you open it up and measure the magnetometer strength? Do you double-check the timer that it's accurate?
You want a program that takes in A and returns B within X milliseconds, I deliver it to you. Do you spend the time going through the whole program line by line to see how it was made or do you trust it?
Or when you buy a car do you take it to a garage and dismantle it to see whether it was correctly assembled in the factory? Or do you trust them?
I think the difference here is that 'passing all the tests' isn't the same as satisfying the contract that the consumer is paying for. Even the best test suites won't cover all of the workflows a user might take.
Being pedantic here, but the two scenarios mentioned have regulations as well with repercussions for those products not satisfying their base requirements, whereas a lot of software is the wild-west (I won't be prosecuted for my software not actually working, in most cases).
Being pedantic here, but the two scenarios mentioned have regulations as well with repercussions for those products not satisfying their base requirements, whereas a lot of software is the wild-west (I won't be prosecuted for my software not actually working, in most cases).
But what the customer is paying for is defined somewhere, right? Preferably in writing.
You can give that to an agent and have it confirm the application fulfills the spec. Just like a human would have to.
And if the specific test can’t be automated, why? Is it impossible to automate or just inconvenient?
Granted there are immaterial things that we can’t automatically test yet like how the application feels to use. “Snappy” or “smooth” can’t really be quantified with code.
You can give that to an agent and have it confirm the application fulfills the spec. Just like a human would have to.
And if the specific test can’t be automated, why? Is it impossible to automate or just inconvenient?
Granted there are immaterial things that we can’t automatically test yet like how the application feels to use. “Snappy” or “smooth” can’t really be quantified with code.
>You want a program that takes in A and returns B within X milliseconds
No, I actually want a lot more than that. I just didn't communicate all of it, because I'm accustomed to you understanding what good software is. (Or I didn't hire you in the first place, because I don't trust others to care like I do.)
If the microwave doesn't cook my food well, I can probably adjust for it; and anyway the objective power metric isn't the thing that matters to me, but the temperature and taste of the food I pull out. The code is an entirely different story, assuming I'm actually asking for code and not a finished program. Because I'm going to have to integrate it into something else.
And yeah, like the sibling comment said, the currently existing tests aren't actually the full interface. And they, too, are code, which can be wrong.
No, I actually want a lot more than that. I just didn't communicate all of it, because I'm accustomed to you understanding what good software is. (Or I didn't hire you in the first place, because I don't trust others to care like I do.)
If the microwave doesn't cook my food well, I can probably adjust for it; and anyway the objective power metric isn't the thing that matters to me, but the temperature and taste of the food I pull out. The code is an entirely different story, assuming I'm actually asking for code and not a finished program. Because I'm going to have to integrate it into something else.
And yeah, like the sibling comment said, the currently existing tests aren't actually the full interface. And they, too, are code, which can be wrong.
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
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
This reminded me of Naur's "Programming as Theory Building" [1], the article's "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" is Naur's theory, and the author's "friction" is what teams build that theory.
I guess whether AI written code means you can't build a theory of a program is an open question - but I don't see why you can't have AI written code that keeps the system knowable and extendable, in the same way that any long lived program or system can be. It's _just_ a question of being disciplined in the same way you'd need to be with developing and maintaining any long lived artefact.
[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf
I guess whether AI written code means you can't build a theory of a program is an open question - but I don't see why you can't have AI written code that keeps the system knowable and extendable, in the same way that any long lived program or system can be. It's _just_ a question of being disciplined in the same way you'd need to be with developing and maintaining any long lived artefact.
[1] https://pages.cs.wisc.edu/~remzi/Naur.pdf
Does it really keep rising? Many of my fondest memories of technology come from times past...
I interpret "keeps rising" negatively. Changes keep getting made, certainly. The AIs will perhaps never fail to fulfill your feature request. But there's no overall plan. It's just undirected, cancerous growth. It's Homer Simpson telling a team of automotive engineers to add feature after feature.
The tower is not about fondness, its about growth
Is growth enough if technology makes our lives worse? Is a tower the pride of the civilization if a strong gust of wind could bring it down? It is before the gust, when all that matters is that the tower is tall rather than strong. After the gust, things are a bit more nuanced. Fingers are pointed.
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.
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.
Cancer is also growth.
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.
Every time I think the past was better, I think about how terrible ksh scripting was in 1995. And look at how great peoples' bash scripting is now compared to when we though bash had reached its apex in like 2009.
Conversely, Rexx scripting on the desktop was glorious in 1995.
ARexx on Amiga was way before 1995. And it was glorious.
I used to want an Amiga. they are probably still for sale on ebay. Like in 2010. :(
lol I was actually kidding. The past was way better, almost always (it isn't just nostalgia). I think my enjoyment of tech actually used to sort follow a wavelike pattern. Then, it sort of became a straight line a few years before COVID, and I worry that AI is cementing people into an always-forward mindset that removes the enjoyment from just about everything.
I mean, yeah, hobby coding is not going away, but the feeling of exploration for me is totally gone. I don't dislike tech, I just don't see anyone being the way they used to be. People in tech are different and too many people are in tech.
Probably only part of the joy will ever be there, now. Which is weird because I did my own thing with computers til college, and don't consider myself a super sociable person. I just used to know that it was there, and now it isn't.
I mean, yeah, hobby coding is not going away, but the feeling of exploration for me is totally gone. I don't dislike tech, I just don't see anyone being the way they used to be. People in tech are different and too many people are in tech.
Probably only part of the joy will ever be there, now. Which is weird because I did my own thing with computers til college, and don't consider myself a super sociable person. I just used to know that it was there, and now it isn't.
There's nothing quite like the empowerment of discoverable user interfaces devoid of dark patterns.
> Many of my fondest memories of technology come from times past...
Is that because of the technology or because of who you were at the time?
Is that because of the technology or because of who you were at the time?
Really surprised not to see Pope Leo's recent encyclical on AI/tech mentioned here.
https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...
https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...
I had the same thought, glad someone else noticed this.
Comparing AI adoption to the Tower of Babel is a central theme to Magnifica Humanitas, but written by someone with a much deeper understanding of the Biblical narrative.
Comparing AI adoption to the Tower of Babel is a central theme to Magnifica Humanitas, but written by someone with a much deeper understanding of the Biblical narrative.
One day we'll get to the plateau of productivity of this hype cycle and wonder WTF were we thinking.
Not that we won't have most code written by agents. I truly beleive that to be true. But that we got so far down the "never look at code" rabbit hole that our abstractions will become so divorced from the reality that is the actual.. freaking... code. We will truly have spaghetti code, bloated towers of babble.
We'll tut-tut these times and think "if you only spent half a day thinking about the big picture, looking at code, dare I say write some code you could have saved the project a whole mess of trouble".
In the meantime we're going to be generate 10K in spaghetti what should probably be 500 reasonably understandable LoC.
Spending a day reading some code can save you $100s of tokens, and weeks of headaches.
Not that we won't have most code written by agents. I truly beleive that to be true. But that we got so far down the "never look at code" rabbit hole that our abstractions will become so divorced from the reality that is the actual.. freaking... code. We will truly have spaghetti code, bloated towers of babble.
We'll tut-tut these times and think "if you only spent half a day thinking about the big picture, looking at code, dare I say write some code you could have saved the project a whole mess of trouble".
In the meantime we're going to be generate 10K in spaghetti what should probably be 500 reasonably understandable LoC.
Spending a day reading some code can save you $100s of tokens, and weeks of headaches.
Software construction needs to become like Mission Control - everyone can see everyone else's screen. Maybe that's a monitor bank for passive monitoring, and letting anyone hop into any tmux and steer any agent - and an agent pool works on tasks from the backlog, rather than engineers being assigned tasks and using agents to do them. It needs to be more like an orchestra, where things are being directed in real time - designating a conductor who steers things. Maybe it's like a ship's crew, with roles, a chain of command, and lots of overlap. So each day someone gets to be Captain.
It was all good when change was slow and needed deep contemplation. Things sped up this year. Chaos is harder to defeat now. It really does need a different paradigm than "people facing into corners each doing today's task".
It was all good when change was slow and needed deep contemplation. Things sped up this year. Chaos is harder to defeat now. It really does need a different paradigm than "people facing into corners each doing today's task".
Is communication at risk? Perhaps more demanding of one's attention, more insistent in its attempt at inclusion and contribution?
Large Language Models are the most powerful communication tools to have ever existed - probably behind the written and spoken word and marginally behind the internet, maybe more important than phones and texting.
With understanding now on tap in this new form of infrastructure, the tower (codebase) and our coordination within it are both very customizable - up, down, sideways - per the will of the team and maintainers.
The sample size of your architectural taste, intuition, or expertise at abstraction may never be large enough for a LLM to match it. But if you want it to, it too can keep getting better and closer at this as it seeks alignment with your acceptance.
Once your tower is built, what's next?
Large Language Models are the most powerful communication tools to have ever existed - probably behind the written and spoken word and marginally behind the internet, maybe more important than phones and texting.
With understanding now on tap in this new form of infrastructure, the tower (codebase) and our coordination within it are both very customizable - up, down, sideways - per the will of the team and maintainers.
The sample size of your architectural taste, intuition, or expertise at abstraction may never be large enough for a LLM to match it. But if you want it to, it too can keep getting better and closer at this as it seeks alignment with your acceptance.
Once your tower is built, what's next?
the tower keeps rising but the elevator pitch for every new floor is 'it solves the problems created by the floor below it'
AI can make individuals 2x or 5x or 10x (?) faster. Lack of trust, alignment, and ownership can make _teams_ 2x or 5x or 10x slower.
I love the line “This friction synchronizes people.”
Part of the understanding that is missed being learned by the team are the failure modes: how can this system fail and how catastrophic is it?
Now I fear only the users will learn via data loss, leaks, and hacks.
Part of the understanding that is missed being learned by the team are the failure modes: how can this system fail and how catastrophic is it?
Now I fear only the users will learn via data loss, leaks, and hacks.
It is a great analogy.
Also quite like Linus Torvalds likening of AI to a compiler.
He argues that calling AI the "author" of code is the equivalent of saying a compiler wrote your code.
He views AI as an incredibly powerful productivity layer, much like the historic progression from machine code to assemblers, and then to higher-level compilers!
Also quite like Linus Torvalds likening of AI to a compiler.
He argues that calling AI the "author" of code is the equivalent of saying a compiler wrote your code.
He views AI as an incredibly powerful productivity layer, much like the historic progression from machine code to assemblers, and then to higher-level compilers!
An important difference is the code precisely expresses many behaviours of the program, and a correct compiler guarantees to respect those behaviours.
An AI prompt is not so precise, and an AI offers no such guarantees to respect the behaviours expressed.
This is why the primary artifact of the development process, which we review and version control, is still the code, and not the prompt.
That said, I do think there's a lot of value to be gained by recording and analysing the prompt/response loop behind the code that ends up in a codebase
An AI prompt is not so precise, and an AI offers no such guarantees to respect the behaviours expressed.
This is why the primary artifact of the development process, which we review and version control, is still the code, and not the prompt.
That said, I do think there's a lot of value to be gained by recording and analysing the prompt/response loop behind the code that ends up in a codebase
Shall we be concerned that not many are even able to read assembler code?
I'm not talking about reading machine code, produced by the assembler, but the assembler code itself.
Machine code was hard, but one could make it pretty efficient. Not efficiently.
Assembler was still pretty performant, for today's standard it is tip top.
So, moving on 10, 20 years from now, can someone read c++? Even html?
Machine code was hard, but one could make it pretty efficient. Not efficiently.
Assembler was still pretty performant, for today's standard it is tip top.
So, moving on 10, 20 years from now, can someone read c++? Even html?
I think whoever is responsible for the correct operation of a software system will still need to read something that precisely describes the behaviours that they care about.
Today, for most devs, thats the code. We usually don't need to look at compiled output, because the code is enough. We can't just look at the prompts, because they aren't precise enough.
Today, for most devs, thats the code. We usually don't need to look at compiled output, because the code is enough. We can't just look at the prompts, because they aren't precise enough.
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.
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.
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.
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?
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?
> 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.
But this is just bad vibecoding? This would be bad if humans did it too. With agents or humans, you need to coordinate.
Nothing to do with vibes, it's just a process issue.
Yes, you can "add" anything you want, but if you can get that in to the main branch without a PR, it doesn't matter whether it was done by AI or human or both.
Yes, you can "add" anything you want, but if you can get that in to the main branch without a PR, it doesn't matter whether it was done by AI or human or both.
Agents are very good at making us think the tower is rising, when in fact it is falling beneath our feet.
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.
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.
This is an interesting comparison, but the resulting product of an LLM aren't deterministic in the same way machinery in an assembly line is. You typically expect to get the exact same thing every time as an assembly line worker, and it's usually fairly obvious when something is wrong or off.
So while I agree with your invocation of Marx and the alienation of labor, but I don't know if we really can compare it to the automation of manual labor.
So while I agree with your invocation of Marx and the alienation of labor, but I don't know if we really can compare it to the automation of manual labor.
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.
1. Perhaps with a handful of skyscrapers sprinkled in.
> 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 think we have hit a long enough timescale to say that we _can_ actually build on top of the AI-assisted engineering work. Tech debt tends to reveal itself later on in the process.
Personally I've totally witnessed AI-assisted work that is clearly heading towards a brick wall quite quickly. I think "mixed feelings" is my optimistic view.
People really discount how well _well engineered abstractions_ are required for AI tooling to not generate absolute garbage. And if people are relying on AI tooling for the abstractions... I think you're really tempting fate in the mid-term.
I don't think we have hit a long enough timescale to say that we _can_ actually build on top of the AI-assisted engineering work. Tech debt tends to reveal itself later on in the process.
Personally I've totally witnessed AI-assisted work that is clearly heading towards a brick wall quite quickly. I think "mixed feelings" is my optimistic view.
People really discount how well _well engineered abstractions_ are required for AI tooling to not generate absolute garbage. And if people are relying on AI tooling for the abstractions... I think you're really tempting fate in the mid-term.
The author correctly identifies coordination as one of the things that enables humans, unlike the their primates, to build societies of immense scale and to collaborate, even through competition, across time and space.
However, I think what the author might miss is that AI is perhaps the next level of coordination of the human organism.
However, I think what the author might miss is that AI is perhaps the next level of coordination of the human organism.
> 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?
Why being one (I see as collaborative) was it not desired? Interpretations? Why is it seemed *more* harmful rather than good?
The Pope discusses this exact question at length in his recent Encyclical:
https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...
It's odd that TFA doesn't acknowledge this.
https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...
It's odd that TFA doesn't acknowledge this.
No, the story of the tower of Babel was:
"we can, so we should".
It ended badly.
"we can, so we should".
It ended badly.
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.
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.
Indeed. This is an awkward era where we're using these artificial language tools to target abstractions made for humans to manually write.
At some point the path from human language to machine code is not going to require an interstitial step writing to higher level languages as we know them.
At some point the path from human language to machine code is not going to require an interstitial step writing to higher level languages as we know them.
For a lot of people, LLM's are actually doing a better job than what they are capable of. I do worry that they are the people first up for replacement, since they don't really provide much value that the LLM itself can't provide. There isn't much point in paying a human to prompt an LLM if you could do it yourself, the value is in someone with the skill and judgement to both prompt it correctly and validate the output - and if the LLM is producing better code than the human is capable of they clearly don't have any of that.
Personally I really like using LLMs because they have made certain things a lot more productive, but I don't feel like my job has really changed at all. I have a new way of generating code, but my value has never been my (abysmal) typing speed or knowledge of algorithms or how fast I can centre a div. It's been in the stuff that LLMs still haven't pierced, and probably never will.
Personally I really like using LLMs because they have made certain things a lot more productive, but I don't feel like my job has really changed at all. I have a new way of generating code, but my value has never been my (abysmal) typing speed or knowledge of algorithms or how fast I can centre a div. It's been in the stuff that LLMs still haven't pierced, and probably never will.
I see that point differently.
Typing code and using AI well are distinctly different things. I've dealt with Chinese subcontracting managers before. But managing people is different from doing code reviews and writing code. I think these two are fundamentally similar but different. Of course, it's undeniable that you need a certain level of skill to verify the output, which is why I practice typing for an hour every day. But that aside, while it's true that good coders may have a head start in using AI well, I don't think they're essentially the same thing.
The reason I say this is simple: AI has already learned more than I have in many areas. Good code often involves a lot of error handling. But humans can't cover all of those edge cases. Even something like UAF (Use-After-Free) can happen depending on timing, and pointers may not release properly. But AI catches these things surprisingly well.
So I think this way: on average, it may be true that people with higher coding skills use AI better, but I think it's hard to say that means they're better at using AI. People who are good at using AI are usually those who break functions down into more readable pieces and set boundaries better, rather than those who are good at LeetCode-style problems. That's similar to being a good coder, but it's a slightly different skill set.
I respect your opinion, but I think an additional layer will emerge.
Typing code and using AI well are distinctly different things. I've dealt with Chinese subcontracting managers before. But managing people is different from doing code reviews and writing code. I think these two are fundamentally similar but different. Of course, it's undeniable that you need a certain level of skill to verify the output, which is why I practice typing for an hour every day. But that aside, while it's true that good coders may have a head start in using AI well, I don't think they're essentially the same thing.
The reason I say this is simple: AI has already learned more than I have in many areas. Good code often involves a lot of error handling. But humans can't cover all of those edge cases. Even something like UAF (Use-After-Free) can happen depending on timing, and pointers may not release properly. But AI catches these things surprisingly well.
So I think this way: on average, it may be true that people with higher coding skills use AI better, but I think it's hard to say that means they're better at using AI. People who are good at using AI are usually those who break functions down into more readable pieces and set boundaries better, rather than those who are good at LeetCode-style problems. That's similar to being a good coder, but it's a slightly different skill set.
I respect your opinion, but I think an additional layer will emerge.
You sound like you’re young and you don’t have a ton of experience programming yet. Id be cautious about outsourcing your knowledge and skill development to LLMs at this time. There is a massive gap between what a beginner and expert can achieve with LLMs - in fact I’ve seen plenty of people who’s use of AI results in a net negative! You need to develop your skills and knowledge in order to best make use of LLMs. You can even use the LLMs to learn and grow, but I think it’s dangerous for your career to have the mentality that AI is and will always be a better programmer.
Anyways just my opinion, I don’t mean it in an offensive way at all, I just think that people need to be careful about how they approach their usage of LLMs. Even experienced people need to be careful and ensure they don’t lose their own skills.
Anyways just my opinion, I don’t mean it in an offensive way at all, I just think that people need to be careful about how they approach their usage of LLMs. Even experienced people need to be careful and ensure they don’t lose their own skills.
Thank you for your kindness. If we're just counting years, I've been programming since college, so that's about 15 years, but my professional experience is around 7 to 8 years. It's a short career, and if that makes me young, then I'm young. I agree with you that offloading knowledge and skill development to LLMs is a real problem, and I also agree that there's a huge gap between what a beginner and an expert can achieve using LLMs. (I was born in 1992.)
I agree with most of what you're saying, and I think you're giving me thoughtful advice out of genuine concern. I agree with nearly all of it.
I think of the phenomenon you're describing as "layering of input." Everything you've cautiously advised me on, I believe you're right. The atrophy of coding muscle from using AI is happening to me too. That's why I make myself type for at least an hour a day, just to maintain the coding muscle I need to actually read what the AI generates.
The problem is, I'm a freelancer, and I have to accept the reality that the market itself has already shifted around AI. Open source developers can show off the aesthetic beauty of their code to others and attract sponsors. But I'm a freelance developer, and I usually get paid per project. These days, with AI vibe coding, not only are companies handling more things in house, but deadlines have become drastically shorter compared to before. What used to be a two month project is now a one month project. And the trouble is, I charge by the month. So the workload has gone up, but my pay has effectively gone down.
I also think, as you said, that people should be more careful about how they use LLMs. But the landscape has shifted so much, and in this environment, I think the people who use it more will end up using it more adeptly. In other words, I've changed from a programmer who models with typing and UML into a programmer who models by using an LLM. I don't know which direction is the better one.
That said, I admit there's probably some self rationalization going on, because I don't really have a choice. The moment I stop working, I can't make rent. The open source world isn't really open to someone like me, an Asian guy. I upvoted you because I'm not taking your advice in bad faith. I understand where your heart is, but there's a part of me that just feels like I don't have much of a choice. Have a good day.
I agree with most of what you're saying, and I think you're giving me thoughtful advice out of genuine concern. I agree with nearly all of it.
I think of the phenomenon you're describing as "layering of input." Everything you've cautiously advised me on, I believe you're right. The atrophy of coding muscle from using AI is happening to me too. That's why I make myself type for at least an hour a day, just to maintain the coding muscle I need to actually read what the AI generates.
The problem is, I'm a freelancer, and I have to accept the reality that the market itself has already shifted around AI. Open source developers can show off the aesthetic beauty of their code to others and attract sponsors. But I'm a freelance developer, and I usually get paid per project. These days, with AI vibe coding, not only are companies handling more things in house, but deadlines have become drastically shorter compared to before. What used to be a two month project is now a one month project. And the trouble is, I charge by the month. So the workload has gone up, but my pay has effectively gone down.
I also think, as you said, that people should be more careful about how they use LLMs. But the landscape has shifted so much, and in this environment, I think the people who use it more will end up using it more adeptly. In other words, I've changed from a programmer who models with typing and UML into a programmer who models by using an LLM. I don't know which direction is the better one.
That said, I admit there's probably some self rationalization going on, because I don't really have a choice. The moment I stop working, I can't make rent. The open source world isn't really open to someone like me, an Asian guy. I upvoted you because I'm not taking your advice in bad faith. I understand where your heart is, but there's a part of me that just feels like I don't have much of a choice. Have a good day.
People gotta do what they gotta do to make money, no issues with that. Best of luck brother.
ai eliminating friction is eliminating learning and understanding. this is felt with more severe consequences in K-12 writing and music.
This reminds me of Ted Chiang's "Tower of Babylon". You really should read it (and all of TC's works)!
Ultimately, AI models will need to ingest the slop ziggurat they created. This means, other things being equal, that it won't be so easy as it is now to achieve incremental gains from the sheer fact of gobbling up more code.
... 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...
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...
Domain Driven Design
Speaking of tower analogies, I fear it may play out like in this comic: https://www.smbc-comics.com/comic/the-village-and-the-tower
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.
Really liked the framing on this
so, is it an analogy for a better tower or a better communication breakdown?
this is just a software engineer's ego trying to protect itself in flowery language
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?