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.
> Reading the code does not mean you understand the code.
Reading the code may not be enough to understand the behaviour of your program, but believing you can understand the behaviour of a program without at least reading the high level code is truly silly.
(by high level, I mean the code living in the higher layers - of course we don't often read the code of the generated assembly, or the interpreter, or the browser, but that's because they're reliable abstractions, unlike prompts!)
> believing you can understand the behaviour of a program without at least reading the high level code is truly silly.
have you ever used a library after only reading the README and documentation, or do you always pull the source and read through it before you think you understand it?
Of course. And then we fix the problem. It's no different here. The point is that reading the code first is absolutely not a requirement when adopting a new library.
It is not. But there’s an element of trust being involved. Something like libflac or libcurl, I don’t read the code. I read the doc which does outline the behavior of each function and the conceptual model. If something break, it’s quite often my code. Why? because their code is battle tested. Which is quite different from AI generated code.
That's because it's new. libflac and libcurl didn't come out as battle tested code. That takes time and...battles. And what are those battles if not people seeing issues with what those libraries are doing and fixing the code? There absolutely no reason that AI written code can't or won't become battle tested.
The battle tested part is the reason I suspect my code rather than theirs first. The trust part is in their engineering process. New project from OpenBSD or Debian, I’m ready to try. Random guy on Github, bring out the 10 foot pole.
> There absolutely no reason that AI written code can't or won't become battle tested.
I can think of 2:
1. Low trust: I'm not going to trust some rando's AI-generated code/PR when I can make my own AI generated code.
2. Fragmentation, if a lot of people are doing (1), they wont contribute to the same upstream codebase like they would in the past, which means each codebase only runs through a small subset of potential environments.
The interplay between 1 & 2 will result in a lot of siloed code.
Low trust is not a reason that code can’t be battle tested. All non battle tested code starts as low trust by default. AI written or otherwise.
But you’re right that it’s the hill climb of human trust that AI is going through right now. Some of us are just farther along than others. Some of us refuse to consider trusting AI out of fear, and not rational evaluation of its capability.
I am sure OP cannot understand the Unix file API without actually reading every line of its implementations (on each different architecture)! Or any function for that matter , what does sort do?? Impossible to know without reading the source. And I’m sure after reading the source you will know every detail of how it works and will never forget it.
It's hard for me to understand how you could work on software and not understand the qualitative difference between the Unix File API and some code that an AI spat out 5 minutes ago.
I would draw the difference here that a library is used by hundreds (of thousands) of people, and established across different scenarios. I don't read the boto3 library AWS provides, but I can trust them and the amount of customers enough to be certain enough that it behaves the way I expect it to.
The same can't be said with code we write in silos at our workplace or at home. It simply does not have the same test bench.
Yes, libraries aren't bug-free, but they give me a reliable abstraction tested in the field. Not rarely you dig into library code if you notice unexpected behavior.
If we could rely on our LLM or colleague written code, or own code, have run through the same amount of requests, sure I wouldn't need to review it, as my confidence can be north of 99.9999% it works correctly. But we can't.
I've used libraries before, where I call the API surface that they expose based on method names and parameter types, without reading all the source. Generally those libraries don't implement my software's entire problem domain area; they tend to implement things like "CSV parser" or "HTTP server". The important code, that I'm actively reading and writing, tends to be the code around those library calls.
This is different from building a product, which you only interact with via UI buttons/CLI/etc, without reading any code to understand how it conceptualizes that product's problem domain area.
People do that latter thing, and we call them "users", not "developers".
Whenever there is a bug in a library or a hard to diagnose issue and there is no information on the internet about it, I tend to just dive right into the dependency source code for debugging.
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.
jdkoeck · · focus · HN ↗
Reading the code may not be enough to understand the behaviour of your program, but believing you can understand the behaviour of a program without at least reading the high level code is truly silly.
(by high level, I mean the code living in the higher layers - of course we don't often read the code of the generated assembly, or the interpreter, or the browser, but that's because they're reliable abstractions, unlike prompts!)
rco8786 · · focus · HN ↗
have you ever used a library after only reading the README and documentation, or do you always pull the source and read through it before you think you understand it?
weakfish · · focus · HN ↗
rco8786 · · focus · HN ↗
Jare · · focus · HN ↗
If they fail you can stop using their library. If you fail your company can stop using you.
watermelon0 · · focus · HN ↗
rco8786 · · focus · HN ↗
kevinh · · focus · HN ↗
rco8786 · · focus · HN ↗
skydhash · · focus · HN ↗
rco8786 · · focus · HN ↗
skydhash · · focus · HN ↗
rco8786 · · focus · HN ↗
overfeed · · focus · HN ↗
I can think of 2:
1. Low trust: I'm not going to trust some rando's AI-generated code/PR when I can make my own AI generated code.
2. Fragmentation, if a lot of people are doing (1), they wont contribute to the same upstream codebase like they would in the past, which means each codebase only runs through a small subset of potential environments.
The interplay between 1 & 2 will result in a lot of siloed code.
rco8786 · · focus · HN ↗
But you’re right that it’s the hill climb of human trust that AI is going through right now. Some of us are just farther along than others. Some of us refuse to consider trusting AI out of fear, and not rational evaluation of its capability.
brabel · · focus · HN ↗
discreteevent · · focus · HN ↗
misterderpie · · focus · HN ↗
Yes, libraries aren't bug-free, but they give me a reliable abstraction tested in the field. Not rarely you dig into library code if you notice unexpected behavior.
If we could rely on our LLM or colleague written code, or own code, have run through the same amount of requests, sure I wouldn't need to review it, as my confidence can be north of 99.9999% it works correctly. But we can't.
rco8786 · · focus · HN ↗
[deleted] · · focus · HN ↗
[deleted]
ubertaco · · focus · HN ↗
This is different from building a product, which you only interact with via UI buttons/CLI/etc, without reading any code to understand how it conceptualizes that product's problem domain area.
People do that latter thing, and we call them "users", not "developers".
jimbokun · · focus · HN ↗
But SOMEBODY should be familiar enough with the code to fix, improve and maintain it. Using unmaintained libraries can be risky.
imtringued · · focus · HN ↗