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

201–210 of 219 posts

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

#201

Post by skydhash »

dpark wrote: post #199
skydhash wrote: post #197

Earlier quoted context omitted.

> the AI skeptics that remain in the software industry have put very little time into experimenting with AI coding. Why does everyone assume that anyone that is slightly critical has no experience whatsoever with the thing they critic? That is very dismissive. As soon as you start working on something complex, the agent requires a lot of guidance from an expert. That's not what's being marketed. If someone told you t…

> Why does everyone assume that anyone that is slightly critical has no experience whatsoever with the thing they critic? That is very dismissive. It’s because most of the criticisms around the capability (as opposed to the ethical concerns or costs) are shallow. (“But it could leak your creds.” Come on. More likely one of the ten thousand NPM dependencies you install will do that.) I’m interested in meaningful discu…

I think we're going to agree to disagree. Not that I find fault in your argument (we're both debating our opinions), but I'm concerned about reliability of the tool first.

My workflow is centered about a correct output, not speed or efficiency. But what makes it easy to get correct result makes it easy to be fast and be economical in resource consumption too. Except that you need to average over the usual period of times you need to support a project (months or years). Nice tricks like slinging a PR over the wall in a day don't matter if it's not sustainable.

Things like writing code that's been written over and over again also don't matter. It's either I know how to do it (or at least the general pattern). And then it will be a walk in the park (some relax period even, like walking between bouts of running when jogging). Or I don't know the pattern and I need to be careful to get it right.

So what saves me time ultimately the reliability of my software. When I'm not busy fixing stuff right and left and can be fairly confident when releasing. I've not found any methodology that helps with that with AI tooling being actually helpful in that regards.

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

#202

Post by jimmaswell »

stuaxo wrote: post #151
jimmaswell wrote: post #123

Earlier quoted context omitted.

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

The people can meaningfully collaborate and produce something of high quality.

I see you haven't met some of my coworkers.

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

#203

Post by QuantumNoodle »

It's too early for me to have a firm opinion one way or another.

Just a data point: this month I had a knarly bug in generated bpf code. The C language was correct but the compiler produced a bug that corrupted packets. I spent around 8 hours debugging _where_ the issue is and how to work around, never really understanding what went wrong. That knowledge came with several more days on and off looking at it--after I had mitigated the production issue.

So if I extrapolate this experience to LLMs (who are not deterministic) and who will make larger systems. What we trade for velocity we will pay for with hours of debugging because we won't understand how things work. I think this is unavoidable.

Another way I'm looking at it: after some time of not writing code, it will be analogous to instructing the LLM and the output being assembly--where I simply don't have the muscle to grok the output. How do I mitigate that knowledge gap? I see micro serves coming back. Today it is easy to slop up disposable scripts. Our services need to be modular so we can dispose of broken things--so they are only coupled with each other by strict APIs.

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

#204

Post by dpark »

skydhash wrote: post #201
dpark wrote: post #199

Earlier quoted context omitted.

> Why does everyone assume that anyone that is slightly critical has no experience whatsoever with the thing they critic? That is very dismissive. It’s because most of the criticisms around the capability (as opposed to the ethical concerns or costs) are shallow. (“But it could leak your creds.” Come on. More likely one of the ten thousand NPM dependencies you install will do that.) I’m interested in meaningful discu…

I think we're going to agree to disagree. Not that I find fault in your argument (we're both debating our opinions), but I'm concerned about reliability of the tool first. My workflow is centered about a correct output, not speed or efficiency. But what makes it easy to get correct result makes it easy to be fast and be economical in resource consumption too. Except that you need to average over the usual period of t…

I don’t know anything about your work so I can’t speak to that. What I do know is that intentionally pushing my use of AI (to the point that at times it was clearly a detriment) taught me a lot about how I can use it effectively, how I cannot, and sometimes where I still need to invest to be more effective with it. AI is not magic but it has proven very useful in many cases (not all cases) for me.

But yes, agree to disagree. I’m not here to evangelize AI and I hope you have success regardless of whether you use AI coding.

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

#205

Post by EFLKumo »

trimethylpurine wrote: post #180
EFLKumo wrote: post #177

> just like we don’t read assembly, or bytecode, or transpiled JavaScript This makes sense since certain higher-level code produces certain lower-level code, while LLM cannot. If the transpired JS code doesn't work we could just find out the bug in minifiers, etc. but one cannot figure out why LLM fails at one task, especially considering LLMs, even SOTA ones, could be strongly affected by even small prompt changes.…

