The Agent That Reviews Its Own Code

<p>Nova — my personal AI multi-agent system — just crossed into what I'd call the production orchestration phase. It's not a demo anymore. There are 34 agents running across general chat, pipeline execution, ERP specialists, and language tooling, and they're doing real work day to day. That's a nice milestone, but it's not the thing I'm most interested in right now. The thing I'm chewing on is the next goal on my list: building a self-improvement loop.</p><p>The idea is straightforward to say and much harder to do well. I want agents that can review, refactor, and improve Nova's own code. Not in a hand-wavy "AI writes AI" way — I mean a concrete, bounded loop: an agent reads a module, evaluates it against a standard, proposes a change, and that change goes through the same review any of my own commits would. The system improving the system. If it works, the leverage compounds. Every improvement to how Nova reasons about code makes the next improvement cheaper.</p><p>Here's why this feels different from just using an AI coding assistant. My whole thesis for the past while has been that AI is the primary leverage point in software engineering — not a tool you reach for occasionally, but the core competency you build around. A coding assistant helps me write a function faster. A self-improvement loop changes the shape of the work. Instead of me being the bottleneck on every refactor, I become the person who sets the standards and reviews the diffs. That's a genuinely different job, and I think it's the right one to be moving toward.</p><p>But I'm being deliberately careful about the boundaries, because this is exactly the kind of thing that goes wrong quietly. A few rules I've set for myself:</p><p>First, no agent gets to merge its own work. Every proposed change is a pull request, reviewed by me or by a separate reviewing agent whose only job is to be skeptical. The generator and the critic are never the same process. If you let the thing that writes the code also decide the code is good, you've just built a very expensive way to talk yourself into bad decisions.</p><p>Second, changes have to be small and reversible. I'd rather have a hundred tiny, boring refactors I can read in thirty seconds than one sweeping rewrite that's technically impressive and impossible to audit. The whole value of the loop is that I can trust it, and trust comes from being able to see what changed and why.</p><p>Third, the loop earns scope. It starts with the safe, mechanical stuff — dead code, inconsistent patterns, missing type hints, tests that should exist and don't. Only once it's proven itself on the boring work does it get anywhere near logic that actually matters. I'm not handing an agent the orchestration layer on day one.</p><p>The honest part I'll admit: I don't know yet how much of this pans out. There's a real risk that the review overhead eats the gains, that I spend more time babysitting proposed changes than I'd have spent making them myself. That's fine. If it turns out the loop only works for the mechanical 20%, that's still 20% of maintenance work I don't have to think about, and I'll have learned exactly where the line sits between what AI can own and what still needs a human. Either outcome teaches me something I can carry into AIREP and the other projects, where the same question — how much can the system safely improve itself — is going to come up again and again.</p><p>What I like about doing this on Nova first is that Nova is mine. If a self-improving agent makes a mess, it makes a mess in my own house, not a client's. That's the right place to run the experiment. Build it where you can afford to be wrong, learn where the edges are, then bring the parts that actually work to the systems where it counts.</p><p>I'll report back once there's a real diff to show — good or bad.</p>