From code to merge: organizing agent workflows as a team

When several sessions produce PRs faster than the team can verify them, PRs pile up. An additional session can increase output without reducing delivery time. The question becomes: what is waiting, and who can unblock the next step?

Work and waiting need separate records. A PR may wait for someone to become available, then require time to read the diff, reconstruct the context and discuss a correction. CI may wait for a runner, then consume compute while executing tests. A retry adds compute and may require another review. These activities have different causes and costs.

Review and CI can proceed in parallel. But when a necessary check is missing, the merge decision waits. Counting commits or open PRs alone hides this downstream work.

On a recent PR, I therefore look for the points where progress stopped: missing context, a missing test result, an unavailable reviewer or a correction that needed rework. These are more useful for choosing an improvement than the number of active sessions.

Coding faster moves the cost to verification opens my Engineering the Review Loop series: it connects these queues to delivery measures and separates attempt cost from the cost of accepted work.

I use harness to mean the instructions, tools and checks that govern agents, together with their permissions and budgets. Its operation also depends on organization: who reviews, who answers questions and who decides?

In Harness engineering for coding agent users (April 2, 2026), Birgitta Böckeler distinguishes guides before action and sensors after action. Either can use deterministic tools or model judgment. Instructions guide; tests and reviews supply feedback. Maintainability, architecture and behavior need different controls. Human steering remains necessary; passing agent-written tests alone does not establish intended behavior.

For the layer shared by the team, my article on the AI instruction system at Aristote explains common sources, ownership and drift checks. It develops the organizational side of context engineering.

To choose what belongs in context, the L0-to-L5 context engineering playbook starts from the observed problem: missing information, irrelevant rules or behavior that needs checking. It distinguishes persistent constraints from procedures loaded for a task. These context capabilities complement the four harness layers below; the two frameworks describe different things.

I read it as four layers, from bottom to top:

Check on the workstation before asking for another review

Locally, I read the diff and run the checks relevant to the change. Finding an error here may avoid a correction push, a CI retry and another request to the reviewer. The talk illustrates this possible rework; it does not quantify savings.

Local execution uses the workstation’s CPU and RAM. Several worktrees, builds and test suites can exhaust those resources. A review orchestrated from the workstation may also call a billed remote model: “started locally” does not mean “free” or “executed entirely on this machine.”

When several worktrees coexist, Worktree Sweep, one of my personal projects, inventories working branches and local files to help identify what needs preserving. Its macOS MVP remains read-only: it does not delete worktrees.

Local checks prepare the PR. They do not replace mandatory CI tests. A draft PR can be opened early; before marking it ready for review, explain the change, the tests performed and what remains to be checked.

The description should make the problem understandable before someone works through the entire diff. It serves people and agents. In my workflow, the summary explains the change to the team; a collapsible “AI et détails” section collects the technical context that a PR-reading skill retrieves.

In the Aristote example shown in the talk, pulling dependency changes caused AI configuration synchronization to fail. Installed dependencies were out of date. The fix updates them before synchronization. This summary explains the trigger and the expected outcome; the details can then show the hooks and checks.

A useful description gives the problem, the behavior after the change, the checks actually executed, their results and remaining limits. A list of tests or a comment saying “it works” is not sufficient evidence of behavior.

For adaptable starting templates, my Claude Code Plugins project includes PR descriptions, review requests and merge checklists. These help structure the work; each PR still needs its own checks and results.

Start with what the change could break

An agent, a person or both can perform these roles. The agent needs the risk to check, the expected result and the necessary tools. A person can add cases, replay the journey and resolve an uncertain business rule.

Present in the DOM does not mean visible, readable or functional. For a button, inspect the rendering and test the expected action. A shared component may affect several pages despite a short diff. For access rights, hiding a button does not secure the API: the server must also reject an unauthorized request.

A test written but not run remains a check to perform. These targeted checks supplement the team’s usual controls.

Make the need for review visible

