Your Bots are Busy. But Who Is Catching the Rework?

AI made it easy to open another bot. Then another. Then five, each with a nickname, each "helping."

The meter went up. The commit count went up. So did the second afternoons: the fix after the fix, the UI pass after Tank already ran, the twin-screen bug you thought you closed on Link Preview.

More bots are not the hard part. Catching rework is.

That is the question this post answers. My order of priority is deliberate. First, less redo. Second, balanced usage. Cheap wrong answers are still wrong answers.

I split my Cursor work across a few named seats (builder, tester, reviewer, scope, designer) because one chat trying to do every job kept making the same mess twice. That helped. What almost did not help was the week after: I was still the only person catching the redo, and every catch burned time and tokens.

So the rest of this is practical: who catches which kind of rework, how I write that down as standing instructions (because that is still where the rails live), and why specializing seats is about context windows, not cosplaying a human org chart.

Who catches the rework (the short answer)

If nobody owns a row, you will own it later as rework. Bots do not invent that ownership. You write it into their standing pages, or you keep paying.

The honest answer about where the rails live

I looked for a fancy control plane. For the bots I run day to day, I have not found one yet.

What I have is:

1. A standing instruction block I paste (or keep) at the start of that seat's chat: who they are, what they own, what they must not do, what "done" means.
2. A short brief for this piece of work: the ticket, the look we approved, the build to test, the checks I already ran.
3. Me, deciding merge, staging, UI taste, and when to stop overnight work.

That is it for now.

I do have richer process tooling in the repo for other work (AI-DLC). My bots are not running that. Pretending they are would be marketing, not a diary.

So if you want to copy this, copy the boring part: write who catches which redo once, reuse it, and update it the same day you catch a painful mistake yourself.

How I set that up (the part you can do tomorrow)

Step 1. Pick a few seats, not twelve

I started with more roles than I needed. What stuck:

• Builder (Bob): changes the code, opens the PR, does not merge.
• Tester (Tank): tries to break it, does not push or merge.
• Reviewer (Troy): reads the plan and the diff, names blockers, and attests the local check run so Tank is not redoing CI for sport.
• Scope / cost (Frugal): decides what is a must-have for this PR versus polish that can wait.
• Designer: critiques copy and UX (Ultra), or implements Lab UI to match the main site (Lab Designer).

You do not need the whole cast on day one. Builder plus tester is enough to feel the difference. Add Troy when plan and review redo is noisy. Add Frugal when polish keeps expanding the ticket. Add a designer when "works" and "looks right" keep getting confused.

Give each seat a name if that helps you remember which chat is which. The name is for you. The instructions are for the model.

Step 2. Write one standing page per seat

Open a plain markdown file on your machine. One file per seat. Mine live in a local folder I can grab when I start a chat.

I asked the seats what they believe their standing rules are today (from the instructions they were given, and the corrections that stuck). Here is the condensed version I would paste next time. Yours will differ. Steal the shape.

Builder (Bob)

• You implement on a feature branch and open a PR. You never push to main. You never merge. Only I merge.
• Before you write product code, share a short development plan with Troy and wait for his input. Adjust the plan for his blockers. Do not "start coding and hope the review catches it."
• Before you implement, ask Tank which test cases apply to this change (happy path, break paths, twin surfaces like Link Preview and Packer). Bake those into the work; do not discover them only after the PR is up.
• UI changes run with me first. Show staging or screenshots and wait for my OK before you send the work to Tank. Small alignment and style drift still slips through when Tank is the first gate on looks. Tank can still fail functional cases later; taste and layout get my eyes earlier.
• In the PR description, call out key architecture and design changes in plain language (what changed structurally, what shared pattern moved, what the UI is supposed to look like now). Do not bury that only in commit noise.
• Stay in the web UI and its tests unless the brief says otherwise. Do not touch deploy pipelines that ship production.
• Prefer one clear way to do a thing. If Link Preview and Metadata Packer share a rule, fix both before you call it done.
• GitHub Actions may be off. Run the local checks yourself on the Node version the repo expects.
• When you say "passed," name the commit you ran, and do not skip steps or soften a check just to look green. Leave real logs if you claim a full run.
• Answer review and QA notes on the same branch. No force-push. No rewriting history to hide the work.

Tester (Tank)

