Make your Bot the manager, not the coder: one rule and locke

How this helps you

Your Bot stays a clear-headed manager, coding runs on the tools built for it, and mistakes become rules instead of repeats.

✦ Try it

For anything more than a short question, don't write the code yourself. Hand it to a coding agent with an acceptance test. Check the proof. Open a pull request and report back. Never merge. When I correct an agent, propose where the fix belongs: code first, then a lint rule, then a rules file, with review last.

Fill in: No placeholders. Add your repository names if your Bot works across several.

What they did

Rob Shocks argues your Bot should be the manager, not the coder. Grok Bot is good at the first mile (working out what to build from Slack, email, X and Linear) and the last mile (chasing and checking the work), while coding agents such as Claude Code or Cursor cloud agents do the middle. Handing the coding off also saves usage, since Grok Bot runs on one weekly usage pool, and gives each worker its own computer, context and kill switch. His starting rule for your Bot: for anything more than a short question, don't write the code yourself; hand it to a coding agent with an acceptance test, check the proof, open a pull request and report back. Every time you correct an agent, move the fix up the stack: code first, then a lint rule, then a rules file, with human review last. He also warns that all your Bots share one cloud computer, including files, browser sessions and command line credentials, so a coding CLI logged in with an API key on it can be used by every Bot. His advice: run agents in a sandbox, give scoped and read-only credentials where you can, and let them open pull requests but not merge them until you trust your setup.

Who it's for: Developers and technical founders who already use coding agents.

Before you start

A coding agent your Bot can hand work to (Cursor cloud agents, or a coding CLI on its computer).
GitHub connected, with a repository you're happy for agents to open pull requests on.

How to try it

Paste the rule below into your Bot's description.
Give it one real task and watch the hand-off: acceptance test, proof, pull request, report.
Check which credentials are on the shared computer. Swap broad keys for scoped or read-only ones.
Keep merge rights with a person until you trust the checks.
Each time you correct an agent, ask your Bot to turn the fix into code, a lint rule or a rules file.

What to expect

'Handed the date bug to a cloud agent with a failing test. Test now passes, screenshot attached. PR #142 is open for your review.'

Common mistakes

Letting the Bot write big changes itself. It burns usage and you lose isolation.
Logging a coding CLI in with a full-access key on the Bot's computer. Every Bot can use it.
Starting with 50 agents. Rob's advice is one loop first.

Related tips

How to trust your Bot's work more: Put most of your effort at the top: code structure, then lint/tests/CI, then prose rules, then human review.
Run Claude Code or Codex on your Bot's computer with your own plan: Your Bot's computer has a terminal, so it can install a coding CLI, you sign in once, and your Bots can use that subscription from anywhere.
Watch coding work live and get recordings back: With Cursor connected, your Bot links you to the cloud agent live and sends screenshots and screen recordings.