20 ms·

The Tower Keeps Rising

558 points by cdrnsf 3mo ago

beardyw 3mo ago
No, the story of the tower of Babel was: "we can, so we should". It ended badly.
prymitive 3mo ago
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.
- Xirdus 3mo ago
  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.
  - sarchertech 3mo ago
    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.
  - theshrike79 3mo ago
    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.
    - zahlman 3mo ago
      Having slop tests instead of no tests is definitely not the same thing as actually caring about avoiding bugs.
      - theshrike79 3mo ago
        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?
    - Xirdus 3mo ago
      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.
- deleted 3mo ago
  [deleted]
- Cthulhu_ 3mo ago
  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.
  - theshrike79 3mo ago
    But if all the tests pass, does it matter what's inside?
    - timothycoleman 3mo ago
      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.
      - theshrike79 3mo ago
        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).
    - zahlman 3mo ago
      Yes, of course it does. It's strange to me that this can be asked.
      - theshrike79 3mo ago
        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?
conartist6 3mo ago
Does it really keep rising? Many of my fondest memories of technology come from times past...
- GlickWick 3mo ago
  The tower is not about fondness, its about growth
  - conartist6 3mo ago
    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.
    - archonis 3mo ago
      Cancer is also growth.
- CobrastanJorji 3mo ago
  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.
- a2dam 3mo ago
  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.
  - 3mo ago
sixtyj 3mo ago
> 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.
- calvinmorrison 3mo ago
  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.
  - paulryanrogers 3mo ago
    > Major databases now ship effective HA tooling Which ones? PostgreSQL doesn't have HA in core.
    - calvinmorrison 3mo ago
      MySQL 8, but upon review that was 2018. 5.7 had some but it's certainly improved overall since then as well
  - endorphine 3mo ago
    A database with built-in HA is a significantly more complex system than one without it.
    - hilariously 3mo ago
      And one built without it and not coordinating with it is often much harder to reason about when you bolt it on later.
tekacs 3mo ago
I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear. I feel like that gives an even more literal tower-rising metaphor, and that's what it feels like people using agents naively (and software engineers of lower skill or earlier-career), end up violating. Agents are getting better at folding things into themselves, especially if you direct them to... but unfortunately I've found that the architectural instincts, even of Fable and 5.6 Sol, are still wildly behind what I reflexively achieve, say. For sure there is an ability to have agents go back over work and try to fold it into better and better abstractions until it's sort of annealed into something good. I've done something similar on codebases that I have, but the 'high reaches' of architecture with great _prediction of how the software will evolve in the future_ in _subtle_ ways – those are, for now, out of reach of agents. There is a part of me that wonders if it's partly just how much they can hold in their head right now, though. Even with the greatest articulation and high density of feeding them, the current setups don't allow them to hold a high-quality, sparse, 'zoomable' model of the world in their head that well yet, which we can do pretty well. But the fact that I'm talking about it in terms of that kind of subtlety is itself promising, I guess?
- Animats 3mo ago
  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.
  - conartist6 3mo ago
    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
jeffreyrogers 3mo ago
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.
- snarf21 3mo ago
  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.
  - gwbas1c 3mo ago
    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.
    - slopinthebag 3mo ago
      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.
m3kw9 3mo ago
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.
- jagenabler2 3mo ago
  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.
apinstein 3mo ago
> The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does. This language is rarely written down in one place. It lives partly in documentation and code, but also in code review, conversations, arguments, and the experience of having to explain a change to somebody else. This is so true. I am a big fan of Christopher Alexander’s “Pattern Language” concept, which addresses this exact problem! In fact he recommends developing your own pattern languages for your own domains (which of course led to the famous GoF Design Patterns book). I have been experimenting with a “Pattern Language” skill which instructs the AI to maintain 3 pattern languages for every project. One in the business domain, one in the product domain, and one in the technical domain. It is working really well. It is always super cool to see it reference the pattern languages during planning and curate them during implementation and review. I credit using it with keeping my 100% ai-coded projects well organized, aligned across domains, and easy to work on.
- whattheheckheck 3mo ago
  Do you have any github examples publically available?
- ucyo 3mo ago
  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.
- apinstein 3mo ago
  Here is the “internal” pattern language I started on “patterns for building software projects with AI”: https://github.com/apinstein/pattern-language-building-with-ai https://github.com/apinstein/pattern-language-building-with-... It’s mostly AI-written patterns based on my personal prompts/observations. And here is the skill for organizing the pattern languages for a single project: https://github.com/apinstein/skills/tree/main/skills/pattern-language-engine https://github.com/apinstein/skills/tree/main/skills/pattern... I haven’t really battle tested these so hard yet but it’s a fun concept and really should get back to organizing them more intentionally. Happy to share this early phase just cause it’s cool to see the interest.