• You are a QA gate. Try to break the change. Return pass or fail. Do not fix product code. Do not push, open PRs, merge, or comment on GitHub.
• When Bob asks before coding, answer with the applicable test cases for this ticket (including cases he is likely to miss). Keep that list short and concrete.
• For UI work, wait until I have signed off looks with Bob. Do not burn a full QA pass on alignment and style I am about to reject.
• I will give you an exact commit for the real retest. Confirm you are on that commit before you spend the afternoon. If I change the target, drop the old one.
• If Troy (or I) already certified lint and unit tests at that commit, do not rerun them for sport. Use the time on the broken paths users hit.
• Report blocking vs non-blocking findings with steps to reproduce. When I ask for accessibility against main, compare yourself; do not take "pre-existing" on faith.
• Keep any extra test scripts local and attach them in the report.

Reviewer (Troy)

• You review plans and PRs. You do not merge. You do not rewrite the feature unless I ask you to fix a tiny typo yourself.
• When Bob sends a development plan before implementation, answer with risks, missing surfaces, and what must be true before code starts. That is cheaper than a post-hoc blocker list.
• On the PR, separate blocking from nits. Blocking means wrong behavior, broken tests, or scope that was never asked for. Say the file and the line when you can.
• If the branch drifted into pages or docs the ticket did not name, say revert. Do not let "while we were here" become the PR.
• When you attest local CI, name the commit and the known allowed failures. That attestation is what lets Tank skip the suite and go hunting for real breaks.
• Hand blockers to Bob with enough detail that he can fix without guessing. Prefer talking to Bob over making me retype your review.

Scope / cost (Frugal)

• You protect the ticket from growing. Must-haves for this merge versus nice-to-haves for a follow-up.
• When Ultra (or anyone) proposes polish, say clearly what ships now and what waits. Example: role-selector polish that is lovely but not required for the buyer-led home PR.
• Prefer shorter copy and fewer moving parts when the longer version does not change the decision a reader must make.
• You do not implement. You do not merge. You argue scope so Bob and Tank are not drowning in optional work.
• If a change burns tokens or calendar time without reducing rework, push it out of this round.

Designer, critique lane (Ultra)

• You review copy and UX. Be blunt. Flag AI-sounding or template language.
• Suggest concrete line edits. Keep the service titles and audience lines I already chose.
• Do not invent new offerings. Do not start an implement thread unless I switch your mode.
• Check with Frugal before treating a polish list as must-have for the open PR.

Designer, implement lane (Lab Designer)

• Static HTML, CSS, and JS only. No new dependencies. Match the main site's tokens, type, and content width.
• Measure first. Do not say "aligned" without proof (screenshots or a simple width script at a few desktop sizes and a phone width).
• If live production is hard to measure, say so and measure the preview or local build with the same checks. Do not invent before numbers.
• Honor the ticket on whether you may call other bots. Open a PR. Do not merge. Do not deploy production.

Paste the right block at the top of a new chat and keep that chat for that seat. When the chat gets fat, start a fresh one and paste the same block again. The reuse is the whole trick.

If your tool supports saved rules or a reusable prompt for a cloud bot, put the same text there. I still treat the markdown file as the source of truth, because that is what I can edit after a bad day.

Why specialize (it is about the context window, not the org chart)

People hear "builder, tester, reviewer" and think I am cosplaying Scrum with chatbots. That is not the point.

The point is attention. Each seat keeps a thinner working set: Troy holds the plan and the diff risks. Tank holds break cases. Bob holds the implementation. Frugal holds what is in or out. When Bob asks Troy and Tank before coding, those answers land in Bob's window as short, useful context instead of a graveyard of half-remembered chat.

That will often use more tokens on the first pass. Specialized seats plus side talk is not the cheapest graph. It is usually the graph with fewer second passes, which is where rework lives.

Why Grok Bot helps catch redo earlier

Standing pages alone still leave a messy human in the middle if every handoff is copy-paste through me.

One real advantage of Grok Bot for this setup: bots can talk to each other. Bob can send the plan to Troy and get notes back. Bob can ask Tank for applicable test cases up front. Troy can hand PR blockers to Bob. Tank can send a fail list without me retyping it. Frugal can tell Ultra which polish is in or out for this PR.

I still own merge, UI taste, and "stop for the night." I am not trying to leave the company. I am trying to stop being the only person who notices the redo. When the seats can pass work sideways, mistakes get caught in the next seat's window, not three chats later in my summary.

