Retaining Authorship for Critical Code: An Agentic Buddy System for Review and QA | Smorsic Labs

Skip to main content<br>AI does help me write code, but when I'm writing for you here, I only write my own words, not even using autofill. I would rather lose some time than lose your trust. - Scott

Something that's always been true about software is that every project has different needs.

A lot of debate about how we should be engineering suffers from the fundamentally flawed idea<br>that we can write one set of rules and practices that perfectly apply to all software projects:

"If you don't have strong test coverage, your project will suffer" vs.

"Tests are a waste of time and have only caused my teams more pain"

Lately: "If you don't review your agent's code yourself, your your project will rot" vs.

"Agents are so good at writing and reviewing code now, you shouldn't waste time on it"

The quality of agent-generated code has risen and likely will continue to rise, which is<br>not a surprise. With this, the review debate is getting louder and more contentious.

To me, this is still a question of code criticality , and the idea that the importance of quality code review<br>depends on the project isn't really a new one, so once again, we just have an old problem in a new form.

I develop pacwich, supply chain open source that runs in DevOps processes,<br>handles arbitrary shell scripts, etc., which I argue is closer to the astronaut end of<br>the criticality spectrum above, meaning that in my opinion, my detailed code review and manual<br>polish is indeed critical .

I've found that both of these statements are true:

I catch code and design issues that agents don't

Agents catch code and design issues that I don't

Therefore, a balance I've been trying to achieve is how to maximize agent assistance while retaining my authorship<br>and personal touch in the code.

I've begun mirroring the idea in aviation of a buddy system , where two pilots both perform<br>safety checks and cross-review each other's controls. Mainly using skills, I have adopted<br>a workflow where agents both perform QA and code review and support my manual QA and review<br>via clear, strict rules on how they should operate.

Code Review​

Before jumping into the buddy system, I want to detail my reasons for code review and what<br>I do to set it up for success, since my reasoning is not just that it's "something you're supposed to do."

You can jump forward to the meat and potatoes instead, if you<br>already get this.

The Value of A Consistent Codebase​

Having well-established precedents in a critical project is important to me, and this fundamental aspect of<br>a project helps maximize the buddy system's effectiveness.

pacwich's style​

I developed an opinionated coding style over many years of writing TypeScript by hand in my career.

pacwich's code inherits that style, largely due to the fact that I wrote its predecessor package bun-workspaces<br>almost entirely manually, though I'll detail how I maintain this later.

Over many of my refactoring passes and feature additions, the codebase accumulated enough patterns to<br>make it relatively clear to either people or agents how changes should look in the codebase.

Benefits of Predictability​

The predictability of the code streamlines several key tasks: My ability to make consistent changes, an agent's<br>ability to make consistent changes, my ability to review changes, and an agent's ability to review changes.

The main point is that a clean, consistent project makes both authorship and review easier, regardless<br>of whether it's a person or an agent performing it .

It simplifies decision making and makes comprehension easier, and I believe that I am needed to guard and<br>maintain this, since without an opinion set by the true leader of a project, agents or other maintainers<br>will run with their defaults.

Relevant "Traditional" Preferences​

The aspects of a project's style include syntax preferences, naming preferences, and so on.

Someone who argues that these are no longer necessary to care about are effectively arguing that human review is<br>unnecessary, whether they intend to or not, since these affect readability.

So, I'll reiterate that critical code requires my review , so of course I'm still going to care about "old fashioned" things like syntax and<br>naming that directly affect my ability to review.

Agents' Imperfect Code Affects Myself and Future Agents​

Even if the actual behavior of generated code is fine, agents can't read my mind, so oftentimes the names they choose in<br>the code aren't intuitive to me, so I end up changing the names myself to maintain consistency and reviewability.

Despite my instructions, I also often end up heavily editing comments that are often superfluous in many regards, such as talking about a change<br>I asked for in a chat during ephemeral iterations that isn't relevant to any existing code or releases, duplicated verbose descriptions of entire flows<br>above every related function, or...