Smaller and simpler feedback loops

One thing that’s definitely changed in how I work over the past year—as I’ve used coding agentsToday, a mix between Claude and AMP. more and more—is how I optimize for small, simple feedback loops. At first, it was about having more tests (in particular unit tests) to validate that something works as expected. But now, these feedback loops benefit not just the agent but me as well.

One example is writing React components. In the past, I would write some unit tests and Storybook stories to validate the UX. That part hasn’t changed much. But now, in addition to the stories, I also write interaction tests using Storybook’s built-in interaction testing. This serves a dual purpose:

• Agents no longer have to use the Playwright MCP to see and test the component, which means less tool output added to the context.
• We get faster feedback on whether the component behaves as expected.

Another example is debugging remote systems: a couple of years ago, this was tedious if I didn’t know where to look. I’d start by searching the symptoms online, then inevitably copy-paste commands from Stack Overflow and hope they’d work. Now, I still do some research online so I know where to point the agent. Then, I set up a tmux session with the agent running on one pane and SSH to the remote system on another pane. I then instruct the agent to read from and write to this pane for the investigation. In most cases, depending on the system, I also instruct the agent to not actually run the command so I can inspect itThis was not always effective in the past, but agents are getting better with these kinds of instructions. .

Let the agent see if it worked. It’ll iterate instead of guessing, and you won’t be stuck figuring out which of the twelve things it tried is the one that broke.