Skip to content
How I run a team of coding agents

From a customer’s bug report to a fix a tester confirms, without me passing every message

ResultA tester agent, using HYVIRAL as a customer would, caught the in-app assistant falsely claiming no profile was linked. After the fix shipped, the same tester confirmed it in a fresh conversation.

In plain words
The problem
One person cannot be the relay between several AI agents all day. Reports, fixes, reviews and retests need to flow without me forwarding each one, and without losing track of what is fixed, deployed or confirmed.
What I did
I gave one agent ownership of each fix, start to finish. Before anything reaches production, it runs the changed flow with real API calls against a test copy of HYVIRAL, on my machine or in staging, so testers never see untested work. A second agent that never saw the work reviews the exact change before it ships. Tester agents with only a customer’s access use the product and report what breaks, in one Slack thread per issue.
What happened
A tester caught a false claim the assistant made to a user, the fix shipped, and the tester confirmed it in a fresh conversation. A later review caught missing wiring that the unit tests had worked around.
My contribution

I designed the agents’ roles, the rules for handing work over, what counts as tested before anything ships, what the reviewer may see, and how customer-side testing reports back.

HYVIRAL’s development harness connects engineering, review and testing agents through Slack, so they can investigate reports, implement changes and ask for verification without me routing every handoff. I define the work, set what counts as done and decide anything consequential. The hard part was deciding who is responsible for what.

My responsibilityDefine the work and the acceptance bar

Resolve disputed findings and consequential decisions.

One delivery ownerEngineering agent

Intake, implement, deliver and provide evidence of the running revision.

A fresh perspectiveCode-review agent

Review the exact changes without the implementation conversation.

Blocking findings return for correction. Disputes return to me.

The customer’s doorTester agents

Retest with only a customer’s tools and instructions.

Confirmed Issue closes with evidenceStill failing Issue returns to delivery

Autonomous handoffs. Explicit ownership. Customer-verified closure.

Decision 1

One owner per fix, reviewed with fresh eyes

On 8 September 2026 I merged intake, implementation and delivery into one engineering session. The separate fixer and reviewer sessions had already collapsed into one twice, and the permission boundary between them stopped the fixer from finishing its own deployments.

Every change is tested before anyone else sees it. The engineering agent drives the changed flow with real API calls against the local stack, using staging services where the flow needs them, because a green unit-test run mocks the very services the change depends on. Nothing goes to production for the testers until that run passes.

A fresh code-review agent replaced the standing reviewer. It examines the exact change about to ship without having watched it being written, looking for dropped fields, mismatches between the front end and the back end, and tests that pass without detecting the defect. Blocking findings are fixed before the push, and delivery ends with evidence of the running version and retest steps in the issue thread; a tester’s confirmation closes it.

The tradeoff is a serial delivery cycle: several testers can find problems faster than one session can fix them. I took that bottleneck in exchange for clear ownership, fixing severe defects first and batching small ones.

SourceDecision record + operating rules

The dated decision that merged the fixer and reviewer roles, and the review contract every production push goes through.

Read the source
Decision 2

Test through the customer’s door

I added a tester agent with a real customer account and the public documentation, but no access to the code or internal specifications. An engineering agent can work around a misleading instruction because it knows the implementation; a customer’s assistant cannot, and I wanted the failures a customer would hit.

I also removed a reporting step that was failing: after 15 reports, the tester’s issue repository was still empty because the tester could not reach it. One Slack thread per issue replaced it, and the engineering register stayed the system of record, with automatic checks for duplicate or missing IDs.

The cost is keeping the conversations and the register in agreement. That bookkeeping is what separates a fix on my machine, a deployed change and a result a customer has confirmed.

SourceCustomer-side reproduction + closure

The closed issue: the assistant’s false “no profile linked” claim, the per-turn fix, the deployment, and a fresh-conversation retest by the customer-side tester.

Read the source

Results

On 7 September a tester agent caught the in-app assistant falsely telling a user that no social profile was linked. The fix re-checks the account’s state on every turn; after deployment the tester confirmed it in a fresh conversation and the issue closed.

The same day, retesting exposed incomplete fixes to the retry logic in the ingestion pipeline, the step that pulls in a creator’s posts, until it processed 23 reels with 79 of 79 steps successful.

On 9 October a fresh-eyes review by Codex flagged missing service wiring that the isolated tests had bypassed, plus an error on upload completion.

The 7 September closures predate the reorganisation: they show the customer-side loop working, not a measured effect of the new structure.