The talk proposes two GitHub label names: Review AI and Review Human. They are examples for routing review, not evidence of a routing system deployed everywhere.

A mechanical, bounded change covered by tests may receive AI review within a scope authorized by the team. Access rights, private data, payments, business calculations and poorly understood consequences require a person’s review. A small PR can have large consequences. When in doubt, involve a person; after a push that changes the scope, reassess that choice.

The label helps the team find PRs waiting for them and helps an agent select those it may process or prepare. A GitHub filter triggers nothing by itself: a workflow must actually use it. The label does not authorize merging. Required checks still apply and, in this workflow, a person decides whether to integrate the change.

At Aristote, we defined a trio: CodeRabbit, Marc Hugon’s FriendlyReviewer and Claude as a native review agent. The native Claude agent is separate from the Claude bot operating on GitHub. In the workflow described in the talk, CodeRabbit and FriendlyReviewer work remotely on an already pushed commit; coordination happens from the workstation.

All three readers need to examine the same version and comparison base. We also need to know what they actually covered. On the PR used in the talk, CodeRabbit reported excluding Markdown, although our skills are written in Markdown. A reviewer’s name therefore does not guarantee that every file was read.

That PR presented the setup and GitHub reviews. It demonstrated neither a complete execution of the local trio nor a measured benefit. More readers are useful only if their feedback can be acted on.

Process feedback together

The workflow presented in the talk as /tech:pr-feedbacks organizes three steps:

1. Collect all feedback on the PR.
2. Validate each finding against current code, group duplicates and expose disagreements.
3. Correct the accepted problems, using several agents or models as needed, then rerun the relevant tests and reviews.

This is a custom workflow I am describing, not a standard command bundled with review tools.

A finding may concern an old version, lack context or conflict with another proposal. Several identical comments are not several bugs. The coordinator maintains the link between each problem, the decision and the correction, and checks that the changes remain coherent with each other.

For the human reviewer, the synthesis must preserve disagreements, limits and decisions still needed. A rejected finding deserves a verifiable reason. A correction that has been started needs a result, not just the name of the agent assigned to it.

To evaluate another reader’s contribution, When an independent reviewer earns its place proposes a comparison on the same diff. Operating a multi-reviewer system safely develops roles, permissions and degraded outcomes. Their protocols do not establish that our trio has already passed that evaluation.

A correct diagnosis can produce the wrong fix

On an Aristote PR, CodeRabbit identified a test that accepted any error. The diagnosis was useful; the suggestion nevertheless used the same expected message for cases that required different messages.

Here is the talk’s simplified example, not the PR’s exact cases or messages:

The vague assertion can pass because the code fails for the wrong reason. The suggestion adds precision but gets the first case wrong. Assertions need to match the expected behavior, then the tests need to run again.

There are therefore two decisions to verify: the reported problem and the proposed correction. If the expected behavior is unknown, the agent needs a human decision. After the fix, the new diff and results must be reviewed.

An agent correcting code after review or CI needs an objective, an allowed number of attempts and a budget set before it starts. Otherwise, a new attempt may only repeat the previous one.

Designing a bounded review loop develops the controller contract, counters and failure cases. A green review is not a merge gate adds revision-bound results and branch policy. Both distinguish a proposed control from behavior verified in a repository.

A useful handoff explains what was attempted, what remains unknown and the next possible action. An exhausted budget does not prove a bug. If the agent runs inside a CI job, that job’s status depends on its role; mandatory tests must still produce their own results.

Red CI first needs a diagnosis

I start by reading the logs. Two cases from the talk show why:

• The test ran and found an incorrect calculation. Correct the code, then retest.
• The test never started because a dependency was missing. Restore the environment, then execute the test. The calculation has not yet been verified.

If the expected result is itself unclear, clarify the business rule. If the job result is missing, retrieve it. Automatically requesting a code change whenever a red cross appears mixes these situations together.

Results stay attached to the tested version

Commit A was tested and reviewed. The agent pushes a correction: commit B. Successes on A remain results for A; they do not prove the behavior of B’s changes. The previous review does not automatically cover what changed.