Step 3. Add a tiny brief every time you hand work over

Standing instructions are the job description. The brief is today's assignment. Keep it short:

• What ticket / what page.
• What "done" means in one sentence for this job.
• What not to touch.
• For the tester: the commit hash, and the three cases you care about (or the list Tank already gave Bob).
• For the designer: the prototype or live page to match, and how you want proof.

I used to type "retest when it's fixed." That sent the tester back to the old code while I thought we were talking about the new one. Now I paste the hash. Boring. Effective. Wrong-build retests are pure rework.

Step 4. Keep one human gate

Bots can draft the PR. They should not be the last word on:

• Does this match what we approved visually? (Bob shows UI to me before Tank.)
• Did the PR say what architecture or design actually changed?
• Is there still one way the system does this?
• Are we merging, or only parking a branch?
• Are we burning weekly usage overnight on purpose?

If you skip that gate, you did not get more capacity. You got unsupervised spend, and you are still the one catching the morning cleanup.

Step 5. After every painful interrupt, edit the standing page

This is the part I skipped too often.

When I caught dual logic paths, I should have updated the builder page that day: "if you change how a run becomes ready, check both Lab tools." When the tester chewed time on checks I had already run, that sentence went into the tester page. When "looks aligned" was not true in the browser, the designer page got "measure it." When Bob coded before anyone named the tests, the builder page got "ask Tank first; share the plan with Troy." When Tank kept finding work that was really "the spacing is off," Bob got "show UI to me before Tank" and "write the architecture and design changes into the PR body."

If the lesson only lives in the chat scrollback, next week you will be the one catching that rework again.

What I learned the hard way

A few stories, without the process jargon.

I called something "done" because the feature worked, while the page still looked wrong next to the design we had already signed off. That is two projects pretending to be one. Now I catch looks before Tank runs.

I watched a fix land in one Lab tool and leave the sibling tool broken the same way. Same idea, two screens. Bob's page now says: change a shared rule, check both places.

I asked for a retest without naming the commit. We argued about results that belonged to different builds. Naming the commit ended that argument.

I left bots running after I stopped for the night. The weekly meter did not stop with me. Now I treat "close the tabs / pause background work" as part of logging off, especially once weekly usage is already high.

None of that required a new platform. It required naming who catches that class of redo, and writing it where the next chat would see it.

Tokens come second, but they still need a habit

More seats means more context. Side talk between Bob, Troy, and Tank will show up on the meter. That is real money on a metered plan.

I still treat that spend as insurance against redo, not as a free lunch. What keeps the meter from becoming a lifestyle:

• One main build lane per day.
• Use a stronger model when the question is "what did we mean?" or "why are there two designs of the same thing?" Use a faster model when you are merging obvious fixes.
• Do not leave background bots on overnight as a default. I pause them when weekly included usage gets uncomfortable (for me, somewhere around seventy percent).
• Keep logging and blog edits off the expensive models.

Again: fewer redos beat cheaper models that still force a redo. Narrow windows that talk a little beat one fat window that pretends it remembered everything.

A setup checklist you can steal

1. Create markdown files for the seats you actually use (builder, tester, reviewer, scope, designer).
2. For each seat, write what rework they own and what they must never do (start from the samples above, then ask the seat what it thinks its rules are and fix the gaps).
3. Start one chat per seat; paste the file; keep it. Prefer a setup where bots can message each other so you are not the only router.
4. For build work: Bob shares the plan with Troy, asks Tank for test cases, implements, shows UI to me before Tank, and writes architecture/design changes into the PR description.
5. Every handoff gets a short brief (ticket, done line, commit if testing).
6. You still own merge, UI taste, and "stop for the night."
7. Same day as a painful mistake: edit the markdown file, not only the chat.

If you later get a workflow engine your bots actually run (I have one in the repo that these bots do not use yet), you can move the same text there. Until then, reusable instructions are how rework gets an owner.

If you want help on your stack

This is the consulting work behind CohesionStack: how to run AI-assisted delivery without spending the week catching the same redo, and without treating the usage graph as a personality trait.

I help teams decide which seats they need, who owns which class of mistake, what belongs in standing instructions, and which decisions stay human: who merges, who signs off on looks, and when overnight bots stop.

Describe your challenge · Services

AI will keep giving you more bots. The useful question stays the same: who is catching the rework? Write that down. Reuse it. Update it when it hurts.