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 don't know if we're there yet, but I have no doubt that LLMs will increasingly crank out better and better code, along with better and better logs, fuzzers, unit tests, and analyzers that, taken together, will maybe--just maybe--produce more solid code per dollar than working with human engineers.
What I'm not convinced of, and what I fear most, is the lack of accountability. When something does go wrong, who will take responsibility? I don't mean who will be tasked with fixing it; I mean who will stand up and say, "yeah, that was me, I screwed up, lesson learned, I will do better next time?" Who will then look into the code for similar issues, to find them before they wreak more havoc? Who will prioritize the different pieces of the giant puzzle in a way that makes it work better for humans, not just machines producing a sterile end result?
This trend concerns me because I see an increasing lack of ownership and a disconnect between what are ultimately human processes at either side of the computation equation: a human being (e.g. customer) trying to accomplish a goal that affects another human (e.g. business owner).
As an analogy, I'm reminded of an aspect of Japan that is in stark contrast to the US: people in Japan take deep responsibility for that which is assigned to them, especially things that aren't necessarily someone's official responsibility. Every public place is immaculately attended to. Not so much in the US, and it's not for lack of budget; anybody with five minutes to spare can sweep up the cigarette butts; they just don't care to.
So sure, your LLM steam engines may be faster and more powerful than John Henry the developer, but what happens when something goes wrong? How do I know the LLMs aren't just spitting out logs and test results that they think will please us? At a certain point, you have to dig into the code, otherwise you're no better than a CSR who is reading from a script and pretending to give a damn.
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.
kmoser · · focus · HN ↗
What I'm not convinced of, and what I fear most, is the lack of accountability. When something does go wrong, who will take responsibility? I don't mean who will be tasked with fixing it; I mean who will stand up and say, "yeah, that was me, I screwed up, lesson learned, I will do better next time?" Who will then look into the code for similar issues, to find them before they wreak more havoc? Who will prioritize the different pieces of the giant puzzle in a way that makes it work better for humans, not just machines producing a sterile end result?
This trend concerns me because I see an increasing lack of ownership and a disconnect between what are ultimately human processes at either side of the computation equation: a human being (e.g. customer) trying to accomplish a goal that affects another human (e.g. business owner).
As an analogy, I'm reminded of an aspect of Japan that is in stark contrast to the US: people in Japan take deep responsibility for that which is assigned to them, especially things that aren't necessarily someone's official responsibility. Every public place is immaculately attended to. Not so much in the US, and it's not for lack of budget; anybody with five minutes to spare can sweep up the cigarette butts; they just don't care to.
So sure, your LLM steam engines may be faster and more powerful than John Henry the developer, but what happens when something goes wrong? How do I know the LLMs aren't just spitting out logs and test results that they think will please us? At a certain point, you have to dig into the code, otherwise you're no better than a CSR who is reading from a script and pretending to give a damn.