Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

-​-dangerously-skip-reading-code

olano.dev

Post reply on HN
Print view View original

111–120 of 219 posts

Re: -​-dangerously-skip-reading-code

#111

Post by charcircuit »

ricardobeat wrote: post #102

> We can’t leverage agents if our unit of work is still “add a new endpoint to the RESTful API” Why not? You just make every task faster. Not everything has to be an uncontrollable rocket launch. > We need a virtually infinite supply of requirements, engineers acting as pseudo-product designers, owning entire streams of work Why? To build what? You can only build as fast as you understand the business and your users.

>You can only build as fast as you understand the business and your users.

It should be possible to go faster by having AI understand the business and users.

Re: -​-dangerously-skip-reading-code

#112

Post by nirui »

> We can stop reading LLM-generated code just like we don’t read assembly, or bytecode, or transpiled JavaScript; our high-level language source would now be another form of machine code.

My opinion is very close to this. Currently the reason that it's bad to not reviewing/testing the code LLMs generated is because the LLMs can sometime generate bad codes. But it's a bug that can be improved. One day you'll have LLMs generating code consistently better than what a human could write. And then you just stop needing to review them. (And that's probably also the time where most programmers/developers got fired too)

Don't get surprised if anyday the LLMs starts to generate binaries directly. THAT will be impossible to read and costs more time to analyze.

Re: -​-dangerously-skip-reading-code

#113

Post by alabut »

iloveoof wrote: post #99

Software engineering has always worked this way, just not to ICs. “The LLMs produce non-deterministic output and generate code much faster than we can read it, so we can’t seriously expect to effectively review, understand, and approve every diff anymore. But that doesn’t necessarily mean we stop being rigorous, it could mean we should move rigor elsewhere.“ Direct reports, when delegated tasks by managers, product n…

Simon Willison made a similar parallel recently:

https://simonwillison.net/2026/May/6/vibe-coding-and-agentic...

  “The thing that really helps me is thinking back to when I’ve worked at larger organizations where I’ve been an engineering manager. Other teams are building software that my team depends on.

  If another team hands over something and says, “hey, this is the image resize service, here’s how to use it to resize your images”... I’m not going to go and read every line of code that they wrote.

  I’m going to look at their documentation and I’m going to use it to resize some images. And then I’m going to start shipping my own features. And if I start running into problems where the image resizer thing appears to have bugs or the performance isn’t good, that’s when I might dig into their Git repositories and see what’s going on. But for the most part I treat that as a semi-black box that I don’t look at until I need to.”

Re: -​-dangerously-skip-reading-code

#114

Post by 9029 »

nirui wrote: post #112

> We can stop reading LLM-generated code just like we don’t read assembly, or bytecode, or transpiled JavaScript; our high-level language source would now be another form of machine code. My opinion is very close to this. Currently the reason that it's bad to not reviewing/testing the code LLMs generated is because the LLMs can sometime generate bad codes. But it's a bug that can be improved. One day you'll have LLMs…

Is it possible to reason or prove the correctness of an LLM?

Re: -​-dangerously-skip-reading-code

#115

Post by arcwhite »

charcircuit wrote: post #111
ricardobeat wrote: post #102

> We can’t leverage agents if our unit of work is still “add a new endpoint to the RESTful API” Why not? You just make every task faster. Not everything has to be an uncontrollable rocket launch. > We need a virtually infinite supply of requirements, engineers acting as pseudo-product designers, owning entire streams of work Why? To build what? You can only build as fast as you understand the business and your users.

>You can only build as fast as you understand the business and your users. It should be possible to go faster by having AI understand the business and users.

It doesn't do that though. Understand. That's not how LLMs work.

Re: -​-dangerously-skip-reading-code

#116

Post by adelks »

"A sufficiently precise spec is code". I've read somewhere here before.

So guardrails, i.e. sufficiently precise spec and tests, will need to be as strict as the LLM is bad at getting the right context and asking back the right questions. I suppose at that point not much difference between a human engineer and it.

Re: -​-dangerously-skip-reading-code

#118

Post by AlexCoventry »

Uptrenda wrote: post #107
facundo_olano wrote: post #95

Author here. I'm surprised to see this surfacing now. I just wanted to clarify, since apparently the post doesn't do a good job at it, that what I discussed there is not a methodology I advocate for. The point of the post was: ok, since there are organizations mandating to maximize speed by reducing time spent on typing code (or even mandating to maximize agents usage), is there a way we can meet that requirement whi…

[flagged]

He was establishing the context of The current blog post. Very unlikely that he was doing it for Google juice.

Re: -​-dangerously-skip-reading-code

#119

Post by skydhash »

alabut wrote: post #113
iloveoof wrote: post #99

Software engineering has always worked this way, just not to ICs. “The LLMs produce non-deterministic output and generate code much faster than we can read it, so we can’t seriously expect to effectively review, understand, and approve every diff anymore. But that doesn’t necessarily mean we stop being rigorous, it could mean we should move rigor elsewhere.“ Direct reports, when delegated tasks by managers, product n…

Simon Willison made a similar parallel recently: https://simonwillison.net/2026/May/6/vibe-coding-and-agentic... “The thing that really helps me is thinking back to when I’ve worked at larger organizations where I’ve been an engineering manager. Other teams are building software that my team depends on. If another team hands over something and says, “hey, this is the image resize service, here’s how to use it to resi…

But then, the ownership is clear. And no team would be like to be pointed that their 5th iteration is also broken and can’t be relied for production usage. That’s the difference with AI code. LLM are not aligned with your goals. Any trust in them doing the right thing is very misguided.

Re: -​-dangerously-skip-reading-code

#120

Post by charcircuit »

arcwhite wrote: post #115
charcircuit wrote: post #111

Earlier quoted context omitted.

>You can only build as fast as you understand the business and your users. It should be possible to go faster by having AI understand the business and users.

It doesn't do that though. Understand. That's not how LLMs work.

LLMs are not the only possible AI models to use and create.
Post reply on HN