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

121–130 of 219 posts

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

#121

Post by culi »

urbandw311er wrote: post #97
culi wrote: post #89

Earlier quoted context omitted.

"unsafe" seems quite different from the "dangerously [...]" phrasal template. I don't think it's a stretch to suppose it was inspired by React. Still waiting for this one to catch on: React.__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED https://github.com/reactjs/react.dev/issues/3896

This is sometimes exposed in front end browser code and I had an actual (non technical) end user email our support team last month asking if it was something they should be concerned about! God knows how they found it, I suspect everyone is now an AI-enabled expert at these things…

Oh I've stumbled upon it myself while coding. You can ctrl/cmd-click into any React type and it will take you to its explicit source definition. I'm not sure if it's still the case but they used to have all of the types organized into a single file. Since I was the go-to TypeScript person at one job I had I made sure to familiarize myself with every type (less than you'd expect)

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

#122

Post by rspeele »

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…

Suppose the image resize service has some caching, and due to a bug in the caching, under certain circumstances it will respond with an already-cached resized version of a different source image.

Let's say for example it caches on something stupid like the CRC32 of the input image -- good enough that the couple dozen images in your test dataset don't collide, you don't see it in smoke testing your app, but real world data has collisions on a daily basis.

This gets into production and customer A sees a resized version of customer B's document for a thumbnail. Now customer A is wondering how many other customers are seeing resized versions of their private documents in thumbnail images. They are very very mad.

If the image resize service was built by "another team" then that other team is responsible for the bug and will take most of the heat for it. If it was built by an "agent swarm" or "gas town" or whatever under my direction then I'm 100% responsible for it and rightly deserve the heat.

That is why I cannot understand any approach that doesn't involve reading the code at all. Testing alone is not sufficient. MTTR is not sufficient because you can't make a customer less mad about a data privacy bug by fixing it.

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

#123

Post by jimmaswell »

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…

> every time I use AI for coding, to some capacity I'm sacrificing system understanding and stability in favor of programming speed.

Sure, but couldn't you say the same for letting other people contribute code too? In either case, you make the choice of how deeply you want to review it. You can ask the AI or the human to explain things that aren't clear.

For me it's case by case in either scenario. Sometimes it's not that important to look closely at a specific subsystem that's self-contained or just simple, other times I need to carefully audit whatever touches a different system. You need a good sense of the existing codebase/architecture in the first place to make these determinations.

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

#124

Post by esperent »

skydhash wrote: post #119
alabut wrote: post #113

Earlier quoted context omitted.

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.

That's why you have them write tons of tests. Way more than you generally would for human written code. And the agent writing/maintaining the tests is not the agent fixing the bugs.

I've personally had a LLM write an image resizing library for me. It's a fairly basic one, I didn't need anything fancy. I could have used something off the shelf but it was at a time when I was testing what Claude could do. And to be honest, it just worked. One shot, if I recall correctly, or at least, one session with a few tweaks and never touched again. It's been embedded in a larger app for several months and I don't recall hitting a single bug with that, specifically. So I'm not sure your complaints about "the 5th iteration" being broken have much grounds here.

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

#125

Post by rspeele »

geraneum wrote: post #70
giancarlostoro wrote: post #63

Earlier quoted context omitted.

Hate it all you want, but XML is genuinely a good fit there, and Claude is apparently insanely good at working with XML prompts.

I don’t know why, but I get this feeling whenever someone uses “insanely” or “shockingly” along with AI, I think they’re bot or are writing based on a guideline! No offense, btw, I’m not saying you’re a bot.

I'm prepared to excise the word "genuinely" from my vocabulary after working with Claude.

One of my biggest fears with using AI at work is that I will subconsciously start talking and writing like a bot, despite making conscious efforts to do the opposite. Just like how when you read a lot of books by one author, their style infects your own writing style.

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

#126

Post by furyofantares »

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…

> Currently the reason that it's bad to not reviewing/testing the code LLMs generated is that the LLMs can sometime generate bad codes.

Sometimes?

