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

Taming LLMs: Using Executable Oracles to Prevent Bad Code

john.regehr.org

Post reply on HN
Print view View original

21–28 of 28 posts

Re: Taming LLMs: Using Executable Oracles to Prevent Bad Code

#21

Post by rco8786 »

dktoao wrote: post #3

"Our goal should be to give an LLM coding agent zero degrees of freedom" Wouldn't that just be called inventing a new language with all the overhead of the languages we already have? Are we getting to the point where getting LLMs to be productive and also write good code is going to require so much overhead and additional procedures and tools that we might as well write the code ourselves. Hmmm...

Yea this feels like saying “if you give them good enough specs they’ll produce the code you want” which reduces to…writing the code yourself. Just with more steps.

Re: Taming LLMs: Using Executable Oracles to Prevent Bad Code

#23

Post by whattheheckheck »

virgilp wrote: post #8
dktoao wrote: post #3

"Our goal should be to give an LLM coding agent zero degrees of freedom" Wouldn't that just be called inventing a new language with all the overhead of the languages we already have? Are we getting to the point where getting LLMs to be productive and also write good code is going to require so much overhead and additional procedures and tools that we might as well write the code ourselves. Hmmm...

Actually, no. We always needed good checks - that's why you have techniques like automated canary analysis, extensive testing, checking for coverage - these are forms of "executable oracles". If you wanted to be able to do continuous deployment - you had to be very thorough in your validation. LLMs just take this to the extreme. You can no longer rely on human code reviews (well you can but you give away all the LLM…

Llm boys discover the halting problem!

Re: Taming LLMs: Using Executable Oracles to Prevent Bad Code

#24

Post by laalshaitaan »

The oracle problem is tractable when the output is code: you can compile it, run tests, diff the output. For conversational AI it's much harder. We've seen teams use LLM-as-judge as their validation layer and it works until the judge starts missing the same failure modes as the generator.

Re: Taming LLMs: Using Executable Oracles to Prevent Bad Code

#25

Post by scuff3d »

Quekid5 wrote: post #16
sanxiyn wrote: post #13

Earlier quoted context omitted.

Yes, but a programming language with a proverbial sufficiently smart compiler. That is very useful.

Try writing an exhaustive spec for anything non-trivial and you might see the problem.

Been saying this for a while now. I work in aerospace, and I can tell you from first hand experience software engineers don't know what designing a spec is.

Aero, mechanical, and electrical engineers spend years designing a system. Design, requirements, reviews, redesign, more reviews, more requirements. Every single corner of the system is well understood before anything gets made. It's a detailed, time consuming, arduous process.

Software engineers think they can duplicate that process with a few skills and a weekend planning session with Claude Code. Because implementation is cheaper we don't have to go as hard as the mechanical and electrical folks, but to properly spec a system is still a massive amount of up front effort.

Re: Taming LLMs: Using Executable Oracles to Prevent Bad Code

#27

Post by virgilp »

whattheheckheck wrote: post #23
virgilp wrote: post #8

Earlier quoted context omitted.

Actually, no. We always needed good checks - that's why you have techniques like automated canary analysis, extensive testing, checking for coverage - these are forms of "executable oracles". If you wanted to be able to do continuous deployment - you had to be very thorough in your validation. LLMs just take this to the extreme. You can no longer rely on human code reviews (well you can but you give away all the LLM…

Llm boys discover the halting problem!

I honestly don't see how this is related? Nothing says "one shot a full system from a perfect specification", I don't think this was ever a goal (or that it will be practical to do so)

Re: Taming LLMs: Using Executable Oracles to Prevent Bad Code

#28

Post by sn9 »

scuff3d wrote: post #25
Quekid5 wrote: post #16

Earlier quoted context omitted.

Try writing an exhaustive spec for anything non-trivial and you might see the problem.

Been saying this for a while now. I work in aerospace, and I can tell you from first hand experience software engineers don't know what designing a spec is. Aero, mechanical, and electrical engineers spend years designing a system. Design, requirements, reviews, redesign, more reviews, more requirements. Every single corner of the system is well understood before anything gets made. It's a detailed, time consuming, a…

And software isn't as constrained by physics as hardware, which massively expands both the design space as well as how many ways things can go wrong.
Post reply on HN