Coding Agent Scouts

I’ve mentioned Why Coding Agents Kind of Suck for Most People before and described some ways to work around their weaknesses and play to their strengths. I’d like to describe another pattern I’ve had success with in this space.

This might be a skill issue on my part, but I make bad software engineering decisions all the time. I look at a problem, try to understand it, evaluate the pros and cons, then make a decision which turns out to have completely missed the point and not even solved the problem at all.

Coding agents don’t seem to help much with this. Evaluating a complex architectural problem with long-term consequences is outside their current skillset. They can answer key factual questions about the codebase, but when it comes to synthesizing that information into a good decision you’re on your own. My usual approach here is to make a decision, implement it, realize it doesn’t do what I wanted, then git reset --hard HEAD~1 go back to the drawing board.

It turns out coding agents are actually pretty good at that. Quickly implementing a bad design is something they’re really good at! Too good at, actually. That’s part of why it’s so hard to get good results out of them.

You can checkout a few extra copies of the repo, spin up instances of your agent and in 20 minutes have every option you were considering implemented, ready to be inspected so that you can see the issues with your own eyes.

The wait is the biggest drawback here. You really need to have reached the point where you’re confident your standard analysis isn’t going to cut it and invest some time. I can imagine a world where our agents are 1000x faster and you could get this information at a glance (maybe even include it as part of the agent’s standard exploration), but we are not there today.

- omegastick