jagged-chisel 3mo ago
... 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...
alwa 3mo ago
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.
trjordan 3mo ago
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
ssivark 3mo ago
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 https://www.winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://www.marktarver.com/bipolar.html https://www.marktarver.com/bipolar.html
- zephen 3mo ago
  > 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.
  - nico 3mo ago
    > 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
__0x01 3mo ago
Agents are very good at making us think the tower is rising, when in fact it is falling beneath our feet.
fantasizr 3mo ago
ai eliminating friction is eliminating learning and understanding. this is felt with more severe consequences in K-12 writing and music.
overgard 3mo ago
I feel like this is missing the ending of "until gravity wins"
- lstodd 3mo ago
  not gravity, enthropy.
zemo 3mo ago
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?"
- kmoser 3mo ago
  https://www.newyorker.com/cartoons/daily-cartoon/monday-july-13th-ai-fortune-teller https://www.newyorker.com/cartoons/daily-cartoon/monday-july...
- moffkalast 3mo ago
  Not to worry, we're still flying half a project.
- Cthulhu_ 3mo ago
  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.
guessbest 3mo ago
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.
mrdomino- 3mo ago
[dead]
thadk 3mo ago
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?
jzer0cool 3mo ago
> 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?
- zoobaloo 3mo ago
  The Pope discusses this exact question at length in his recent Encyclical: https://www.vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html https://www.vatican.va/content/leo-xiv/en/encyclicals/docume... It's odd that TFA doesn't acknowledge this.
aaron_m04 3mo ago
This could've been a much better article without the strained Tower of Babel article.
- aaron_m04 3mo ago
  Err, last word is "analogy"
overfeed 3mo ago
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.
- abraxas 3mo ago
  so the post-AI landscape is software as a shanty town? That's not a bad analogy. We won't like the looks of it and it will barely function but like real life shanty towns it will function nonetheless.
  - archonis 3mo ago
    Kowloon Walled City.
dzonga 3mo ago
at one point - future generations - will look at people who designed unix like tools - tools that do one thing well & compose with other tools as demigods.
- ares623 3mo ago
  lol no. They'll "rediscover" it and claim themselves as demigods.
jadbox 3mo ago
This reminds me of Ted Chiang's "Tower of Babylon". You really should read it (and all of TC's works)!
HiPhish 3mo ago
> 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.
- geraneum 3mo ago
  I have this funny feeling that someone’s probably gonna ask their favorite frontier LLM about the fruit salad thing to refute your point.
- robocat 3mo ago
  > 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.
  - godwinson__4-8 3mo ago
    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.
jdw64 3mo ago
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.
cheschire 3mo ago
Douglas Adams basically predicted Wikipedia on smartphones, and I suspect we are only a few years away from babelfish ear buds.
- Tagbert 3mo ago
  Apple AirPods and Google buds both can do automatic translation. It's still a little too slow and is a little clumsy to use but it's getting better fast.
ddp26 3mo ago
> 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.
- theshrike79 3mo ago
  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.
zawaideh 3mo ago
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.
- mynameisbilly 3mo ago
  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.
luciana1u 3mo ago
[flagged]
sigbottle 3mo ago
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.
cadamsdotcom 3mo ago
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".
4b11b4 3mo ago
Really liked the framing on this
_pdp_ 3mo ago
Vibe-coded software require a new type of discipline that has not been invented yet.
- ies7 3mo ago
  Vibe-coders from non developer haven't/won't learn that discipline.
alkyon 3mo ago
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.
bobro 3mo ago
Really surprised not to see Pope Leo's recent encyclical on AI/tech mentioned here. https://www.vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...
- zoobaloo 3mo ago
  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.
phoneafriend 3mo ago
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?
fancyfredbot 3mo ago
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.
- strix_varius 3mo ago
  > 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?
  - mkehrt 3mo ago
    Well, that's literally what "vibe coding means", no?
  - fancyfredbot 3mo ago
    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 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.
lowbloodsugar 3mo ago
Domain Driven Design
softwaredoug 3mo ago
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.
Invictus0 3mo ago
this is just a software engineer's ego trying to protect itself in flowery language
noisy_boy 3mo ago
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.
rtpg 3mo ago
> 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.
iririririr 3mo ago
so, is it an analogy for a better tower or a better communication breakdown?
Ozzie_osman 3mo ago
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.
deleted 3mo ago
[deleted]
peter_retief 3mo ago
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!
- permalac 3mo ago
  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?
  - timothycoleman 3mo ago
    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.
