I was feeling time pressure and rushing to troubleshoot with my coding agent yesterday and did many of the things that my deliberate practice tries to avoid. I didn’t make it:

• Recreate the bug in a test, or
• Analyze the codebase for related implementations, or
• Task out its plan, or
• Stop frequently for atomic commits.

So, it partially fixed the problem (yay!), then it obfuscated the work by “fixing” things that weren’t broken (boo) and then, for dessert, it applied breaking “fixes” on top of what it had done (sadness).

I started over.

After a day or two of adapting to the difference, I am finding good success with the new claude sonnet 3.7 reasoning model for complex troubleshooting. It does a better job of replicating my priorities in subsequent responses like incremental change validated through tests.

It is less predictable and can do really strange veering turns. Review changes carefully, Commit frequently and be ready to revert in case you miss something like renaming of variables, inserting test code into production code, or other random nonsense. That’s actually an indicator that the work your doing is directed enough that you should move back to the non-reasoning model.

This is exactly what I’m experiencing.

Agentic approaches might be powerful but they shouldn’t be thought of as a replacement for skilled problem specific engineering.

Think of it in terms of return on processing time. Invest in design time up front to avoid orders magnitude more processing expense at runtime

For many - if not all - reasons.