Before merging B, I inspect what changed between A and B, which tests ran on B, their results and the version actually reviewed. I repeat the checks affected by the change, plus those required by the team. Not everything necessarily needs repeating, but what remains covered and what needs rechecking must be explicit.

A running, skipped or canceled test is not a passed test. This does not prove a bug; a result is missing. An exemption follows the team’s rules. A useful PR record brings together the commit, checks and results, review coverage, open questions and human agreement.

Correcting a PR resolves the current case. When the same error, false alert or wasted effort returns, we also need to examine what caused it.

I open an issue containing the precise case, expected result and linked PR. Depending on the cause, the response may be a missing regression test, a clearer instruction or additional context for the reviewer. A new instruction is not always the best response.

The talk’s example is a mishandled empty list: fix the code, add a test for that case and clarify the instruction if it contributed to the problem. Then replay the case and the other affected behaviors. A correction that handles an empty list but breaks a nonempty one has not met the need.

The next check happens on later PRs. Does the problem return? Does the new rule produce false alerts or extra work? It must be possible to revise it, shorten it or remove it when it does not help.

Installing a rule does not demonstrate a benefit. The harness evolves with the code, tools and team. Its controls need their own verification cases and someone able to maintain them.

Diagnose and repair context drift, part 2 of my Context Engineering series, develops the loop of observing, locating the cause, repairing the source and replaying the case. It separates evidence that an instruction loaded from evidence that the agent followed it. This extends the maintenance approach without establishing that a complete self-learning loop has been tested.

Turn recurring review comments into tested controls then examines the control, its reserved positive and negative cases, its owner and its removal. It separates improvements to the author’s harness from improvements to the reviewer’s harness.

My ctxharness tool addresses part of this maintenance: finding facts that have become false between code and instructions, such as an outdated version or file path. These static checks complement behavioral cases. The article on portable agent configuration explains why an instruction being present, installed, loaded or invoked does not yet demonstrate that it is effective.

At Aristote, I observe a clear acceleration in delivery. In the talk, I describe our pace: a feature in a few hours, an epic in a few days. That is the pace I observe in our team. The talk does not provide a controlled comparison that attributes a quantified benefit to the reviewer trio or the whole harness.

The question now is where we can save more time, with what quality and at what cost. Take consolidating bot comments before a person resumes the PR:

To observe Claude Code sessions, I develop ccboard, a local dashboard. Its counters still need scrutiny: my article on three ways to measure AI usage examines their scope, possible double counting and the difference between API-equivalent cost and an invoice. A session dashboard does not by itself measure the quality of delivered work.

The article on cost per accepted task develops the accounting question: failed attempts and human corrections count too.

Two review-series parts clarify what can be measured: 5 AI code reviewers, 1 repository, and what developers did next analyzes a historical export closed on September 28; Testing Opus 5.5 as the code-review baseline proposes the next comparison. The first records visible actions without ranking quality; the second reports no new model run.

Waiting for a runner and reading comments need separate tracking. Before-and-after comparisons need similar PRs: a large functional change and a tiny mechanical correction do not make a useful comparison. Different outcomes can also come from a scope change or the people available.

When a harness adds cost without improving the result

Added on October 14, 2026, after the talk.

In Are Harnesses Worth the Cost?, Naresh Jain (October 13, 2026) compares Sol and Luna at low reasoning effort on one greenfield Java service, 10 attempts per condition and 178 identical external tests. Both conditions receive the brief and baseline repository instructions: “without harness” does not mean without context.

API-equivalent estimates exclude setup, maintenance and repairs. Small sample, unusually detailed brief, findings not generalizable to our PRs. Final-gate-only checking remains untested.

My article How to read a token-compression benchmark provides a reading checklist applicable here: matching tasks, versions and acceptance criteria, including failed attempts. It also explains why comparing complete configurations cannot attribute their difference to a single component. Its examples concern token reduction; they do not reproduce Jain’s experiment.