- timothycoleman 3mo ago
  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
Matumio 3mo ago
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 https://www.smbc-comics.com/comic/the-village-and-the-tower
jbarber 3mo ago
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 https://pages.cs.wisc.edu/~remzi/Naur.pdf
burntcaramel 3mo ago
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.

558 points by cdrnsf 3mo ago

No, the story of the tower of Babel was: "we can, so we should". It ended badly.

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.

Xirdus 3mo ago
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.
- sarchertech 3mo ago
  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.
- theshrike79 3mo ago
  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.
  - zahlman 3mo ago
    Having slop tests instead of no tests is definitely not the same thing as actually caring about avoiding bugs.
    - theshrike79 3mo ago
      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?
  - Xirdus 3mo ago
    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.
deleted 3mo ago
[deleted]
Cthulhu_ 3mo ago
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.
- theshrike79 3mo ago
  But if all the tests pass, does it matter what's inside?
  - timothycoleman 3mo ago
    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.
    - theshrike79 3mo ago
      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).
  - zahlman 3mo ago
    Yes, of course it does. It's strange to me that this can be asked.
    - theshrike79 3mo ago
      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?

conartist6 3mo ago

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

GlickWick 3mo ago
The tower is not about fondness, its about growth
- conartist6 3mo ago
  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.
  - archonis 3mo ago
    Cancer is also growth.
CobrastanJorji 3mo ago
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.
a2dam 3mo ago
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.
- 3mo ago

sixtyj 3mo ago

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

calvinmorrison 3mo ago
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.
- paulryanrogers 3mo ago
  > Major databases now ship effective HA tooling Which ones? PostgreSQL doesn't have HA in core.
  - calvinmorrison 3mo ago
    MySQL 8, but upon review that was 2018. 5.7 had some but it's certainly improved overall since then as well
- endorphine 3mo ago
  A database with built-in HA is a significantly more complex system than one without it.
  - hilariously 3mo ago
    And one built without it and not coordinating with it is often much harder to reason about when you bolt it on later.

tekacs 3mo ago

I've said for a long time that composability in software is a bit like playing Tetris: the lines have to clear. I feel like that gives an even more literal tower-rising metaphor, and that's what it feels like people using agents naively (and software engineers of lower skill or earlier-career), end up violating. Agents are getting better at folding things into themselves, especially if you direct them to... but unfortunately I've found that the architectural instincts, even of Fable and 5.6 Sol, are still wildly behind what I reflexively achieve, say. For sure there is an ability to have agents go back over work and try to fold it into better and better abstractions until it's sort of annealed into something good. I've done something similar on codebases that I have, but the 'high reaches' of architecture with great _prediction of how the software will evolve in the future_ in _subtle_ ways – those are, for now, out of reach of agents. There is a part of me that wonders if it's partly just how much they can hold in their head right now, though. Even with the greatest articulation and high density of feeding them, the current setups don't allow them to hold a high-quality, sparse, 'zoomable' model of the world in their head that well yet, which we can do pretty well. But the fact that I'm talking about it in terms of that kind of subtlety is itself promising, I guess?

Animats 3mo ago
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.
- conartist6 3mo ago
  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

jeffreyrogers 3mo ago

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.

snarf21 3mo ago
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.
- gwbas1c 3mo ago
  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.
  - slopinthebag 3mo ago
    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.

m3kw9 3mo ago

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.

jagenabler2 3mo ago
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.

apinstein 3mo ago

> The shared language of a software project is not English or Python but it is the common understanding of what its concepts mean, where the boundaries are, which invariants matter, who owns what, and why the system has the shape it does. This language is rarely written down in one place. It lives partly in documentation and code, but also in code review, conversations, arguments, and the experience of having to explain a change to somebody else. This is so true. I am a big fan of Christopher Alexander’s “Pattern Language” concept, which addresses this exact problem! In fact he recommends developing your own pattern languages for your own domains (which of course led to the famous GoF Design Patterns book). I have been experimenting with a “Pattern Language” skill which instructs the AI to maintain 3 pattern languages for every project. One in the business domain, one in the product domain, and one in the technical domain. It is working really well. It is always super cool to see it reference the pattern languages during planning and curate them during implementation and review. I credit using it with keeping my 100% ai-coded projects well organized, aligned across domains, and easy to work on.

