| ▲ | peterbell_nyc a day ago | |
Wait, did you let the same agent write the tests that wrote the implementation? Or was it that the plan was the wrong way round, and both the generator of code and the generator of the tests followed that same incorrect plan? Also, what were your mechanisms for reviewing the plan against the described business outcome? Anything else you could have done there to catch the backwardness? And finally, did you run any of it across models from different foundation labs? I'll often run important stuff generated by codex across Anthropic, grok, and Gemini with an opus or fable judge... | ||
| ▲ | andai 13 hours ago | parent [-] | |
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. | ||