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

Verification debt: the hidden cost of AI-generated code

fazy.medium.com

Post reply on HN
Print view View original

61–70 of 103 posts

Re: Verification debt: the hidden cost of AI-generated code

#61

Post by gspr »

fishtoaster wrote: post #17

Figuring out how to trust AI-written code faster is the project of software engineering for the next few years, IMO. We'll need to figure out the techniques and strategies that let us merge AI code sight unseen. Some ideas that have already started floating around: - Include the spec for the change in your PR and only bother reviewing that , on the assumption that the AI faithfully executed it - Lean harder on your d…

> We'll need to figure out the techniques and strategies that let us merge AI code sight unseen.

Why do you assume that's doable? I'm not saying it's not, but it seems strange to just take for granted that it is.

Re: Verification debt: the hidden cost of AI-generated code

#63

Post by cuntiusmccunt »

bensyverson wrote: post #25

It comes down to trust. I was not able to trust GPT 4.1 or Sonnet 3.5 with anything other than short, well-specified tasks. If I let them go too long (e.g. in long Cursor sessions), it would lose the plot and start thrashing. With better models and harnesses (e.g. Claude Code), I can now trust the AI more than I would trust a junior developer in the past. I still review Claude's plans before it begins, and I try out…

good moooorning sir

Re: Verification debt: the hidden cost of AI-generated code

#66

Post by mentalgear »

gopalv wrote: post #57
fishtoaster wrote: post #17

Figuring out how to trust AI-written code faster is the project of software engineering for the next few years, IMO. We'll need to figure out the techniques and strategies that let us merge AI code sight unseen. Some ideas that have already started floating around: - Include the spec for the change in your PR and only bother reviewing that , on the assumption that the AI faithfully executed it - Lean harder on your d…

> We'll need to figure out the techniques and strategies that let us merge AI code sight unseen Every strategy which worked with an off-shore team in India works well for AI. Sometime in mid 2017, I found myself running out of hours in the day stopping code from being merged. On one hand, I needed to stamp the PRs because I was an ASF PMC member and not a lot of the folks who were opening JIRAs were & this wasn't a t…

> Every strategy which worked with an off-shore team in India works well for AI.

Why hasn't SWE then not been completely outsourced for 20 years. Corporations were certainly trying hard.

Re: Verification debt: the hidden cost of AI-generated code

#67

Post by halfcat »

logicchains wrote: post #45
sarchertech wrote: post #34

Earlier quoted context omitted.

Translating from a natural language spec to code involves a truly massive amount of decision making. For a non trivial program, 2 implementations of the same natural language spec will have thousands of observable differences. Where we are today, that is agents require guardrails to keep from spinning out, there is no way to let agents work on code autonomously that won’t end up with all of those observable differenc…

>For a non trivial program, 2 implementations of the same natural language spec will have thousands of observable differences. If they're not defined in the spec then these differences shouldn't matter, they're just implementation details. And if they do matter, then they should be included in the spec; a natural language spec that doesn't specify some things that should be specified is not a good spec.

> we just need to make the spec perfect

So, never.

Greg Kroah-Hartman was once asked by his boss, ”when will Linux be done?” and he said, ”when people stop making new hardware”, that even today, when we assume the hardware won’t lie, much of the work in maintaining Linux is around hardware bugs.

So even at the lowest levels of software development, you can’t know the bugs you’re going to have until you partially solve the problem and find out that this combination of hardware and drivers produces an error, and you only find that out because someone with that combination tried it. There is no way to prevent that by “make better spec”.

But that’s always been true. Basically it’s the 3-body-problem. On the spectrum of simple-complicated-complex, you can calculate the future state of a system if it’s simple, or “only complicated” (sometimes), but you literally cannot know the future state of complex systems without simulating them, running each step and finding out.

And it gets worse. Software ranges from simple to complicated to complex. But it exists within a complex hardware environment, and also within a complex business environment where people change and interest rates change and motives change from month to month.

There is no “correct spec”.

Re: Verification debt: the hidden cost of AI-generated code

#68

Post by talkvoix »

With a CS degree and 15 years of software engineering under my belt, I was initially skeptical of 'vibe coding'. But the article is right about this adolescent phase. I recently built my platform (https://voix.chat) 100% through agentic workflows. Having that much experience meant I didn't use the AI as a crutch to learn how to code; I used it as a hyper-productive junior dev while I played the paranoid senior architect. It allowed me to focus purely on the hard stuff: strict anti-flood mechanisms, brute-force protection, and overall server hardening. The AI handles the syntax; the human handles the paranoia.

Re: Verification debt: the hidden cost of AI-generated code

#69

Post by fishtoaster »

gspr wrote: post #61
fishtoaster wrote: post #17

Figuring out how to trust AI-written code faster is the project of software engineering for the next few years, IMO. We'll need to figure out the techniques and strategies that let us merge AI code sight unseen. Some ideas that have already started floating around: - Include the spec for the change in your PR and only bother reviewing that , on the assumption that the AI faithfully executed it - Lean harder on your d…

> We'll need to figure out the techniques and strategies that let us merge AI code sight unseen. Why do you assume that's doable? I'm not saying it's not, but it seems strange to just take for granted that it is.

Why do you assume I assume it's doable? :P

For real, I'm not certain we will ever be able to merge AI code without human review. But:

1. Every time I've confidently though "AI will never be able to do X" in the last year, I've later been proven wrong, so I'm a bit wary to assume that again without strong reasons.

2. I see blog posts by some of the most AI-forward people that seems to imply some people are already managing large codebases without human review of raw code. Maybe they're full of crap - there are certainly plenty of over-credulous bs artists in the AI space - but maybe they're not.

3. The returns on figuring this out are so incredibly high that, if it's possible, people will figure it out.

All that to say: it's far from certain, but my bias is that it is possible.

Post reply on HN