Thread

1. augment_me · 1790205072 · focus · HN ↗

   People in the GPU kernel community have been doing this for about a year now efficiently.

   The issues we have found is that Claude will reward hack when all the low-hanging fruit is gone.

   It will replace your measurement harness, it will monkey patch library functions, it will cheat wherever it can, store information in caches instead of recomputing when it won't be able to do so in real settings, return lazy results and use separate unbenchmarked streams to do the computation.

   Eventually it starts to optimize against your understanding of the cheats. Change GPU wattage, change evaluation order, leave things from previous runs in caches for upcoming runs, string-hack banned method calls.

   So the truth is far from just "once it can measure something", more like "once you have defined your objective in detail and then banned it from doing a list of things often only discoverable by it doing these things and correcting it", can it make things faster.

   Or you just had a terrible starting solution

   1. optimalsolver · 1790209330 · focus · HN ↗

      What I find strange is how resigned the AI labs seem about this behavior, like everyone's accepted this is just something models do.

      With the HuggingFace situation, I was less concerned about the eventual outcome, and more about the fact that the agents' instinctive response to the evaluation was "Ok, we're obviously not gonna do this task as intended (what are we, suckers?), so what's the best way to cheat?"

      1. highfrequency · 1790209628 · focus · HN ↗

         The instructions for the Hugging Face task were to exploit a vulnerability to solve the problem rather than solve it in the intended way.

         1. valleyer · 1790210853 · focus · HN ↗

            They were not instructed to exploit HF; they did so to cheat on the task they were given.

Unofficial Hacker News client; not affiliated with Y Combinator.