For the workflow in this guide, I take away a question to test on our changes: which checks prevent enough defects or rework to justify their cost? Another review or a test rerun after every edit needs a measure of what it contributes. Verification frequency and the checks required to accept a PR remain separate decisions.

The studied harness provides feedback while building a service; the talk’s setup also organizes reviews, responsibilities and merging within a team. Jain’s results therefore measure neither our reviewer trio nor our delivery pace. Testing our organization would require comparable PRs with the same acceptance criteria, accounting for rework and human effort, and attaching every result to the commit actually checked. I did not run that comparison as part of the talk.

The Luna/Astra pilot prepared without model calls

Our preparation status on October 14, 2026. A separate pilot plans 12 attempts on 3 frozen tasks: gpt-6-luna and gpt-6-astra, each at medium and xhigh. These identifiers come from the installed Codex client’s catalog. The 31 local tests and 6 isolation checks pass. Four client sessions use fixed responses from a local server; 12 confined evaluations use operator-written control submissions. Interruption disconnects the local stream and prevents continuation.

No benchmark model has been called; the budget remains undecided. Actual access, provider-applied effort, consumption, final counters after interruption, a hard limit during a response and a memory ceiling remain unverified. This preparation neither reproduces Jain’s Sol/Luna experiment nor measures gains from our review workflow. One attempt per task and configuration will qualify the pilot, not establish a ranking.

Try one change on the next PR

I suggest returning to a recent PR with three questions: what went wrong, what took the most time and what do we change on the next PR?

Choose one action and the person who can act. If the team always asks “what did you test?”, have the agent preparing the PR record the checks run, their results and their limits. On the next PRs of the same type, look for fewer questions, less waiting and less rework without more bugs.

Keep what helps, adjust or abandon the rest. If the description becomes a wall of text, shorten it. If an additional review produces nothing actionable, inspect its coverage and the work it adds. Removing a required check to improve the delay does not demonstrate better delivery.

Connect the merge to delivery and use

The journey starts with a clarified need and a plan, followed by code and local tests. The PR makes the change understandable; reviews and CI provide results; the team decides whether to merge. Delivery and verification in use still remain. Merging does not mean the code has already been deployed and verified in production.

Bugs, feedback, time and costs inform the next iteration. I develop this connection with the whole team’s work in Lean and AI: work that reaches users. The harness requires technical skills to configure, test and automate, and organization to distribute work, review and decide.

Added on October 14, 2026, following questions received after the talk.

Does one agent process the feedback, or are responsibilities split?

The setup presented separates coordination from corrections. A coordinating agent gathers feedback, checks findings against current code and keeps track of the whole change. Accepted fixes can be assigned to several agents or models as needed. This does not require a new agent for every comment or every step.

The split depends on how the fixes relate to each other. Independent problems can be assigned separately; changes affecting the same files or business rule need closer coordination. A delegated task needs a confirmed problem, a defined scope and a result to verify. The coordinator then reviews the complete diff and results to check that the changes work together.

/tech:pr-feedbacks is the name used in the slides. In my current Aristote instructions, /tech:pr-feedback handles collection and reporting without making changes, while /tech:pr-reconcile handles authorized corrections within a bounded cycle. Separating these functions does not require a different agent for every step. The section on consolidating reviews explains the checks shared by these roles.

Have you tested a self-learning loop for recurring problems?

I have not yet tested a complete self-learning loop. The mechanism presented in the talk preserves the case in an issue, addresses its cause, reruns the relevant tests and observes subsequent PRs. It improves code, tests or harness instructions; it does not describe retraining the model.

Automation could propose a regression test or an instruction change based on an observed problem. The old and new versions would then need comparison on that case and other behaviors, followed by checks that the change reduces errors without creating false alerts. The change would need to remain versioned, reviewable and reversible. This is a possible extension, rather than a complete loop I have already tried.

The chapter on recurring problems develops this approach. My article on the team’s AI instruction system covers shared instruction maintenance and drift checks.