I had Sonnet volunteer some tests last year, which really impressed me at the time. It was just a couple console.log statements that printed green checkmarks and "tests passed!"

I'm working on a multiplayer game, and realized I could scale a server further by letting clients handle collisions, and then just verifying those (instead of the server checking all collisions for all games taking place on the server).

The point was that if your bullet hits someone, you would report it to the server, and then the server would check if you got the hit or not. (So you couldn't just send fake hit reports.) So the game would still be fair and CPU usage would be greatly reduced.

The way the agent implemented it was the other way around. It had players send reports when they had been hit. So they could simply not send them and make themselves invincible. Also the game still checked collisions anyway making the whole feature pointless (on top of broken).

(Actually it made the game slower than it was originally!)

Hope that clears things up.

--

An AI agent actually pointed out the absurdity of the new code to me. So I'm assuming it wasn't that one which wrote it. Probably one of the smaller ones I was testing. But unfortunately I didn't get them to sign their names so I'll never know!

I think he means it was very wrong.

In test-driven development, you're supposed to write out the tests first to specify the desired behavior, then write the code to confirm to that.

First of all the necessary context: this was a hobby project, and I am not a professional software engineer.

In this particular instance I'm not sure what happened. I don't know where it got the idea from to do it backwards.

My best guess is that the to-do items were too vague. I built up a lot of context in my head from back and forth with the agents, and so my mental model was pretty solid, but probably an insufficient amount of that was encoded in the repo itself.

I'm not sure what you mean by reviewing the plan — do you mean making a detailed implementation plan before beginning the work?

Most of the changes were pretty straightforward, or at least we'd already worked out most of the details and put them into to-dos. So for the most part my prompt was just "alright go ahead and implement the next thing on the list."

If I had to guess I'd say the main reason it went wrong was because the why was missing. The to-do item specified what work remained to be done, but it did not explain the reason for each item. I think that was the core of the issue.

So it probably ended up seeing a bunch of individual changes out of context and not understanding what the point was supposed to be.

---

>did you run any of it across models from different foundation labs?

Working on a different part of the same repo a week later, I used Fable and Sol to find issues. Then I let them run cross critique on each other's reports. Then I had each of them generate a plan, and then I had them do cross critique on the plans. And then I repeated that until they were both satisfied with the results, i.e. until the two plans merged into one coherent plan.

It was interesting because they're both had different strengths and weaknesses in different parts of the process. (One of them sound more issues in the initial phase, but the other came up with a more comprehensive fix for each one.)

I've seen very promising results for model alloys with security research (it was posted here about a year ago[0]), so I wanted to give it a try myself.

There doesn't seem to be a very convenient way to do it (maybe one of the new harnesses which runs the proprietary harnesses as subprocesses?), so I just passed markdown files between the two models manually.

[0] - https://news.ycombinator.com/item?id=44630724