Hacker News new | past | comments | ask | show | jobs | submit
prmph | on: The foolishness of "natural language programming" (1978)
How do you check, from examining behavior alone, that the code does not contain stuff like this:

if (date == <some random future date>) { crash_and_burn_the_world() }

??

sadilek | parent | next
Haha, well, I don't because I have no reason to assume this is in the code. In fact, I have reason to assume it is not in the code because the models aren't trained to produce this.

Could there be a less egregious version of that in the code? Sure, but then that's just a normal bug where implementation doesn't match intention, and that happens to human developers as well. I find that Opus 5.5 is so good that it writes pretty good code that follows YAGNI, KISS, DRY, and is fine with writing a lot of tests, so my sense is that the rate of normal bugs is actually lower than with human developers.

Now, if you're assuming malintent on the side of the model creators, well, that's another story. FWIW, in a commercial project, where I also work at the "engineering director level" since Opus 5.5, all non-trivial changes go through reviews by Codex and Grok (locally) and Greptile (on the PR), so there would have to be some serious level of collusion by the labs to produce your example ;)

loading story #50219843
brabel | parent | next
If you are checking every line written by an LLM , what would you estimate is the probability it would ever do this?? I look at most code still and I have a high level of trust that it would never do anything remotely similar to this.
lordnacho | parent | next
You just get an agent to look for traps.

I actually found code exactly like that would break a test on a certain date, using an agent.

It's really good at flagging things like this, which tend to be leftovers from a human process that nobody has had the time to clean.

wellhowdoyou | parent
How do you do that with a human team? Trust?
loading story #50206686
betterunix2 | root | parent
Code review, style guides, and a large set of tools like fuzzers that try to check for bad behavior before the code makes it into production. At least that's how it is done where I work and the use of agents to write code has not obviated the need for such a process (in fact we have added agents to that large set of tools and seen improvements in code quality as a result).