"The future belongs to whoever understands what they just shipped."
Perfect summary.
It's like we invented a world where you can finally, _finally_ speedrun an enormous legacy codebase and all patted ourselves on the back like that was a good thing.
True, but I think there's another dimension implied: how many devs are left that understand the code? Being able to start at zero is a fascinating surprise (compared to five years ago).
At least with a person, you can say that there's one person in your org that understands the code after they write it and submit it for review.
Maybe they stick around for a while, maybe they move on to another job, but they were THERE at some point. They have a name. You can ask them questions about what they did. And hey, they still exist in the real world too, so you can get in touch with them even after they leave if you need to.
AI powered development is like a guy shows up, gets hired for 90 seconds, writes part of a feature, and dies instantly once the code hits the screen.
a comment I cannot stop thinking about is "we need to start thinking about production as throw away" Which is a wild thought to think about when I think about on my career. We had so many dbs or servers that we couldn't touch because they were a special snowflake
Yup. AI can't automate long-term responsibility and ownership of a product. It can produce output quicker but somebody still has to be responsible to the customer using said product. The hard limit is still the willingness of the human producing the code to back what's been output.
I agree with most of the article, right up to the point where the assumption is that AI will make things worse.
We have reached a point of complexity and short-termism where it's standard practice to shove a huge, barely tested mass of Python, JavaScript, shell scripts, and who knows what else inside a docker container and call it done. Complete with hundreds or thousands of intractable dependencies, many of which we know ~nothing about and thousands of lines of esoteric configurations for servers we have barely any hope of even getting to run optimally, let alone securely.
Most software has been awful for a while.
Already, with AI:
- We can build everything in a statically typed, analysable, and memory safe language like Rust[0], even bits that really have to interact with the shell or wider OS and would previously have been shell scripts
- We can insist on positively deranged amounts of testing, at every level
- We can easily cut the number of dependencies in our code by >50%, in many cases more like 90%
- We can do the refactor as soon as it becomes obvious that it would be a good idea
- We can implement quality of life admin and monitoring features that would otherwise sit on the backlog for eternity
- We can educate ourselves about what we've built[1] by asking questions about our codebase, build tools to understand the behaviour of our systems, etc.
So yes, I agree that "The Future Belongs to Whoever Understands What They Shipped", but unlike the author I am somewhat optimistic[2]. There is more opportunity than ever to build and understand extremely high quality software that does not accept technical debt, corner cutting to meet deadlines, or poor quality (in design or implementation), for those that engineers who are knowledgeable enough and willing to embrace the new tools.
And AI, and the tooling around it, is only getting better.
[0] or Go or even TypeScript, but there's precious little reason not to pick Rust for most use cases now
[1] of course we need to choose to, and many won't…
[2] of course, there'll also be near-infinite valueless slop and some people will get sucked into that, but this seems little different to regurgitated SEO spam, short form video, and all the non-AI enshittification we already put up with, and perhaps AI will help more of us do a better job of avoiding it
We are speedrunning legacy "codebases" all the time. Or do you conjure up your own pickaxe, mine your own minerals, produce your own electricity, and construct your own computers and networks first before you go off to develop an application? Would you even know how to do those things? That is all enormous legacy codebase that we speedrun all the time. Just add one more to it.
When I use a library someone understood it when they shipped it. It also had a long stabilisation period where bugs were fixed in it. When I use an LLM, potentially nobody understands what was just shipped and it has had no time to stabilise.
But when I'm using all of those things (pickaxe, mineral mine, power station, internet network hub), I know that there was a thinking human being that took some measure of human care and consideration when creating them. And that there are people on the other side of the economic transaction to talk to or hold accountable when something goes wrong.
You cannot understand everything. That has been the case since long before AI. I have a vague idea how the linux kernel works, and I could figure it out (I once found and fixed a bug in FreeBSD device drivers) - but I don't, I just trust it works. I've never looked at sqlite to understand how it works - I know enough SQL to be dangerous and trust it works. I know very in depth how the logging framework of my project works - maintaining that code is part of my day job and so I need to know, but the hundreds of other developers in the company that use it trust it works. Meanwhile my co-workers are writing code that I don't understand, I trust they do it well until proven otherwise.
AI is very useful, but it so far doesn't write the type of code I can trust. Thus I use it but I carefully review everything it does.
I 100% agree with this in a individual person sense, but in a humanity sense someone does understand linux very deeply and is very intentional on how they change it which to me is how I gain trust in it.
Linux is less then 40 years old. Most of the people who designed it are still alive. How will the situation be in 40 years when the current maintainers are dead? (reiserfs comes to mind - it was just becoming great when [censored] and filesystems in linux went backward for many years, will that be allowed to happen next time?)
There are systems still in use from the 1960s (maybe before) - the original authors are at least retired and likely dead. I question how well the replacements understand all that. Sure they have had to dig in and understand some parts, but what about the parts that just keep working and don't need new features?
Genuine question: is there a big inherent difference between "I don't understand this thing but I think this other human does," and "I don't understand this but I think this other AI does"?
If your answer is "yes," do you think that's inherent to the (metaphysical?) fact of it being AI or to specific limitations to current AI? If the latter, what changes to AI would let you trust it?
I don't know. AI has an understand of some really complex things, but it also does some really stupid things. Depending on which it did most recently for me I change my answer.
The question is does AI understand well enough to maintain that thing for whatever maintenance I need to do in the future?
"In short, I suggest that the programmer should continue to understand what he is doing, that his growing product remains firmly within his intellectual grip. It is my sad experience that this suggestion is repulsive to the average experienced programmer, who clearly derives a major part of his professional excitement from not quite understanding what he is doing. In this streamlined age, one of our most undernourished psychological needs is the craving for Black Magic and apparently the automatic computer can satisfy this need for the professional software engineer, who is secretly enthralled by the gigantic risks he takes in his daring irresponsibility. For his frustrations I have no remedy......"
There's a funny angle to all this. There was an article last year where the author asked AI for a web app. It installed a gigabyte of node modules and crashed on startup.
He told it to calm down and just use php, it gave him 100 lines with no dependencies that worked the first time.
The Pieter Levels stack :)
Of course, this is ideal for solo entrepreneur. If you are employed, then you cannot finish it in 100 lines. How will you get paid to maintain it for the next ten years, and hire all your friends to help you?
I think this difference in incentives explains most of what we've been complaining about for the last twenty years.
That wasn't exactly my point, but it is a related one: building on top of stuff that's constantly shifting is a great way to ensure you will always have work to do.
We went from expressing computation via formal, mostly non-ambiguous languages with strict grammar and semantics, to a fuzzy and flaky probabilistic system that tries to mimic code that was already written. What could go wrong?
I'm still balancing on whether we "need" to know what's happening.
Very few understand deeply what's happening within the computer between the cou and the bridges and the rest.
The fdiv bug in 1994 took us all by surprise because we were in a situation where bug couldn't exist in hardware, because it either works or it doesn't.
When I'm using firebase or aws, I don't know the underlying system, I don't know why some resources can be created with an underscore or other can't start with a number.
Yet it works.
We're working in layers where usually we only touch the last one. Yes, understanding the others is great to debug.
I'm even wondering whether we need tests when they are written by the same llm that wrote the code.
> I'm still balancing on whether we "need" to know what's happening.
Of course we do. Otherwise we start trying to water crops with Brawndo
> Very few understand deeply what's happening within the computer between the cou and the bridges and the rest
But it's very very important that those people deeply understand it. We cannot replace their actual knowledge with LLM approximations of their knowledge
>Otherwise we start trying to water crops with Brawndo
But it got electrolytes !
For now it seems we're veering towards even more specialization in roles.
The concept of "Full Stack" might disappear because, well any LLM can center a div now and create the sql query that fills it with data.
When asking a LLM about "any sre interview question that LLM got wrong ?", it identifies the questions and the corrects answers.
I should take some time to discuss with an LLM to see their answer for one of my last assignment where the underlying issue revealed by bad performance was simply that the client shouldn't have used relational db for almost immutable documents.
And that they should have bought a math library instead of writing their own.
I keep seeing the canard that "Anyone with an idea and access to an AI agent can ship a product. What used to take a team of twenty and six months now takes one person and a weekend. That's not hype. It's happening right now, everywhere, all at once."
But I don't see it. Where is this glut of software?
It is not true. Speaking from experience: family member tried this and they couldn't get past a landing page.
I suppose if one is simultaneously ignorant when it comes to software and an expert at agentic workflow, then yeah sure, maybe--at the cost of how many tokens, though? But logically it seems that the former would preclude the latter.
Also, the "get it done in a weekend" seems to be a gross exaggeration.
I am mainly seeing across a lot of my engineer friends and mentor who I respect deeply.
They are using swarms of agents to build crms, small business and run their homelabs.
There's a massive difference between launching a piece of software and launching a successful business.
Over the last couple of months I've seen a load of new "product launches" in my niche but when you look at them they're largely vibecoded and don't show deep understanding and sustainability, so it's pretty likely you'll never see them as successful businesses.
Looking at some of the related places like /r/sideproject/ there's a lot of releases and I'd be willing to suggest that most of them are using LLMs
Then, respectfully, what is the point? Does the trillions-of-dollars AI industry exist to support a few hobbyists building niche products to scratch their own itch? I thought the promise here is increased productivity, presumably in the economic sense.
There seems to be a lot of hype, and has been for years, but I’m not seeing it materialize as actual economic output. Surely by now there should be lots of businesses springing up to capture all of this value created by vibecoded software.
Whilst I have no special knowledge, my expectation is it'll do both. If you reduce the barriers to coding you'll get more code, both at the hobbyist/one-person level and also at the large corp level.
Whether that translates into more value for those larger corps is the trillion dollar question :) Writing code is a small part of the process of finding and shipping features that customers want, so it remains to be seen how much LLM tools translate it.
I think it's fairly widely accepted that from a financial standpoint we're in an AI/LLM bubble. There has been more investment than we're likely to see financial benefits, but it's impossible to predict to what degree (if you can predict that and the timing you can make a lot of money!!)
eventually i realised it was cheaper just to vibecode and buy put options over my company
by managing the risk of failure and technical debt with a financial instrument, i have a lot more freedom to move fast and break things, and scale aggressively
it is if you have specific event driven knowledge that the put options would gain from
but if you just buy deep out of the money put options every year, say 50% price drop, in a 10b5-1 structure, its ok. you will get sued a bit more than usual
not much different than buying life insurance, except if your company crashes like monday.com , some schmuck who sold you the puts will have to pay you a tonne of cash then you can do a dilutionary rights issue or just use the cash buy a boat in miami and start something else
Others are pointing out that you cannot understand everything - and that's true enough.
But you only need to understand what's important. The experience of a good expert helps you to find that out.
As a systems administrator the recent AWS outage in the Middle East is the best recent example. There will be roughly three types of companies, separated by their understanding:
- Don't Understand - these companies thought that the cloud would handle this kind of thing for them, and are probably going to be doing a lot of finger-pointing in the near future.
- Do Understand, Don't Care - these companies did understand that high availability meant going multi-region, but decided against it for whatever reason. Probably cost vs perceived likelihood. These companies know that they've made a mistake. Short term they're wondering how to survive it, long term they'll be re-assessing their risk acceptance. Many may decide to stay single-region, but at least understand why.
- Do Understand, Do Care - these companies will simply be checking that their procedures worked for any manual parts of their failover, plus possibly looking at any improvements they can make given the real-life experience they've gained.
An LLM is just going to tell you how to implement it. It's not going to be thinking "what sort of availability do we require?", it may never start that conversation unless explicitly prompted. And even then it's going to return consensus opinions, which may not be what you want when evaluating risk.
I'd love to think a lot of companies will be looking at this event and updating their own risk register or justifying their existing risk decisions for hosting. But let's be honest - most won't even have thought about it, and won't until it goes wrong.
This person has never worked with several decades old government, bank or tax (return) code where all that's ever done is edge cases and implementations of new laws and capabilities being forever bolted on to each other. Systems that were half migrated from a PL/I / Cobol mess to java 7 by Accenture, until the money ran out with the result being that both systems now exist forever and have to be integrated into each other for years. In the end you have decades old code bases maintained by people with less than 10 years of total work tenure, who will leave for greener pastures soon. No one to ask but some old grumpy grey beard with a royal salary who barely does any work but has some ancient wisdom to share.
No one understanding what's going on inside of complex systems in financially constrained environments built and maintained by average, at best, engineers is the norm and is what keeps the world running.
None of that is a symptom of AI. The only change AI brings is that even first person developers don't know anymore what the fuck they just deployed.
I agree with all of this, but that's assuming we've reached a plateau. Maybe Claude 6.3 will be able to churn through 10M lines of Java and Cobol, tidy it and convert it to Rust. Or maybe not, but so far the scaling laws are holding.
Oh I am sure with the right prompts and the right chunking and subagents this is already possible today. But converting the old cobol mess to java code that is "most likely doing the same things" is just a fraction of the work.
You need to run those systems in parallel, integrate them in each other or have an abstraction/two-rails layer in front of them, test, test, test and test again, all of which takes months, while new features now need to be added to both systems, whether by AI or some average developer schmuck!
Do you have any idea how much any of this costs? Mind boggling amounts of money. Infrastructure costs will at least DOUBLE for several MONTHS. Meanwhile you will need extra manpower and AI credits for MONTHS on top of your increased existing costs for maintenance and new features.
You don't need to convince me that this is hell, in particular with all the managers who have never written a single line of code being now convinced that programming is completely solved.
Should the goal really be to build a system that we completely understand, or build a system that solves a problem? Like we dont fully understand quantum physics, yet good enough to build helpful systems on top of it. Or like not knowing exactly what every bee in a hive does at any moment, yet still reliably harvesting honey in the end? I think people have this modernist desire for absolute truths and certainty, where the world we live in clearly is postmodern. There are no certainties, only probabilities. So embrace the chaos, try to build systems that help to contain entropy for some useful purposes, and accept that all of them will eventually fail in some way and you will need to course correct. Faulkner is dead, long live Pynchon
Someone needs to verify it works enough to trust the output. Of course some things are more critical than others. I don't worry too much about a badly written game, just is it fun - but I still don't want it to delete or transfer my money while I'm playing. However there are also systems where people die if it fails and those need to have a lot more trust/understanding.
Abstractions have been happening since the 1970s when ASM was replaced by the C Programming Language. From there we got C++ (look, it actually has a string type that most humans understand!) then we got memory safe managed languages like Go that is almost human readable, runs almost everywhere and doesn't have buffer overflows.
ASM was machine specific. C was portable but required expert programmers. C++ was even more user friendly, but still very hard for normal people. Today, most anyone can write a program in Go.
The more we abstract, the less knowledge/expertise is needed. So yes, programs are being built by people who don't really understand what they are doing. That is intended.
Abstractions truncate the decision space of the layer above them by making understandable trade offs. LLMs don’t abstract anything, your code is still in python or php or Go. It just feels like they abstract if you don’t understand the output since not understanding the layer down is what we associate with non-leaky reliable abstractions. LLMs are abstractions the same way that your code editor is an abstraction- it’s not a layer, it’s an interface.
The title reminds me of the single lesson I retained from a training for upcoming people managers: "You can delegate everything except accountability."
I like the thought behind the piece, but what I think the criticisms are reacting to is the profusion of short, bursty sentences (just like the ones in the parent post), which can be great when used sparingly, but start to feel repetitive and have a "LinkedIn"-ish vibe, at least to me. For example the very end:
Most of you won't be able to answer that. And you already know it.
That's the conversation this industry needs to have. Not tomorrow. Now.
I hope you don't take this the wrong way and do continue writing - I enjoyed this piece, just wanted to give some constructive feedback
Then just post your opinions rather than the text the LLM dreamed around your opinions. Short posts and tweets tend to be well-liked on HN, there is no need to puff it up to a big blog post.
Look, I'm sympathetic to not feeling like you're a good writer, but there are plenty of writing styles which doesn't turn your opinions into overly dramatic AI slop. And now I don't even know which opinions are your own and which are from a GPT, hence my "unreadable" comment even if it sounds harsch. But it literally is impossible to infer what your opinions actually are when they have been butchered this hard in slop.
Honestly, the post itself reads very generated, very rage bate. I have so much more faith in us and our hobby/industry than this blog post.
There are reports of industries trying to use these tools to generate as much as possible, sure. There are also people generating bad art and unpleasant prose and using llms to generate nonsense they don’t pay attention to.
I don’t see why that implies that you or I lost interest in tinkering with toys we build. If I want to spend 4 weeks understanding oauth a little better by implementing a client, I still can and I still do.
Automating our builds absolutely didn’t create a cathedral of complexity while nobody noticed. It did mean I can open an Free Software project, read the build file and understand how to build the thing. That’s the opposite of generating complexity.
I worry about our future generations as much as the next person, but this low effort pabulum doesn’t represent the thoughtful industry and hobby that I love.
I don't think the hobbyist interest will go away, but I can see what's happening affecting business that use software.
For most businesses, software is just a means to an end, they don't really care how high quality and thoughtful the systems they use are (e.g. look at any piece of "enterprise" software)
What LLMs have done is made much much easier for orgs to launch new features and services both internally and externally, without necessarily understanding the complexity.
For me, that's what this post tapped into. Many orgs already have more complexity than they can reasonably handle. Massively accelerating development, is not going to make that problem better :)
>Honestly, the post itself reads very generated, very rage bate. I have so much more faith in us and our hobby/industry than this blog post.
Don't get me wrong. I think the future is very bright for software. I have friends who are scientist and biomedical professionals and I am excited to see what they are able to do with the powers of software where they don't need to care about syntax and can only lead with their intentions.
The rage bait part is mainly my frustrations manifesting. As an SRE my annoyances came off a little bit when it comes to how fast developers are shipping vs how fast our rails can maintain things.
No. Software is being centralized. If the snake oil AI companies are selling about the coming agentic age were true, then the end result is not "anyone can produce software" it is "anyone stupid enough to rent the ability to run their business from an AI vendor can produce software".
"The future belongs to whoever understands what they just shipped."
Perfect summary.
It's like we invented a world where you can finally, _finally_ speedrun an enormous legacy codebase and all patted ourselves on the back like that was a good thing.
I like that. These AIs are legacy codebase generators. Nobody knows how it works and everyone is afraid to touch it.
Anything in production is legacy; I'm pretty sure it happens as soon as the code is shipped regardless of who wrote it.
True, but I think there's another dimension implied: how many devs are left that understand the code? Being able to start at zero is a fascinating surprise (compared to five years ago).
At least with a person, you can say that there's one person in your org that understands the code after they write it and submit it for review.
Maybe they stick around for a while, maybe they move on to another job, but they were THERE at some point. They have a name. You can ask them questions about what they did. And hey, they still exist in the real world too, so you can get in touch with them even after they leave if you need to.
AI powered development is like a guy shows up, gets hired for 90 seconds, writes part of a feature, and dies instantly once the code hits the screen.
a comment I cannot stop thinking about is "we need to start thinking about production as throw away" Which is a wild thought to think about when I think about on my career. We had so many dbs or servers that we couldn't touch because they were a special snowflake
Yup. AI can't automate long-term responsibility and ownership of a product. It can produce output quicker but somebody still has to be responsible to the customer using said product. The hard limit is still the willingness of the human producing the code to back what's been output.
I agree with most of the article, right up to the point where the assumption is that AI will make things worse.
We have reached a point of complexity and short-termism where it's standard practice to shove a huge, barely tested mass of Python, JavaScript, shell scripts, and who knows what else inside a docker container and call it done. Complete with hundreds or thousands of intractable dependencies, many of which we know ~nothing about and thousands of lines of esoteric configurations for servers we have barely any hope of even getting to run optimally, let alone securely.
Most software has been awful for a while.
Already, with AI:
- We can build everything in a statically typed, analysable, and memory safe language like Rust[0], even bits that really have to interact with the shell or wider OS and would previously have been shell scripts
- We can insist on positively deranged amounts of testing, at every level
- We can easily cut the number of dependencies in our code by >50%, in many cases more like 90%
- We can do the refactor as soon as it becomes obvious that it would be a good idea
- We can implement quality of life admin and monitoring features that would otherwise sit on the backlog for eternity
- We can educate ourselves about what we've built[1] by asking questions about our codebase, build tools to understand the behaviour of our systems, etc.
So yes, I agree that "The Future Belongs to Whoever Understands What They Shipped", but unlike the author I am somewhat optimistic[2]. There is more opportunity than ever to build and understand extremely high quality software that does not accept technical debt, corner cutting to meet deadlines, or poor quality (in design or implementation), for those that engineers who are knowledgeable enough and willing to embrace the new tools.
And AI, and the tooling around it, is only getting better.
[0] or Go or even TypeScript, but there's precious little reason not to pick Rust for most use cases now
[1] of course we need to choose to, and many won't…
[2] of course, there'll also be near-infinite valueless slop and some people will get sucked into that, but this seems little different to regurgitated SEO spam, short form video, and all the non-AI enshittification we already put up with, and perhaps AI will help more of us do a better job of avoiding it
We are speedrunning legacy "codebases" all the time. Or do you conjure up your own pickaxe, mine your own minerals, produce your own electricity, and construct your own computers and networks first before you go off to develop an application? Would you even know how to do those things? That is all enormous legacy codebase that we speedrun all the time. Just add one more to it.
When I use a library someone understood it when they shipped it. It also had a long stabilisation period where bugs were fixed in it. When I use an LLM, potentially nobody understands what was just shipped and it has had no time to stabilise.
I sure don't.
But when I'm using all of those things (pickaxe, mineral mine, power station, internet network hub), I know that there was a thinking human being that took some measure of human care and consideration when creating them. And that there are people on the other side of the economic transaction to talk to or hold accountable when something goes wrong.
You're talking about layers of abstraction, OP was talking about an ever ballooning mass of code in the same layer of abstraction
That’s all legacy but none of it is speedrunning.
If we could conjure pickaxes and electric power plants in a single day, that would be speedrunning.
You cannot understand everything. That has been the case since long before AI. I have a vague idea how the linux kernel works, and I could figure it out (I once found and fixed a bug in FreeBSD device drivers) - but I don't, I just trust it works. I've never looked at sqlite to understand how it works - I know enough SQL to be dangerous and trust it works. I know very in depth how the logging framework of my project works - maintaining that code is part of my day job and so I need to know, but the hundreds of other developers in the company that use it trust it works. Meanwhile my co-workers are writing code that I don't understand, I trust they do it well until proven otherwise.
AI is very useful, but it so far doesn't write the type of code I can trust. Thus I use it but I carefully review everything it does.
>You cannot understand everything.
I 100% agree with this in a individual person sense, but in a humanity sense someone does understand linux very deeply and is very intentional on how they change it which to me is how I gain trust in it.
does trust change when the entire SLDC is AI?
Linux is less then 40 years old. Most of the people who designed it are still alive. How will the situation be in 40 years when the current maintainers are dead? (reiserfs comes to mind - it was just becoming great when [censored] and filesystems in linux went backward for many years, will that be allowed to happen next time?)
There are systems still in use from the 1960s (maybe before) - the original authors are at least retired and likely dead. I question how well the replacements understand all that. Sure they have had to dig in and understand some parts, but what about the parts that just keep working and don't need new features?
Genuine question: is there a big inherent difference between "I don't understand this thing but I think this other human does," and "I don't understand this but I think this other AI does"?
If your answer is "yes," do you think that's inherent to the (metaphysical?) fact of it being AI or to specific limitations to current AI? If the latter, what changes to AI would let you trust it?
I don't know. AI has an understand of some really complex things, but it also does some really stupid things. Depending on which it did most recently for me I change my answer.
The question is does AI understand well enough to maintain that thing for whatever maintenance I need to do in the future?
People also do some really stupid things, I'll just throw out.
But it also kind of sounds like you're just saying that there's a scalar of "get a little better" before you'd trust AI with something.
Also I'm reserving the right to discover other areas of concern. But yes overall I'm waiting to see if it gets better by enough.
SDLC ? software development life cycle ?
Yeah, software development life cycle.
"In short, I suggest that the programmer should continue to understand what he is doing, that his growing product remains firmly within his intellectual grip. It is my sad experience that this suggestion is repulsive to the average experienced programmer, who clearly derives a major part of his professional excitement from not quite understanding what he is doing. In this streamlined age, one of our most undernourished psychological needs is the craving for Black Magic and apparently the automatic computer can satisfy this need for the professional software engineer, who is secretly enthralled by the gigantic risks he takes in his daring irresponsibility. For his frustrations I have no remedy......"
There's a funny angle to all this. There was an article last year where the author asked AI for a web app. It installed a gigabyte of node modules and crashed on startup.
He told it to calm down and just use php, it gave him 100 lines with no dependencies that worked the first time.
The Pieter Levels stack :)
Of course, this is ideal for solo entrepreneur. If you are employed, then you cannot finish it in 100 lines. How will you get paid to maintain it for the next ten years, and hire all your friends to help you?
I think this difference in incentives explains most of what we've been complaining about for the last twenty years.
You don't have to go whole-hog and go back to PHP, a reasonable Django application would suffice :)
But the point remains: the NPM monoculture is indefensible.
That wasn't exactly my point, but it is a related one: building on top of stuff that's constantly shifting is a great way to ensure you will always have work to do.
We went from expressing computation via formal, mostly non-ambiguous languages with strict grammar and semantics, to a fuzzy and flaky probabilistic system that tries to mimic code that was already written. What could go wrong?
I'm still balancing on whether we "need" to know what's happening.
Very few understand deeply what's happening within the computer between the cou and the bridges and the rest.
The fdiv bug in 1994 took us all by surprise because we were in a situation where bug couldn't exist in hardware, because it either works or it doesn't.
When I'm using firebase or aws, I don't know the underlying system, I don't know why some resources can be created with an underscore or other can't start with a number.
Yet it works.
We're working in layers where usually we only touch the last one. Yes, understanding the others is great to debug.
I'm even wondering whether we need tests when they are written by the same llm that wrote the code.
> I'm still balancing on whether we "need" to know what's happening.
Of course we do. Otherwise we start trying to water crops with Brawndo
> Very few understand deeply what's happening within the computer between the cou and the bridges and the rest
But it's very very important that those people deeply understand it. We cannot replace their actual knowledge with LLM approximations of their knowledge
>Otherwise we start trying to water crops with Brawndo
But it got electrolytes !
For now it seems we're veering towards even more specialization in roles.
The concept of "Full Stack" might disappear because, well any LLM can center a div now and create the sql query that fills it with data.
When asking a LLM about "any sre interview question that LLM got wrong ?", it identifies the questions and the corrects answers.
I should take some time to discuss with an LLM to see their answer for one of my last assignment where the underlying issue revealed by bad performance was simply that the client shouldn't have used relational db for almost immutable documents.
And that they should have bought a math library instead of writing their own.
The whole point of AI is that we don't have to think anymore. Knowing what's going on is the AI's job.
Not saying that's how it should be, that's just the world I predict in the not too distant future.
I love thinking, but most people I know seem to experience it as a form of physical pain.
I keep seeing the canard that "Anyone with an idea and access to an AI agent can ship a product. What used to take a team of twenty and six months now takes one person and a weekend. That's not hype. It's happening right now, everywhere, all at once."
But I don't see it. Where is this glut of software?
It is not true. Speaking from experience: family member tried this and they couldn't get past a landing page.
I suppose if one is simultaneously ignorant when it comes to software and an expert at agentic workflow, then yeah sure, maybe--at the cost of how many tokens, though? But logically it seems that the former would preclude the latter.
Also, the "get it done in a weekend" seems to be a gross exaggeration.
I am mainly seeing across a lot of my engineer friends and mentor who I respect deeply. They are using swarms of agents to build crms, small business and run their homelabs.
Where are these small businesses and startups? The software economy should be booming, right? I’m not seeing it.
There's a massive difference between launching a piece of software and launching a successful business.
Over the last couple of months I've seen a load of new "product launches" in my niche but when you look at them they're largely vibecoded and don't show deep understanding and sustainability, so it's pretty likely you'll never see them as successful businesses.
Looking at some of the related places like /r/sideproject/ there's a lot of releases and I'd be willing to suggest that most of them are using LLMs
Then, respectfully, what is the point? Does the trillions-of-dollars AI industry exist to support a few hobbyists building niche products to scratch their own itch? I thought the promise here is increased productivity, presumably in the economic sense.
There seems to be a lot of hype, and has been for years, but I’m not seeing it materialize as actual economic output. Surely by now there should be lots of businesses springing up to capture all of this value created by vibecoded software.
Whilst I have no special knowledge, my expectation is it'll do both. If you reduce the barriers to coding you'll get more code, both at the hobbyist/one-person level and also at the large corp level.
Whether that translates into more value for those larger corps is the trillion dollar question :) Writing code is a small part of the process of finding and shipping features that customers want, so it remains to be seen how much LLM tools translate it.
I think it's fairly widely accepted that from a financial standpoint we're in an AI/LLM bubble. There has been more investment than we're likely to see financial benefits, but it's impossible to predict to what degree (if you can predict that and the timing you can make a lot of money!!)
Ever since Opus 4.6 came out, I've "vibecoded" a bunch of personal apps/CLIs that would've taken me months before. Some examples:
- CLI voice changer with cloned Overwatch voices on ElevenLabs.
- Brother P-Touch label maker using HTML/CSS. Their app is absolutely atrocious.
- Converted a FileMaker CRM into a Next.js/Supabase app.
- Dozens of drag-n-drop or 1-click/CLI tools. Think flattening a folder, a zip file.
- Dozens of Chrome Extensions and TamperMonkey user scripts. Think blocking ads with very targeted xpath.
But when I think about sharing them it feels like what's the point since anyone can make them themselves?
[dead]
In a similar fashion it appears that article was automated - did the author read every word in their own article?
I tried to write it more stream consciousness
Sorry but this has all red flags of llm written, beyond reasonable defense.
eventually i realised it was cheaper just to vibecode and buy put options over my company
by managing the risk of failure and technical debt with a financial instrument, i have a lot more freedom to move fast and break things, and scale aggressively
Would this not be considered insider trading? Serious question
it is if you have specific event driven knowledge that the put options would gain from
but if you just buy deep out of the money put options every year, say 50% price drop, in a 10b5-1 structure, its ok. you will get sued a bit more than usual
not much different than buying life insurance, except if your company crashes like monday.com , some schmuck who sold you the puts will have to pay you a tonne of cash then you can do a dilutionary rights issue or just use the cash buy a boat in miami and start something else
Insider trading is misappropriating knowledge. Not really misappropriation here.
Maybe you're looking for 'moral hazard'?
Not a bad article - thanks!
Others are pointing out that you cannot understand everything - and that's true enough.
But you only need to understand what's important. The experience of a good expert helps you to find that out.
As a systems administrator the recent AWS outage in the Middle East is the best recent example. There will be roughly three types of companies, separated by their understanding:
- Don't Understand - these companies thought that the cloud would handle this kind of thing for them, and are probably going to be doing a lot of finger-pointing in the near future.
- Do Understand, Don't Care - these companies did understand that high availability meant going multi-region, but decided against it for whatever reason. Probably cost vs perceived likelihood. These companies know that they've made a mistake. Short term they're wondering how to survive it, long term they'll be re-assessing their risk acceptance. Many may decide to stay single-region, but at least understand why.
- Do Understand, Do Care - these companies will simply be checking that their procedures worked for any manual parts of their failover, plus possibly looking at any improvements they can make given the real-life experience they've gained.
An LLM is just going to tell you how to implement it. It's not going to be thinking "what sort of availability do we require?", it may never start that conversation unless explicitly prompted. And even then it's going to return consensus opinions, which may not be what you want when evaluating risk.
I'd love to think a lot of companies will be looking at this event and updating their own risk register or justifying their existing risk decisions for hosting. But let's be honest - most won't even have thought about it, and won't until it goes wrong.
This person has never worked with several decades old government, bank or tax (return) code where all that's ever done is edge cases and implementations of new laws and capabilities being forever bolted on to each other. Systems that were half migrated from a PL/I / Cobol mess to java 7 by Accenture, until the money ran out with the result being that both systems now exist forever and have to be integrated into each other for years. In the end you have decades old code bases maintained by people with less than 10 years of total work tenure, who will leave for greener pastures soon. No one to ask but some old grumpy grey beard with a royal salary who barely does any work but has some ancient wisdom to share.
No one understanding what's going on inside of complex systems in financially constrained environments built and maintained by average, at best, engineers is the norm and is what keeps the world running.
None of that is a symptom of AI. The only change AI brings is that even first person developers don't know anymore what the fuck they just deployed.
Cries in defense contractor nosies. (I have)
I wanted to touch on this point but then this post started getting WAY too long.
>the only change AI brings is that even first person developers don't know anymore what the fuck they just deployed.
This to me is going to make your first point 100x worse in every damn way
AI may not be the source of the problem but can make it a hundred times worse.
I agree with all of this, but that's assuming we've reached a plateau. Maybe Claude 6.3 will be able to churn through 10M lines of Java and Cobol, tidy it and convert it to Rust. Or maybe not, but so far the scaling laws are holding.
Oh I am sure with the right prompts and the right chunking and subagents this is already possible today. But converting the old cobol mess to java code that is "most likely doing the same things" is just a fraction of the work.
You need to run those systems in parallel, integrate them in each other or have an abstraction/two-rails layer in front of them, test, test, test and test again, all of which takes months, while new features now need to be added to both systems, whether by AI or some average developer schmuck!
Do you have any idea how much any of this costs? Mind boggling amounts of money. Infrastructure costs will at least DOUBLE for several MONTHS. Meanwhile you will need extra manpower and AI credits for MONTHS on top of your increased existing costs for maintenance and new features.
Welcome to a new hell! LLM can't solve this!
You don't need to convince me that this is hell, in particular with all the managers who have never written a single line of code being now convinced that programming is completely solved.
Should the goal really be to build a system that we completely understand, or build a system that solves a problem? Like we dont fully understand quantum physics, yet good enough to build helpful systems on top of it. Or like not knowing exactly what every bee in a hive does at any moment, yet still reliably harvesting honey in the end? I think people have this modernist desire for absolute truths and certainty, where the world we live in clearly is postmodern. There are no certainties, only probabilities. So embrace the chaos, try to build systems that help to contain entropy for some useful purposes, and accept that all of them will eventually fail in some way and you will need to course correct. Faulkner is dead, long live Pynchon
Someone needs to verify it works enough to trust the output. Of course some things are more critical than others. I don't worry too much about a badly written game, just is it fun - but I still don't want it to delete or transfer my money while I'm playing. However there are also systems where people die if it fails and those need to have a lot more trust/understanding.
Abstractions have been happening since the 1970s when ASM was replaced by the C Programming Language. From there we got C++ (look, it actually has a string type that most humans understand!) then we got memory safe managed languages like Go that is almost human readable, runs almost everywhere and doesn't have buffer overflows.
ASM was machine specific. C was portable but required expert programmers. C++ was even more user friendly, but still very hard for normal people. Today, most anyone can write a program in Go.
The more we abstract, the less knowledge/expertise is needed. So yes, programs are being built by people who don't really understand what they are doing. That is intended.
Abstractions truncate the decision space of the layer above them by making understandable trade offs. LLMs don’t abstract anything, your code is still in python or php or Go. It just feels like they abstract if you don’t understand the output since not understanding the layer down is what we associate with non-leaky reliable abstractions. LLMs are abstractions the same way that your code editor is an abstraction- it’s not a layer, it’s an interface.
The title reminds me of the single lesson I retained from a training for upcoming people managers: "You can delegate everything except accountability."
Actually unreadable
It would be so much easier just to see the three or four bullet points given to the LLM than to read it.
Im not a writer. Just a guy with an opinion
I like the thought behind the piece, but what I think the criticisms are reacting to is the profusion of short, bursty sentences (just like the ones in the parent post), which can be great when used sparingly, but start to feel repetitive and have a "LinkedIn"-ish vibe, at least to me. For example the very end:
I hope you don't take this the wrong way and do continue writing - I enjoyed this piece, just wanted to give some constructive feedbackI have been doing most of my writing over there...honestly I hate it. So thank you for the feedback.
Then just post your opinions rather than the text the LLM dreamed around your opinions. Short posts and tweets tend to be well-liked on HN, there is no need to puff it up to a big blog post.
Look, I'm sympathetic to not feeling like you're a good writer, but there are plenty of writing styles which doesn't turn your opinions into overly dramatic AI slop. And now I don't even know which opinions are your own and which are from a GPT, hence my "unreadable" comment even if it sounds harsch. But it literally is impossible to infer what your opinions actually are when they have been butchered this hard in slop.
Honestly, the post itself reads very generated, very rage bate. I have so much more faith in us and our hobby/industry than this blog post.
There are reports of industries trying to use these tools to generate as much as possible, sure. There are also people generating bad art and unpleasant prose and using llms to generate nonsense they don’t pay attention to.
I don’t see why that implies that you or I lost interest in tinkering with toys we build. If I want to spend 4 weeks understanding oauth a little better by implementing a client, I still can and I still do.
Automating our builds absolutely didn’t create a cathedral of complexity while nobody noticed. It did mean I can open an Free Software project, read the build file and understand how to build the thing. That’s the opposite of generating complexity.
I worry about our future generations as much as the next person, but this low effort pabulum doesn’t represent the thoughtful industry and hobby that I love.
I don't think the hobbyist interest will go away, but I can see what's happening affecting business that use software.
For most businesses, software is just a means to an end, they don't really care how high quality and thoughtful the systems they use are (e.g. look at any piece of "enterprise" software)
What LLMs have done is made much much easier for orgs to launch new features and services both internally and externally, without necessarily understanding the complexity.
For me, that's what this post tapped into. Many orgs already have more complexity than they can reasonably handle. Massively accelerating development, is not going to make that problem better :)
>Honestly, the post itself reads very generated, very rage bate. I have so much more faith in us and our hobby/industry than this blog post.
Don't get me wrong. I think the future is very bright for software. I have friends who are scientist and biomedical professionals and I am excited to see what they are able to do with the powers of software where they don't need to care about syntax and can only lead with their intentions.
The rage bait part is mainly my frustrations manifesting. As an SRE my annoyances came off a little bit when it comes to how fast developers are shipping vs how fast our rails can maintain things.
Whoa a CEO writing about why their product is especially important in this very moment!
> Software is being democratized.
No. Software is being centralized. If the snake oil AI companies are selling about the coming agentic age were true, then the end result is not "anyone can produce software" it is "anyone stupid enough to rent the ability to run their business from an AI vendor can produce software".
[dead]