Couldn't we slowly add guardrails that eventually lead to code generation becoming more and more deterministic over time? I'm seeing in my experience that Claude has become better with every version at producing uniformity in its code output. Especially where the architecture is clear and documented. And even more so in languages with built in uniformity (Go, HTMX, SQL) where there is intentionally only one or two wa…

I once thought about this and found that n-shots makes greater influences on LLMs. In other words, in a repo with good code quality and architecture (which offers good n-shots) and on a task with clear instructions and goals, LLM's output seems reliable enough, which meets your opinion. And n-shots is always better than relying on instruction following, instruction following mentioned in the article ("specifications") as an approach facing LLM's productivity, so imo the idea you suggested is another probability against/comparing with the article as well.

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

#206

Post by npodbielski »

LtWorf wrote: post #194
npodbielski wrote: post #193

Earlier quoted context omitted.

I am talking about applications like to do lists. Or you running app. Or I do not know... Currency exchange calculator. People do not care about that data. Ordinary person maybe would be a bit sad about loosing emails but not terribly. Maybe half of people would be trying to get their picture back rest would just say 'oh well...' And moved on.

Ah yes, things that students make their first week. Surely developers aren't paid to do those?

I have no idea what you are talking about.

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

#207

Post by khasan222 »

sokoloff wrote: post #154
khasan222 wrote: post #147

Earlier quoted context omitted.

For sure every time you use ai you’re sacrificing understanding if you don’t plan out and understand how exactly the ai is going to do the work you asked it to do. The same output that is such a bad thing in this article can also be used to gain context, by making a thorough plan with your ai first, reading through the plan and proposing changes just like you would with a real developer. You can also use this output…

I think most people test at least a happy path of their code end to end. I think we can all agree that your last sentence is far more aspirational than bare minimum standard practice. (“I believe we should be spending our energy thoroughly manually testing a feature to make sure when we brainstormed we actually did get every edge case, and it works well.”) I did one small side web project by only writing spec tests a…

My last sentence is definitely aspirational, it is how I try and go about it, but for sure I make mistakes. However your comments about writing spec tests was interesting to me.

Honestly I don’t even write tests manually because of coverage checks. Being that the coverage check is not something easily manipulated, I always tell the ai, don’t ever change configs, and make the coverage pass whatever I set it to, most times > 95%. I just tell the AI, make this coverage pass.

I find tremendous success with this technique, or anytime really I can find an objective way for the ai to test its work.

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

#208

Post by hombre_fatal »

geraneum wrote: post #73
hombre_fatal wrote: post #26

Yeah, this has been my process for months now. I might even start my own blog to write about things I've found. 1. Always get the agent to create a plan file (spec). Whatever prompt you were going to yolo into the agent, do it in Plan Mode first so it creates a plan file. 2. Get agents to iterate on the plan file until it's complete and thorough. You want some sort of "/review-plan " skill. You extend it over time so…

> PRs should be plan files, not code. Impl is trivial. Doesn’t it bother you that the outcome each PR is different every time you/CI “run it”?

No, because consider the pre-AI status quo where a human PR will come in like "Added tab support", maybe scribbles out some guiding ideas, maybe references some issue where we kinda hashed out some ideas of how it could work, and then we must derive all of the intentions/assumptions/decisions of the implementor from the PR's code changes.

Basically zero plan. Or rather, the "internal" plan that the human implementor used while writing the code is hidden from us because it's a mix of ideas they held in their head, jotted in some notes, existed in a sequence of commits that were lost when squashed into a PR, etc. There's zero reproducibility in the implementation.

So take my idea and pretend we still don't have AI yet: the main point is that we move to a pipeline where we work on a first-class plan first before we begin implementation. This gets us closer to reproducible implementation no matter who is implementing it.

It just so happens that now with implementation becoming automated, we have more attention and energy freed up to focus on this plan-based model.

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

#209

Post by insanitybit »

rspeele wrote: post #122
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…

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…

I found this sort of odd. What is your point? Is it good or bad that another team was responsible in one scenario?

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

#210

Post by insanitybit »

camgunz wrote: post #176
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…

No, because those direct reports can use tools to build deterministic software. LLMs can't, because they themselves are non-deterministic. They will say they did, and they will be wrong. And the LLM you have check will also say it did, and it will be wrong. Etc etc. These things just can't be in the critical path. They are ridiculously unreliable.

What? Software being deterministic is not a feature of who wrote it. And how the hell is a human "deterministic"?
Post reply on HN