Shrinking Feedback Loops

I’ve been working on codifying my knowledge of software development into a multi-agent “Dev Team” plugin since March 2, 2026. Over 1250 commits later, I have a tool that’s been effective at finding defects, automating test improvements in legacy code, enabling framework migrations, driving stack modernization, and executing “/ship this new idea I have.” How I built it is, I think, a reasonable approach to agentic development. Getting here, however, required a fundamental shift in how I approached the work.

In December, a co-worker’s friend gave us a demo of his “agentic scrum team.” It was eye-opening. He talked about the disciplined approach to context management and model selection codified in the plugin, the strict “spec, build, review” workflow, and how work was divided among persona-based agents. We, of course, recorded it to learn from it, and I had a transcript.

“Claude, review the transcript about the agentic scrum team and generate a reference architecture in MermaidJS.”

A few minutes later, I had a diagram to wrap my head around it. I wondered how I could build one myself, but with other work priorities, I left it for a bit.

Physician, heal thyself

By March 2, I did what I’ve been doing for the last two years of working with AI: I asked, “I wonder what will happen if I try this?”

“Claude, review the transcript and the reference architecture and propose a plan to build it.”

A few minutes later, I had a plan that looked reasonable, so… “Build it!” And it did.

Then I started dogfooding it: finding errors, telling it what it did wrong, telling it to fix itself, and trying again with the new version. I kept seeing things other people were doing that seemed like good ideas, so I created the /competitive-analysis skill. This allowed the plugin to compare itself to other plugins, blog posts, white papers, and even Anthropic’s documentation. It would generate a report showing what we were doing better or worse than the examples. I’d tell it to open issues for the ideas I liked, then have it design changes for itself to incorporate them.

This is exactly how you build a CD pipeline: you add in all the good practices you can think of or learn about later, and if a defect makes it through, you find a way to prevent that entire class of defect. As I applied this process to the plugin, I kept finding ways to reduce the toil of finding and reporting problems to fix.

How I Work Now: 970 GitHub Issues Later

“Claude, /ship this change. If you find a problem that you need to overcome, skills that don’t work as described, or rework loops you are doing, open a defect on GitHub.”

Then I watch as it opens a stream of pull requests on the work it’s doing and reports any friction defects in its own repo. I throw hobby code out into the wild, explain I’ve never looked at the code, and challenge reviewers: “Prove to me it’s garbage.” People code-review it and find some objectively bad things (or show they review for personal preference). I feed those review comments back into my plugin, and it immediately delivers better results in the next iteration.

Here’s a simple example:

And just like that, Claude has a new hole to plug.

Welcome to being a technical product manager

The job has never been about coding. It’s been about solving real problems that real people have, no matter how important or trivial. The only time it’s been about coding was during classwork or coding competitions. That’s a hobby, not a profession. Too many developers have their worth tied to the code they write, and that’s always been wrong. Ego should be tied to the outcomes we produce, not the typing. The problem is that when your focus is on the code, you solve the wrong problems and end up using agents as junior developers that you micro-manage.

I took a different path. “How can I be hands-off and get results at least as good as I can deliver by myself?” I built a team that challenges one another at every step to do the right thing, rather than taking the shortest path to “done.” The team tells on itself and self-improves. I tell it to use defect libraries to test the code review workflow. I tell it to use information from Anthropic’s blog to build skill and agent evaluations to test that they don’t regress.

The plugin contains my opinions on how to do things well and documents every industry best practice I can find. In all of that time, I’ve never touched a line of code. I set product goals, provide resources, and give feedback, and I focus on getting my actual work done by using the improved plugin rather than getting bogged down in the meta-work of solving the problems required to solve the problems people care about. That’s the job.