An AI-assisted team can produce more changes than a maintainer can comfortably review. The limiting factor soon becomes confidence: which change solves the request, what else it touched, and whether the reported checks apply to the final version.
The House of Senn development drafts describe specialized agents, ownership lanes, shared records, and independent verification. Those mechanisms are useful when they reduce ambiguity. They become overhead when the process produces more status messages than evidence.
Give a task a reviewable boundary
Define the user-visible result and the files or interfaces the work is expected to affect. Identify dependencies before parallel work begins.
A research task can return a short decision memo with sources. An implementation task can return a diff and a runnable result. A verification task can return observed failures tied to the exact version reviewed.
These deliverables should meet at an explicit integration point. Several completed subtasks do not guarantee a working combined product.
Keep the repository authoritative
Record the branch, commit, and uncommitted state before making changes. Avoid letting two workers rewrite the same file without coordination. Preserve unrelated work.
A handoff should identify owned paths, commands run, remaining uncertainty, and any state that must be preserved. A conversational claim that something is finished is not a substitute for the actual artifact.
Use concise durable notes for long work. Copying an entire conversation into the next prompt can bury the decision that matters.
Review behavior before volume
A large patch or a high test count says little about whether the user’s problem is solved. Begin review with a concrete example of the intended behavior.
Run checks that could expose a meaningful failure: an invalid input, a stale permission, a navigation path, a resource limit, or a realistic integration. Tests that merely reproduce the implementation’s own assumptions provide weaker evidence.
For visual work, inspect the rendered result at the sizes people will use. A successful build cannot tell you whether a menu is unreachable on a phone.
Make independent review specific
A second agent using the same mistaken assumptions may agree with the first. Give reviewers an independent acceptance criterion and access to the relevant source.
Ask them to trace a critical path and identify what would falsify the completion claim. Keep failures attached to a reproducible case. Resolve them in the artifact, then verify the affected behavior again.
The archive’s operational totals describe historical reports, not a live measurement of today’s system. Avoid treating old delivery counts as proof of current reliability.
Check the evaluator as well as the patch
OpenAI’s July 2026 coding-evaluation audit describes cases where benchmark prompts and tests disagree or fail to cover the intended behavior. The finding is specific to the audited benchmark; it does not assign an error rate to every software test suite.
For a real change, ask a reviewer to implement a plausible wrong solution mentally. Would the checks reject it? An authorization test that only checks a successful request may pass code with no authorization at all. A visual snapshot may pass while a saved value is discarded.
Add the smallest discriminating check, then confirm it fails on the relevant faulty behavior. Preserve the user’s acceptance criterion independently of the implementation’s structure.
Make the evidence refer to an immutable artifact
SLSA 1.2 provenance separates records about source production and build production. Provenance helps identify how an artifact was produced; it does not establish that its behavior is correct.
For an agent-assisted patch, record the input revision, final diff, dependency lockfile, build command, resulting artifact hash, and checks run on that artifact. If a reviewer changes the patch after testing, mark affected evidence stale and rerun the relevant checks.
A practical handoff has three links: the change, the runnable result, and the evidence. Include one sentence naming the unresolved risk, if any. Keep tool transcripts available for diagnosis, but make the completion claim readable without them. This proposed evidence format gives a maintainer a concrete object to accept or reject.
Finish with a useful handoff
Report what changed, why, how it was checked, and what remains uncertain. Link the result. Record a recovery path for consequential changes.
The purpose of coordination is to make the next action clearer. When a maintainer can understand a change without reconstructing the entire conversation, the evidence trail is doing its job.
Keep a good idea close.
Follow Signal Tower
