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.
>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.
If coding were solved, then this would be true no?
There are far more moving pieces in deploying an application than coding. My impression is TFA is arguing that replacing humans with LLMs for coding would make other things like quality assurance more difficult, in which case I disagree.
> 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.
At least some places are abolishing formal QA because LLMs. There's a cult of speed uber alles that has a big intersection with LLM enthusiasm.
It's very amusing how for a decade, The Way (TM) has been "move fast and break things", but now with LLMs it's suddenly "woah, AI is moving so fast, it's going to break things!"
If you can quantify quality/reliability/understandability, you can tell LLM what kind of code do you expect. If not, you get whatever.
At my current place we not only have automated tests, static analysis and static rector (linting, but also automatic pattern matcher for problematic code) but also:
- architecture tests that define relationships between application layers
- ADRs that guide developers (and agents as well) that communicate how new code should be written and how existing code should be treated
I find that "how code should look like"/"what code should do" is an ambiguous idea that always is preached, but never defined = everyone's idea of quality is slightly different and only looking at existing code you tend to align. Everyone's idea of what the product does/should do is kept within their heads. If we define this knowledge in writing LLMs can not only write code according to the patterns that are thus defined, review existing code based on these documents, but also actually read acceptance criteria documents to check if the code does what it's intended to do (gherkin)
Same goes for understandability - if LLM applies one pattern this time, another pattern another time, if you have multiple coding patterns then that hurts clarity. Sometimes LLMs work as common denominator thus achieving clarity, but I find that actually giving LLMs reference works.
> I think this false dichotomy between using LLMs and caring about quality/reliability needs to stop
I agree. What does coverage-guided fuzzing fuzz if there is 100% test coverage?
So, then, 100% branch test coverage is not a sufficient metric (because it doesn't indicate whether the code is fuzzed or formally verified for example).
Would Branch coverage even be a sufficient software quality metric if we were to instead measure how many times each branch of code is covered by tests? How to verify that one test which executes 100% of the code and runs only one assertion on, say, a CLI utility exit code integer is actually sufficiently covering?
> I think a codebase generated by AI is actually more understandable than one generated by humans at this point,
From doing a larger port (of sphinx, docutils, myst-md-parser, pygments, to rust in westurner/dsport) with a lot of human in the loop and currently ~80% branch coverage,
this seems to be at least initially true but just like real life there's drift from even a good plan that you pay a more expensive model to prepare.
I suppose it's the same challenge as architectural drift in open source non-LLM-assisted products and the solutions are pretty much the same: give better instructions (AGENTS.md,) and use better sufficiency criteria as an engineering manager (branch test coverage, fuzzing, formal methods, TLA+), and train and pay humans to do secure code review.
Sometimes the agent doesn't notice that the code already solves for that and implements its own implementation with tests and it's wastefully redundant when the code should be refactored and the tests should be refactored so that we can delete code in order to minimize bloat.
Unfortunately often, just like IRL software development, the response from the agent is not sufficient to close the issue.
One proposed solution for this that is in retrospect obvious and also essential to success in "normal"/"traditional"/"legacy" (non-AI) engineering projects, is to always verify whether the candidate solution satisfies the criteria;
From "Groundtruth – checks your AI coding agent's claims against the Git diff" <a href="https://news.ycombinator.com/item?id=48838209">https://news.ycombinator.com/item?id=48838209 :
> "Follow up to verify that the work was actually satisfactorily completed"
> Are there other sound management practices that aren't yet effectively implemented in current gen agents?
Oh, and always write tests, docs, commit messages, and changelog entries; but don't waste tokens on documenting something that doesn't verifiably pass sufficient tests.
> I agree, I think this false dichotomy between using LLMs and caring about quality/reliability needs to stop.
It's not just a false dichotomy, it's intellectual dishonesty. It wasn't that long that conversations about code quality, technical debt, etc were on the front page of HN on the regular. Whether it was coding bootcamp grads who had just enough confidence to be dangerous, "just ship it!" cargo culters, or the product of management breathing down the necks of otherwise good developers, there's plenty of "human slop" running in production across servers worldwide.
I don't think it's a matter of justifying any evil, so long as the argument is made in good faith. Pushing the idea of bad code emerging from AI isn't a good faith argument.
> 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.
100%. I am really getting tired of the narrative that code before LLMs was optimally performant, perfectly architected, completely understood, and bug free...
Does the author not have the experience of working in a legacy codebase that nobody really "understood"? Something sufficiently complex where even the senior SW devs needed to scope out project work and research the codebase for dependencies or potential issues?
I fail to remember a time at LARGE_CORP where even the most experienced developers were able to scope out or design a feature without studying the existing documentation, timing diagrams, etc....
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.
suddenlybananas · · focus · HN ↗
If coding were solved, then this would be true no?
pu_pe · · focus · HN ↗
palmotea · · focus · HN ↗
At least some places are abolishing formal QA because LLMs. There's a cult of speed uber alles that has a big intersection with LLM enthusiasm.
itsalwaysgood · · focus · HN ↗
bdcravens · · focus · HN ↗
That cult was well established prior to LLMs
ModernMech · · focus · HN ↗
IAmBroom · · focus · HN ↗
eithed · · focus · HN ↗
At my current place we not only have automated tests, static analysis and static rector (linting, but also automatic pattern matcher for problematic code) but also: - architecture tests that define relationships between application layers - ADRs that guide developers (and agents as well) that communicate how new code should be written and how existing code should be treated
I find that "how code should look like"/"what code should do" is an ambiguous idea that always is preached, but never defined = everyone's idea of quality is slightly different and only looking at existing code you tend to align. Everyone's idea of what the product does/should do is kept within their heads. If we define this knowledge in writing LLMs can not only write code according to the patterns that are thus defined, review existing code based on these documents, but also actually read acceptance criteria documents to check if the code does what it's intended to do (gherkin)
Same goes for understandability - if LLM applies one pattern this time, another pattern another time, if you have multiple coding patterns then that hurts clarity. Sometimes LLMs work as common denominator thus achieving clarity, but I find that actually giving LLMs reference works.
westurner · · focus · HN ↗
I agree. What does coverage-guided fuzzing fuzz if there is 100% test coverage?
So, then, 100% branch test coverage is not a sufficient metric (because it doesn't indicate whether the code is fuzzed or formally verified for example).
Would Branch coverage even be a sufficient software quality metric if we were to instead measure how many times each branch of code is covered by tests? How to verify that one test which executes 100% of the code and runs only one assertion on, say, a CLI utility exit code integer is actually sufficiently covering?
> I think a codebase generated by AI is actually more understandable than one generated by humans at this point,
From doing a larger port (of sphinx, docutils, myst-md-parser, pygments, to rust in westurner/dsport) with a lot of human in the loop and currently ~80% branch coverage, this seems to be at least initially true but just like real life there's drift from even a good plan that you pay a more expensive model to prepare.
I suppose it's the same challenge as architectural drift in open source non-LLM-assisted products and the solutions are pretty much the same: give better instructions (AGENTS.md,) and use better sufficiency criteria as an engineering manager (branch test coverage, fuzzing, formal methods, TLA+), and train and pay humans to do secure code review.
Sometimes the agent doesn't notice that the code already solves for that and implements its own implementation with tests and it's wastefully redundant when the code should be refactored and the tests should be refactored so that we can delete code in order to minimize bloat.
Unfortunately often, just like IRL software development, the response from the agent is not sufficient to close the issue.
One proposed solution for this that is in retrospect obvious and also essential to success in "normal"/"traditional"/"legacy" (non-AI) engineering projects, is to always verify whether the candidate solution satisfies the criteria;
From "Groundtruth – checks your AI coding agent's claims against the Git diff" <a href="https://news.ycombinator.com/item?id=48838209">https://news.ycombinator.com/item?id=48838209 :
> "Follow up to verify that the work was actually satisfactorily completed"
> Are there other sound management practices that aren't yet effectively implemented in current gen agents?
Oh, and always write tests, docs, commit messages, and changelog entries; but don't waste tokens on documenting something that doesn't verifiably pass sufficient tests.
bdcravens · · focus · HN ↗
It's not just a false dichotomy, it's intellectual dishonesty. It wasn't that long that conversations about code quality, technical debt, etc were on the front page of HN on the regular. Whether it was coding bootcamp grads who had just enough confidence to be dangerous, "just ship it!" cargo culters, or the product of management breathing down the necks of otherwise good developers, there's plenty of "human slop" running in production across servers worldwide.
pona-a · · focus · HN ↗
bdcravens · · focus · HN ↗
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.
beej71 · · focus · HN ↗
Given the quantity of shit software before LLMs, they do indeed appear to be independent variables. :)
supersour · · focus · HN ↗
Does the author not have the experience of working in a legacy codebase that nobody really "understood"? Something sufficiently complex where even the senior SW devs needed to scope out project work and research the codebase for dependencies or potential issues?
I fail to remember a time at LARGE_CORP where even the most experienced developers were able to scope out or design a feature without studying the existing documentation, timing diagrams, etc....
beej71 · · focus · HN ↗