Hacker News Reader

Comment by rco8786 | Hacker News Reader

> 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?

View on HN

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.

Nothing you’re saying excludes AI from writing code. In fact I’ll bet my salary that boto3 has AI written code in it and you happily trust it.

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".

You can use it without understanding, but this won't help you actually understand how it behaves.

I believe I can understand how a library behaves from the README and docs. I do this all the time. We all do.

You haven't run into cases where the documentation is missing or incomplete? You must be dealing with different libraries than I am.

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.

You can’t say a new project is battle tested. Those are mutually exclusive, regardless of who or what wrote the code.

> 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. Maintainer will (rightly) not trust my awesome AI-generated PR because I'm a rando to them.

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, with no accounting for taste (i.e. sensibilities developed by maintainers)

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. I’m not even sure what you mean by fragmentation tbh. This feels like a very vague argument in general.

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 wouldn’t be able to fix a bug in a library I have only called but never contributed to, without a lot of time and effort.

But SOMEBODY should be familiar enough with the code to fix, improve and maintain it. Using unmaintained libraries can be risky.

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.

No, but the authors of $LIBRARY are accountable if it fails

Are they? I've never been able to blame library authors or hold them accountable for code running in my production environment.

They are accountable for their library, you are accountable for putting it in your production environment.

If they fail you can stop using their library. If you fail your company can stop using you.

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.

Reply on news.ycombinator.com