whattheheckheck 3mo ago
Do you have any github examples publically available?
ucyo 3mo ago
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.
apinstein 3mo ago
Here is the “internal” pattern language I started on “patterns for building software projects with AI”: https://github.com/apinstein/pattern-language-building-with-ai https://github.com/apinstein/pattern-language-building-with-... It’s mostly AI-written patterns based on my personal prompts/observations. And here is the skill for organizing the pattern languages for a single project: https://github.com/apinstein/skills/tree/main/skills/pattern-language-engine https://github.com/apinstein/skills/tree/main/skills/pattern... I haven’t really battle tested these so hard yet but it’s a fun concept and really should get back to organizing them more intentionally. Happy to share this early phase just cause it’s cool to see the interest.

jagged-chisel 3mo ago

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

alwa 3mo ago

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.

trjordan 3mo ago

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

ssivark 3mo ago

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 https://www.winestockwebdesign.com/Essays/Lisp_Curse.html [2] https://www.marktarver.com/bipolar.html https://www.marktarver.com/bipolar.html

zephen 3mo ago
> 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.
- nico 3mo ago
  > 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

__0x01 3mo ago

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

fantasizr 3mo ago

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

overgard 3mo ago

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

lstodd 3mo ago
not gravity, enthropy.

zemo 3mo ago

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

kmoser 3mo ago
https://www.newyorker.com/cartoons/daily-cartoon/monday-july-13th-ai-fortune-teller https://www.newyorker.com/cartoons/daily-cartoon/monday-july...
moffkalast 3mo ago
Not to worry, we're still flying half a project.
Cthulhu_ 3mo ago
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.

guessbest 3mo ago

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.

mrdomino- 3mo ago

[dead]

thadk 3mo ago

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?

jzer0cool 3mo ago

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

zoobaloo 3mo ago
The Pope discusses this exact question at length in his recent Encyclical: https://www.vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html https://www.vatican.va/content/leo-xiv/en/encyclicals/docume... It's odd that TFA doesn't acknowledge this.

aaron_m04 3mo ago

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

aaron_m04 3mo ago
Err, last word is "analogy"

overfeed 3mo ago

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.

abraxas 3mo ago
so the post-AI landscape is software as a shanty town? That's not a bad analogy. We won't like the looks of it and it will barely function but like real life shanty towns it will function nonetheless.
- archonis 3mo ago
  Kowloon Walled City.

dzonga 3mo ago

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

ares623 3mo ago
lol no. They'll "rediscover" it and claim themselves as demigods.

jadbox 3mo ago

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

HiPhish 3mo ago

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

geraneum 3mo ago
I have this funny feeling that someone’s probably gonna ask their favorite frontier LLM about the fruit salad thing to refute your point.
robocat 3mo ago
> 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.
- godwinson__4-8 3mo ago
  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.

jdw64 3mo ago

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.

cheschire 3mo ago

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

Tagbert 3mo ago
Apple AirPods and Google buds both can do automatic translation. It's still a little too slow and is a little clumsy to use but it's getting better fast.

ddp26 3mo ago

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

theshrike79 3mo ago
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.

zawaideh 3mo ago

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.

mynameisbilly 3mo ago
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.

luciana1u 3mo ago

[flagged]

sigbottle 3mo ago

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.

cadamsdotcom 3mo ago

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

4b11b4 3mo ago

Really liked the framing on this

_pdp_ 3mo ago

Vibe-coded software require a new type of discipline that has not been invented yet.

ies7 3mo ago
Vibe-coders from non developer haven't/won't learn that discipline.

alkyon 3mo ago

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.

bobro 3mo ago

Really surprised not to see Pope Leo's recent encyclical on AI/tech mentioned here. https://www.vatican.va/content/leo-xiv/en/encyclicals/documents/20260515-magnifica-humanitas.html https://www.vatican.va/content/leo-xiv/en/encyclicals/docume...

zoobaloo 3mo ago
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.

phoneafriend 3mo ago

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?

fancyfredbot 3mo ago

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.

strix_varius 3mo ago
> 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?
- mkehrt 3mo ago
  Well, that's literally what "vibe coding means", no?
- fancyfredbot 3mo ago
  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 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.

lowbloodsugar 3mo ago

Domain Driven Design

softwaredoug 3mo ago

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.

Invictus0 3mo ago

this is just a software engineer's ego trying to protect itself in flowery language

noisy_boy 3mo ago

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.

rtpg 3mo ago

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

iririririr 3mo ago

so, is it an analogy for a better tower or a better communication breakdown?

Ozzie_osman 3mo ago

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.

deleted 3mo ago

[deleted]

peter_retief 3mo ago

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!

permalac 3mo ago
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?
- timothycoleman 3mo ago
  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.
timothycoleman 3mo ago
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

Matumio 3mo ago

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 https://www.smbc-comics.com/comic/the-village-and-the-tower

jbarber 3mo ago

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 https://pages.cs.wisc.edu/~remzi/Naur.pdf

burntcaramel 3mo ago

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.