I am heavily into vibe coding and I think they almost always generate bad code. At least as soon as you're distant enough from the code to call it vibe coding.

When you're still in touch with the code, have at least been recently talking to it about code rather than 100% about features, and its context is filled with good code, it can generate good code.

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

#127

Post by skydhash »

esperent wrote: post #124
skydhash wrote: post #119

Earlier quoted context omitted.

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.

That's why you have them write tons of tests. Way more than you generally would for human written code. And the agent writing/maintaining the tests is not the agent fixing the bugs. I've personally had a LLM write an image resizing library for me. It's a fairly basic one, I didn't need anything fancy. I could have used something off the shelf but it was at a time when I was testing what Claude could do. And to be hon…

> It's a fairly basic one, I didn't need anything fancy.

> one session with a few tweaks and never touched again

> and I don't recall hitting a single bug with that, specifically.

And there you got your answer. If every scenario was as simple as that, we wouldn't really need software development teams. I'm not saying that you can't good result with an LLM tool, but most software are in constant flux and software engineering is about keeping the cost of making new changes minimal.

So if you have a dependency, you want to treat it as a black box, because it lowers the cognitive load. But you don't want it to suddenly change its contract, including breaking it in some strange way. And that brings me to...

> That's why you have them write tons of tests.

Tests are not implementation guarantee. They are a canary to warn about some errors. You assume the code is going to written in good faith, but you place alert points to warn you about possible mistakes. Because you can't really test the full implementation without having a brittle test suite (which you have to maintain).

And tests relies on a lot of assumptions (mocks, initial cases, fakes,...). Those should be treated with care. Because as soon as one are wrong, the test cases it affects are make-believe.

The only true testing of your software is done in production. Everything else is about avoiding the easy mistakes.

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

#128

Post by simoncion »

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…

> Being a manager of software developers has always been a non-deterministic form of software engineering.

I disagree. Being a manager of programmers requires that you trust your programmers and have some way of occasionally verifying the correctness and efficacy of what they build to make sure that that trust is still properly placed.

But on top of that, the user of an LLM isn't really akin to a manager of programmers. Human programmers are responsible for what they write [0], and even the ones that only cost ~50% of a senior's total comp [1] are still going to be able to fairly reliably explain to you why they made the decisions they did, and fairly reliably be able to follow instruction. LLMs just aren't there yet, and the major LLM providers may never care to get them there.

A programmer who's using LLMs is a programmer who's using LLMs... not a manager of other programmers. I'm not going to say that the tech will never advance to that point, but it's simply not there yet.

[0] Unless management decides otherwise, of course.

[1] Nvidia's CEO recently mentioned that he'd be "deeply alarmed" if senior staff aren't spending at least half of their total compensation [2] on LLM providers, so I'm going to use that as my benchmark for "expected annual LLM spend".

[2] ...meaning that each senior programmer costs their employer at least 50% more than their total compensation....

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

#129

Post by Terretta »

blacob wrote: post #106

> Then where does the rigor go? Similar to the Thoughtworks report, my first bet would be specifications (which is not the same as prompts) and tests (which is not the same as TDD). This is what we're building for at Saldor ( https://saldor.com ). It's a hard problem, to get a team in the habit of writing good specs. Probably because it's a hard thing to do: thinking of the behavior of your program, especially at the…

Saldor pitch is on point.

I have team do this using CLAUDE.md telling Claude to do it in a set of interconnected steps, but in brief: they are to make it write every aspect of transcript somewhere: PRD, research notes, spec, dev log and debate log, break/fix/retro notes, commit log, PR, release notes, README, docs .mds... heavy emphasis on the edges in our thinking, and just as important, the edges in its ability to provide good leverage.

It needs a core set of guidance on the ordering and how to write "as of" a given phase or release so context stays current, trusting the old info is in git history it can navigate for the story of how we got here.

CC's /insights claims I have 10:1 md edits to code edits, and we both note this way of working is resulting in far fewer error loops per higher quality outcome.

// So yes, interested in your product. Baking something more broadly battle tested in so we don't have to reinvent it makes sense.

Post reply on HN