Reading the code does not mean you understand the code. One lesson that experience in software gave me: I never understood the code. You think it works a certain way, until you find out that it doesn't.
What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.
If we are committed to it, if we put the resources towards it and dedicate the time to it (and we could do this just by saying: it will take half as long as it used to take!), software built by llms in healthcare, finance, automotive, defense, power plans, aviation, manufacturing can all be made MORE reliable and better with LLMs... without ever reading a single line of code. The LLMS are very good at logic, by the way.
Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while. I felt the same way in 2025. I've written 100s of thousands of lines of difficult code. You, the person reading this, has probably interacted with software I've written. For a time you would've interacted with it every time you made a debit card transaction in the united states, for example. I understand code, and care about quality, and that's why I'm all in on LLMs for code.
I agree, I think this false dichotomy between using LLMs and caring about quality/reliability needs to stop. All these mission critical industries listed in the article rely on extensive testing for quality assurance, with human code review being a layer on top of all that, but far from the most critical one.
Interpretability is the same, our abilities to do that have increased rather than decreased. I think a codebase generated by AI is actually more understandable than one generated by humans at this point, and you can ask clarifying questions whenever you get stuck.
TFA's points only make sense if the mental model the author has in mind is someone who writes a prompt then immediately puts an app into production without any thought behind it.
> I agree, I think this false dichotomy between using LLMs and caring about quality/reliability needs to stop
You're not going to get people to stop doing that by arguing on the internet, but in the end it won't matter, because it will stop, naturally.
In the future, you'll just get left behind and not hired if you're building code by hand, it's that simple. Even traditional code reviews are going to go away. It'll be more about the scope and then verifying correctness.
I'm not sure I understand what you're saying? To keep it simple, how much code do you expect will be written by humans in say, two years time?
I don't know about two years' time, but in ten years' time the majority of code will be written by hand. LLMs are like outsourcing to cheap labor was 20 years ago: it's trendy, but when the abysmal quality becomes apparent the pendulum will swing back.
Agreed for pure vibecoders, but I would expect vibecoding to just become a must have skill for other roles like product owners etc. Still expect some amount of developers to be retained for grooming the vibecoding environment, reviewing and incident response.
>In the future, you'll just get left behind and not hired if you're building code by hand, it's that simple. Even traditional code reviews are going to go away. It'll be more about the scope and then verifying correctness
I don't really buy it actually. There isn't really anything meaningful you can learn with how to use LLMs/agents that has a half-life greater than a few months at this point, so you can just start doing it at any point in the future and not be meaningfully left behind. On the other hand years of letting your actual engineering skills atrophy will have a negative effect on you. I've been witnessing the effects of this. Going back to more coding by hand with AI-assistance circa the 2023 era as a happy medium. I think this is the sweet spot. Full agentic engineering has nasty failure modes and in the long-term is kind of a bad option for basically everyone. I say this after having done it for almost a year at this point, and transitioning away from it now.
> I don't really buy it actually. There isn't really anything meaningful you can learn with how to use LLMs/agents that has a half-life greater than a few months at this point, so you can just start doing it at any point in the future and not be meaningfully left behind.
Right, remember how in ~2023 "prompt engineering" was ostensibly the critical thing everybody "needs to learn now or get left behind"?
I feel these tools—or at least the business-model behind them—have a pattern: Basic adoption is easy, while protecting yourself against their flaws is a shifting target where expertise goes stale.
I use a combination of prompting and hand crafting my code. Sometimes I'll sketch out the design in code, without details, other times I'll delete and change what the LLM has done. I'm still reviewing everything it does, because:
1. Other humans also review my code and I know they won't approve until they're ok with it anyway.
2. I don't trust that the verifications we have at the moment are good enough to catch the errors LLMs still make.
So trust me, I'm not a "vibe coder"
But I can see the writing on the wall. We're not really maximising the potential of these things by doing it this way. In my particular industry, we're in an arms race for clients who can easily move to a competitor. So we need to be continually improving. How I predict this unfolding is that we'll need to get much better at verification of correctness (functional and non-functional) and once that is satisfied, humans will stop manually writing and reviewing code, otherwise you'll just lose to your competitors. At least in my industry, maybe not all.
>How I predict this unfolding is that we'll need to get much better at verification of correctness (functional and non-functional) and once that is satisfied, humans will stop manually writing and reviewing code,
This also used to be my line of thinking too. I started going down this road. Then I stopped because I realised for this to really work you need the whole team to buy into it and then be competent at it, including product managers. I think it's more or less above the skill floor of the average engineer, so trying to actually implement it in a team is going to be painful. For sure I think some people will go down this road, but I think the vast majority actually will not.
efficax · · focus · HN ↗
What LLMs make possible is for me to say: find out all the ways this thing works. Analyze the different ways we can run this software, build a fuzzer, build property tests, and run this software in every scenario possible. Log full traces. Log all the outputs. Now, analyze each scenario for bugs. You can't do that by hand.
If we are committed to it, if we put the resources towards it and dedicate the time to it (and we could do this just by saying: it will take half as long as it used to take!), software built by llms in healthcare, finance, automotive, defense, power plans, aviation, manufacturing can all be made MORE reliable and better with LLMs... without ever reading a single line of code. The LLMS are very good at logic, by the way.
Anyway all of this reads like someone who is not actually using LLMs to build software or hasn't tried them in a while. I felt the same way in 2025. I've written 100s of thousands of lines of difficult code. You, the person reading this, has probably interacted with software I've written. For a time you would've interacted with it every time you made a debit card transaction in the united states, for example. I understand code, and care about quality, and that's why I'm all in on LLMs for code.
pu_pe · · focus · HN ↗
Interpretability is the same, our abilities to do that have increased rather than decreased. I think a codebase generated by AI is actually more understandable than one generated by humans at this point, and you can ask clarifying questions whenever you get stuck.
TFA's points only make sense if the mental model the author has in mind is someone who writes a prompt then immediately puts an app into production without any thought behind it.
munksbeer · · focus · HN ↗
You're not going to get people to stop doing that by arguing on the internet, but in the end it won't matter, because it will stop, naturally.
In the future, you'll just get left behind and not hired if you're building code by hand, it's that simple. Even traditional code reviews are going to go away. It'll be more about the scope and then verifying correctness.
brazukadev · · focus · HN ↗
I expect the exactly opposite to happen. These are going to be the most requested developers as the last ones that understand how it work.
They would then be convinced to use AI for speed, but vibecoders that just prompt AI are the ones that won't find jobs.
munksbeer · · focus · HN ↗
bigstrat2003 · · focus · HN ↗
munksbeer · · focus · HN ↗
brazukadev · · focus · HN ↗
sally_glance · · focus · HN ↗
slopinthebag · · focus · HN ↗
if anything the safer bet is on skill and knowledge, or else you might as well go into a different field altogether.
latentsea · · focus · HN ↗
I don't really buy it actually. There isn't really anything meaningful you can learn with how to use LLMs/agents that has a half-life greater than a few months at this point, so you can just start doing it at any point in the future and not be meaningfully left behind. On the other hand years of letting your actual engineering skills atrophy will have a negative effect on you. I've been witnessing the effects of this. Going back to more coding by hand with AI-assistance circa the 2023 era as a happy medium. I think this is the sweet spot. Full agentic engineering has nasty failure modes and in the long-term is kind of a bad option for basically everyone. I say this after having done it for almost a year at this point, and transitioning away from it now.
Terr_ · · focus · HN ↗
Right, remember how in ~2023 "prompt engineering" was ostensibly the critical thing everybody "needs to learn now or get left behind"?
I feel these tools—or at least the business-model behind them—have a pattern: Basic adoption is easy, while protecting yourself against their flaws is a shifting target where expertise goes stale.
munksbeer · · focus · HN ↗
1. Other humans also review my code and I know they won't approve until they're ok with it anyway.
2. I don't trust that the verifications we have at the moment are good enough to catch the errors LLMs still make.
So trust me, I'm not a "vibe coder"
But I can see the writing on the wall. We're not really maximising the potential of these things by doing it this way. In my particular industry, we're in an arms race for clients who can easily move to a competitor. So we need to be continually improving. How I predict this unfolding is that we'll need to get much better at verification of correctness (functional and non-functional) and once that is satisfied, humans will stop manually writing and reviewing code, otherwise you'll just lose to your competitors. At least in my industry, maybe not all.
latentsea · · focus · HN ↗
This also used to be my line of thinking too. I started going down this road. Then I stopped because I realised for this to really work you need the whole team to buy into it and then be competent at it, including product managers. I think it's more or less above the skill floor of the average engineer, so trying to actually implement it in a team is going to be painful. For sure I think some people will go down this road, but I think the vast majority actually will not.