Lessons from coding with agents pt.1

After a few long sessions spent going back and forth with Cursor and Sonet I have a few notes to make.

Always have rule files

The different coding agents have their own rule files. Cursor has them, Aider has them, Claude code has one.

Make sure to always have a good set of files in the project. If not sure, ask a good model to generate a set.

These are worth refining and extracting for reuse.

Give the thinking model the right tasks

Sonnet 3.7 to do basic code changes is asking for trouble.

At the same time asking Sonnet 3.5 to create the plan for improving a codebase is also not theright move.

The thinking models are good for open ended large in scope changes.

Have change you have a vague idea about, not quite sure, but are happy with some random refactors - 3.7 is good.

You need a full on detailed plan how to improve a codebase - 3.7 is the one.

You want someone to follow up on said plan and implement just those changes? 3.7 is not the one. That's a job for 3.5. Not to mention 3.7 can get expensive fast.

Use multiple models

Sometimes it's easy to tunnel vision one one tool, especially with Cursor and the way you can get into a flow.

Some models are much better problem solvers than others. Asking 01, 03-mini, R1, Grok 3 or Perplexity R1 on more broad problem solving questions can give much better direciton. Going into Sonnet 3.7 for refinement and tasking out and then implementation with 3.5.

Don't be afraid of YOLO mode

Letting do Agent do it's thing is part of the charm.

It ofcourse, needs it's own skill to do well.

Asking it to run build or test commands to double check it's work. That's a good one. Makes the loop much better and allows you to observe, think and strategise about next steps.

Due to the way LLMs predict though, inevitably the small ask to refactor logger statements ends up wiping out core logic. These things happen, as they do.

It's important to catch the agents when they start going rogue, stop them and see if the situation is salvageable. Sometimes a hard git reset and starting from scartch is needed. Good commit hygiene is naturally a must here. Given we are letting the agents loose, we need good save points long the way.

Which brings me to the next point ...

Have good guard rails

Automation, automation, automation!

Tests, lints, formatters, builds - add as many checks as you can. Make them easy to run, run them locally, run them all the tiem. Run them on pre-commit and run the m on the pipeilne.

Given the context of the task ask the agent to run the right checks in the loop.

Thank me later.

Write more tests than you think

Given the situation here, adding more tests is a no brainer. Especially when we can have them help us with maintaining sanity when the inevitable "casual refactor" happens.

Get the reps in

As weird as it sounds, working with the models you end up starting to develop a feel for the workflow. By the looks of it, this skill might scale like any other skill.

Use the tech, get familiar with the tech, get comfortable with the tech.

But don't stop thinking. We're adapting here, not shutting our brain off.

Adaptatin is the name of the game.

Double the agents

Runnig more than one agent at a time has potential. I've not explored it much, yet.

It will get better as agents get better, for now given how much babysitting they require there is a limit to scaling them. At least with the setup we have now.