Retaining Authorship for Critical Code: An Agentic Buddy System

Developer Brian LeRoux advocates for a 'buddy system' in which human authors and AI agents cross-review each other's code for critical projects, arguing that both catch issues the other misses. Writing about his open-source supply chain tool pacwich, LeRoux says detailed manual review and polish remain essential for high-criticality code, even as agent-generated code quality improves. He emphasizes that a consistent, opinionated codebase streamlines both human and agent review.

Retaining Authorship for Critical Code: An Agentic Buddy System for Review and QA 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 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 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 depends on the project isn't really a new one, so once again, we just have an old problem in a new form /blog/typewriters-to-tokens . I develop pacwich https://pacwich.dev , supply chain open source that runs in DevOps processes, handles arbitrary shell scripts, etc., which I argue is closer to the astronaut end of the criticality spectrum above, meaning that in my opinion, my detailed code review and manual 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 and personal touch in the code. I've begun mirroring the idea in aviation of a buddy system , where two pilots both perform safety checks and cross-review each other's controls. Mainly using skills, I have adopted a workflow where agents both perform QA and code review and support my manual QA and review 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 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 the-buddy-system-for-review to the meat and potatoes instead, if you 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 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 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 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 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 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 maintain this, since without an opinion set by the true leader of a project, agents or other maintainers 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 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 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 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 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 above every related function, or similar. Leaving comments like these in the code means leaving myeslf a nightmare of untrustworthy essays embedded into the code. I also notice models that write these comments will often verify real code or behavior anyway and often catch drift, meaning the comments truly are either dangerous to trust or are only dead weight for token usage or my brain . Maybe this gets better, but with each improvement, I still haven't lost the gut feeling that I need to watch and steer critical code. Some people operate on the assumption that things will be perfect later and then further irrationally operate as if that perfection is already here. If someone told me that next year we'll have teleportation technology, I'm not going to sell my car today. I work with what is true today, not what might be true later. The Buddy System for Review The simple idea here is that I utilize both agent review and my own manual review of code changes. What makes this special, however, is that I'm also enhancing my manual review with an agent. Agent Review This is a well-known pattern at this point that I won't waste too much time explaining. Agents are powerful at code review, and it's often effective to use a different agent to review the code generated by another agent. Whether it's a sanity check on code I've written or on the code another agent's written, this is at least a fairly simple task. It's straightforward to ask an agent to review some code or to set up a means of having an agent review a GitHub Pull Request, and of course you can refine this via a prompt or capture preferences in a skill. Manual Review, Assisted by an Agent I have lately felt the truth of the statement "Code review is now the bottleneck." If a bottleneck is necessary, I'm not going to pretend I can just ignore it. My background in music taught me that some things are just a pain in the ass if you want quality. If I skip a true review where I digest and polish agent-generated code to bring it up to my standards, I start to lose the benefits I described earlier, not to mention the seemingly obvious notion that supply chain open source shouldn't be developed blindly. However, I realized that just because I'm performing manual review doesn't mean I can't have help from an agent to make it less painful. A Support Skill I created a skill in pacwich https://github.com/smorsic/pacwich/tree/main/.agents/skills simply called review-assist that instructs an agent how to guide me through a review of some changes. The idea is that here the agent isn't performing the critical review but instead helping give me a framework for approaching my review.It helps me with some of the things that are more painful to figure out from scratch, such as the flow of the changed code, giving me a thread to follow through function calls and the like. I go through all changed files myself, but I don't have to waste as much time trying to sort out the flow. Retaining Authority You could say this is no longer a pure manual review, since maybe I will be led astray by the agent, but I'd say my expertise and desire to retain authority of my project helps balance against this light impurity here. I am going to sanity check with git as a real source of truth of what all has changed, and my own TypeScript expertise will catch if the described flow isn't quite right, and my own existing knowledge of the codebase that I value and maintain guides me greatly. After all, I already spent years performing code reviews before AI. But, having that bit of help in knowing where to begin with suggestions of what to look at greatly enhances the process, and it gives a good springboard to challenge the agent on its descriptions or the choices made in the code. The Buddy System for QA For pacwich , QA is simply using the production features of the CLI or TypeScript API by following only user-facing documentation to verify they work as expected. Agent QA I have an agent-qa skill in pacwich https://github.com/smorsic/pacwich/tree/main/.agents/skills that instructs an agent on how to perform QA. In this, the agent is not allowed to reference source code but can only use some form of production documentation. I have explicit scopes for the QA processes, such as features or layers to test, package managers to test, whether to use Bun or Node, the source s of documentation to reference, and so on. What makes the skill powerful is that it includes scripts to help the agent set up a sandbox shell to install a fresh pacwich package like a new user. The agent can even read the TSDoc comments when testing the API without reading any actual source code files. Afterwards, the agent produces a Markdown artifact report for me to review, so I can confirm any issues myself with either behavior or documentation. Manual QA, Assisted by an Agent Like the skill I made to assist me in performing review, my manual-qa skill in pacwich https://github.com/smorsic/pacwich/tree/main/.agents/skills instructs an agent on how to guide me through manual QA, but this skill is arguably more powerful. Similarly, this supplies a means for me to run a sandbox shell so I can install pacwich like a new user myself and begin using a fresh CLI right away. Easy Starting Points By similarly providing scopes for what I want to QA to the agent, it can then suggest actions for me to take. It provides CLI commands or TS API code for me to quickly copy and paste with pointers to real documentation references I can choose to follow first instead, and from there I will more creatively poke around with features to see the behavior with my own eyes. The idea isn't to just go through agent-dictated motions, but having some initial nudges towards docs and example usage makes the process a lot more efficient. Quick Test Project Scaffolding Perhaps even more time-saving is how the agent can scaffold test projects for me to work with. The biggest pain in testing pacwich manually is constantly setting up test monorepos with many files to confirm behavior. With this skill, the agent can scaffold in a temp dir I can work out of in my sandbox shell and provide an overview of a test project's structure. It's easier for me to read and tweak test projects than create ones from scratch every time. Manual Documentation, Assisted by an Agent I promise to users that I write my documentation myself. But with docs tailored to LLMs alongside the README and documentation website, it can become difficult for me to keep track of all the changes I need to make. Again, I have a skill in pacwich https://github.com/smorsic/pacwich/tree/main/.agents/skills doc-updates that guides me through making documentation updates without the agent writing any actual contents. The skill serves as a place where I can dump all documentation drift gotchas and have an official checklist that an agent can follow for every update I may need to make.This skill also helps me get agent review for grammar and such as I make my doc changes, so I'll write by hand and then get an agent accuracy/grammar pass before each update task is considered complete. I also reference this skill when performing agentic code review, so that a another agent reviewing a whole feature addition or similar can then double check the documentation surfaces I changed as a whole. Conclusion There is a false dichotomy in the idea that we either have to give up all authorship and critical thinking to AI or not use it at all, so I'm challenging that notion here. When manual review and QA started to become disproportionately difficult compared to making code changes, I realized that I could be getting support from agents without losing my own touch by giving them clear, strict boundaries on how they should help. When there are aspects to developing critical code that seem like a huge pain but can't be fully replaced by an agent, we can still ask ourselves if there's a creative way agents can support us without doing all the thinking for us, rather than it being an all-or-nothing ordeal.