{"slug": "how-to-work-with-ai-coding-agents-thorsten-ball-s-15-rules", "title": "How to Work With AI Coding Agents: Thorsten Ball's 15 Rules", "summary": "Thorsten Ball, who works on the Amp coding agent, published a list on October 25, 2026 titled \"How I work with Agents... as of October 2026\" that drew roughly 295,000 views in hours, laying out 15 rules for working with AI coding agents such as Claude Code and Codex. The rules include switching to the newest models because a model that errs 10 percent of the time forces verification of every answer, prompting for the desired end state rather than the method, giving each agent its own local environment to avoid port and database collisions, and reserving human review for high blast-radius files. Ball's central argument is about variance rather than price: a cheaper model needing two attempts and a human review pass costs more than a stronger model that succeeds first time.", "body_md": "Thorsten Ball, who works on the Amp coding agent and wrote the books on building interpreters and compilers, posted a list on October 25, 2026 titled \"How I work with Agents... as of October 2026.\" It reached roughly 295,000 views in hours. The reason is simple: it is a field report from someone who runs agents all day, and it contradicts a lot of advice that was correct six months ago.\n\nThis post turns the 15 points into a working playbook for [Claude Code](https://explainx.ai/blog/claude-code-commands-complete-reference-guide-2026), Codex, or any other coding agent. For each rule we explain the mechanism, show how to apply it this week, and say where we disagree or where the evidence is thinner. The list is one practitioner's opinion, and we label it that way.\n\n## TL;DR: the 15 rules and what to do with each\n\n| Rule | One-line meaning | Do this today | \n|---|---|---|\n| 1. Use the newest models | A model that errs 10% of the time costs retries | Switch your default model to the latest tier | \n| 2. Stop worrying about slop | Recent models add less mess than before | Judge the output, not the fear | \n| 3. Prompt the what, not the how | Give the end state and a measure | Write goals with numbers | \n| 4. Make the SDLC legible | If the agent cannot see it, it invents it | Give it logs, deploys, flags, tickets | \n| 5. Build SDLC tools | Plugins for bug reports, health, flags | Wrap your repeat chores as tools | \n| 6. Eval agentic knowledge | Test whether AGENTS.md and skills help | Run control versus treatment agents | \n| 7. Local dev feels yucky | Agents collide on ports and databases | Give each agent its own environment | \n| 8. Build tools to iterate | Skip trial and error chats | Ask for 20 variants and a comparison page | \n| 9. Ask for irrefutable proof | Demos and numbers beat claims | Write \"this is not evidence\" into AGENTS.md | \n| 10. Let them wait on you | Do not watch the cursor | Batch bigger tasks, run async | \n| 11. Use schedules and heartbeats | Agents that wake up on their own | Schedule log checks and daily jobs | \n| 12. Do not manage context | Compaction works | One thread per task, stop counting tokens | \n| 13. Threads are memory | Link threads to commits | Keep the \"why\" findable | \n| 14. Do not let agents write for humans | Except mechanical output | Let them draft debugging steps and incident reports only | \n| 15. Review only high blast radius | Spend review on the few files that matter | Name your five central files | \n\n## Rule 1: Use the latest model, because uncertainty is the real cost\n\nBall's argument is about variance, not price. If a model is wrong 10 percent of the time and you cannot tell which 10 percent, you must verify every answer or try several times. He compares it to hiring a generalist who is half the cost but randomly 20 percent dumber. His example of a stale choice: \"Who's still using Opus 4.5?\"\n\nThe practical arithmetic matches what we see in cost data. A cheaper model that needs two attempts and one human review pass is more expensive than a stronger model that lands first time, once you count your hour. If you are comparing prices, our look at [agent teams versus a single agent on token cost and quality](https://explainx.ai/blog/ai-agent-teams-vs-single-agent-vals-ai-token-cost-quality-2026) shows how quickly retries and coordination overhead eat the headline savings.\n\nWhere it breaks: bulk mechanical work, such as renaming a symbol across a repository or reformatting files. There, errors are cheap to detect, and a smaller model is fine. Keep the strongest model for ambiguous tasks and anything you cannot check automatically.\n\n## Rule 2: Slop anxiety is out of date, but keep a tripwire\n\nBall writes that he is no longer convinced agents add slop, and even if they do, he is not convinced the result is unmaintainable. That is a strong claim, and it is the one most readers will push back on.\n\nIndependent evidence is mixed. A Harvard and Jellyfish analysis we covered found that [coding agents produce more code, not necessarily more software](https://explainx.ai/blog/ai-coding-agents-more-code-not-more-software-harvard-jellyfish-review-bottleneck-2026), with review as the bottleneck. Both can be true. Models write cleaner code than a year ago, while the volume of code grows faster than anyone can read it.\n\nOur read: treat slop as a measurable risk, not a feeling. Watch for rising test runtime, growing dependency count, and files that nobody can explain. If those stay flat, relax. If not, tighten review on the affected area. Rule 15 is how Ball manages that trade.\n\n## Rule 3: Prompt the what, not the how\n\nBall's examples: \"Make the bytecode compiler and VM as fast as you can. Do not stop until it's 2x faster,\" and \"Here's how it should work in the end.\" Both state a goal and a stopping condition. Neither dictates an approach.\n\nWhy it works: you know your product, but the agent can search a much larger space of implementations in the time it takes you to type the plan. A \"how\" prompt caps the result at your own idea. A \"what\" prompt with a number turns the task into a loop the agent can run until the number moves. This is the same idea behind [loop engineering](https://explainx.ai/blog/loop-engineering-coding-agents-claude-code-guide-2026): a goal, a check, and a reason to continue.\n\nA template you can paste:\n\n```\nGoal: p95 latency of /search under 120 ms on the benchmark in bench/search.ts.\nConstraint: no new dependencies, public API unchanged.\nStop when: the benchmark shows the target on three consecutive runs.\nReport: before and after numbers, plus the diff summary.\n```\n\nThe risk is a goal with a loophole. An agent told to \"make tests pass\" may weaken the tests. Always pair the target with a rule it must not break.\n\n## Rules 4 and 5: Make the whole software lifecycle visible to the agent\n\nBall's central observation: tool calls stopped hallucination, because they let agents touch reality. If an agent cannot see something, it makes it up. So give it access to run what it builds end to end, read production logs, deploy, watch the rollout, cut the release, flip the flag, triage the bug report, and email the customer. His rule of thumb: anything you can see, the agent should see too.\n\nHis team built custom plugins for bug reports, emailing users, \"Is our system healthy?\" and granting feature flags. The pattern is a thin, safe wrapper per chore, not a giant platform.\n\nHere is a minimal way to start:\n\n1. List the five things you check by hand after every change (logs, dashboard, deploy status, error tracker, ticket).\n2. Expose each one as a read-only command or [MCP server](https://explainx.ai/blog/what-is-mcp-model-context-protocol-guide) the agent can call.\n3. Add write actions last, one at a time, behind scoped credentials.\n\nThe security caveat is real. An agent that can deploy and email customers can also do both wrongly. Scope credentials narrowly, log every call, and consider a policy layer for risky actions. Our write-up of [Anthropic's red-teaming of auto mode and guardian monitors](https://explainx.ai/blog/anthropic-red-teaming-auto-mode-codex-guardian-monitors-fail-55-percent-attacks-2026) shows why you should not rely on a model-based monitor as your only brake. Teams that want a deterministic gate can look at [AgentBeam](https://agentbeam.com/?ref=explainx), the agent security platform from the explainx.ai team.\n\n## Rule 6: Test whether your agent knowledge actually works\n\nTeams pile up AGENTS.md files, skills, scripts, and docs. Ball asks the uncomfortable question: do agents actually use them? His method is to spawn five blind agents, a control group without the knowledge and a treatment group with it, and compare outcomes. He notes agents are very good at running experiments.\n\nYou can copy this today:\n\n1. Pick a task your docs claim to make easier, such as \"add a new API endpoint following our conventions.\"\n2. Run the task with the knowledge files removed (control) and present (treatment), several times each.\n3. Compare: did the treatment agents follow the convention, finish faster, or use fewer tokens?\n4. Delete or rewrite any guidance that shows no effect.\n\nThis also explains why [agents may need documentation more than memory](https://explainx.ai/blog/agents-dont-need-memory-they-need-documentation-operator-memory-2026): documents are testable, and plugin memory is much harder to evaluate. For the underlying format, see our guide to [agent skills](https://explainx.ai/blog/what-are-agent-skills-complete-guide).\n\n## Rule 7: Local development is the weak point\n\nBall says local dev now feels yucky. Each agent should be able to install and run whatever it needs, which is easy on remote machines and hard on a laptop where agents collide on ports, databases, and caches.\n\nOptions that work today:\n\n| Approach | Strength | Weakness | \n|---|---|---|\n| Git worktrees per agent | Cheap, isolated code | Shared ports and databases still collide | \n| Containers or VMs per task | Full isolation | Slower start, more setup | \n| Remote dev boxes | Scales to many agents | Cost and network latency | \n| Port and database name templating | Works on a laptop | You must build and maintain it | \n\nOur guide to [parallel sessions and worktrees in Claude Code desktop](https://explainx.ai/blog/claude-code-desktop-parallel-sessions-sidebar-worktrees-nested-sessions-guide-2026) covers the first row in detail. If you run several agents side by side, a [local control plane](https://explainx.ai/blog/agentplane-local-control-plane-claude-code-codex-cursor-side-by-side-2026) helps you see which one owns which port.\n\n## Rule 8: Do not iterate with the agent, make it build the iteration tool\n\nThe anti-pattern is \"let's try this... ah no, let's try that.\" Ball's replacement: \"Generate 20 variations and a little page that lets me combine and test them.\" It applies to the solution space and to the problem space: \"Give me 4 theories on why this is slow, then check all four.\"\n\nThe gain is that you stop being the loop. You review a comparison page once, instead of reading twenty chat turns. Examples:\n\n- A design task: ask for 20 variants of a component and a single HTML page with toggles.\n- A performance bug: ask for four hypotheses, a profiling script per hypothesis, and a ranked result.\n- A prompt change: ask for a test set, a runner, and a table of scores per variant.\n\n## Rule 9: Ask for irrefutable proof\n\nAgent sandbox run producing a pass result and before and after numbers as proof of a coding agent change\n\nBall calls this the biggest game changer. Agents are good at producing proof: end-to-end walkthroughs, demo videos, and before and after numbers. His advice is to build a trust instinct for what counts, and to put \"this is not evidence\" in your AGENTS.md.\n\nA snippet you can adapt:\n\n```\n## Evidence rules\n- \"Tests pass\" alone is not evidence. Show the failing test before the change.\n- For UI changes, attach a screenshot or short recording of the real flow.\n- For performance changes, attach before and after numbers from the same machine.\n- \"It should work\" and \"this looks correct\" are not evidence.\n```\n\nThis pairs well with rule 15. The more proof the agent attaches, the less code you need to read line by line.\n\n## Rule 10: Let the agents wait on you\n\nIf you worry about time to first token, Ball says, you are probably doing something wrong. Lean into async. Give agents bigger tasks, be more ambitious, and batch instead of going back and forth. The measure of a good session is how long the agent works unattended, not how fast the first reply appears.\n\nIn practice, this means writing a fuller brief once (goal, constraints, proof required) and walking away. It also means queueing several tasks, which brings you back to rule 7.\n\n## Rule 11: Schedules, wake-ups, and heartbeats\n\nBall did not realize how much he used automation until it was switched off. His examples: \"Check the logs in 2 hours.\" \"Let me know once this is live.\" \"Check every day at 9 am.\"\n\nThese are small instructions with large effect, because they turn the agent from a tool you operate into a colleague with follow-up duties. If your harness has scheduled tasks or a loop mode, use them for three jobs first: post-deploy checks, daily summaries of errors, and dependency or release watching.\n\n## Rule 12: Stop managing context by hand\n\nBall's position: every thought spent wondering whether you are at 300k or 380k tokens is wasted. Compaction works incredibly well. Keep one thread per task. His threads range from 46 messages to 3,714.\n\nContext compression squeezing a long agent thread into a short summary that keeps the task going\n\nResearch backs the direction. Apple's work on [self-compacting agents](https://explainx.ai/blog/apple-selfcompact-self-compacting-language-model-agents-context-2026) shows models can learn to summarize their own history without losing the thread. The caveat: compaction can drop a detail you needed. If a detail matters across the whole task, write it into a file the agent re-reads, not just the chat.\n\n## Rule 13: Threads are company memory\n\nBall's team uses Amp, where threads link to git commits. When someone asks \"why did we do this?\", the thread answers. It also avoids duplicate work because teammates can find what was already tried.\n\nYou can approximate this in any tool: put the thread or session link in the commit message or pull request body, and keep agent transcripts searchable.\n\n## Rule 14: Do not let agents write for humans\n\nBall's rule is not to let agents write for humans, with three exceptions: debugging steps, incident reports, and some docs. The reasoning is that prose written for people carries tone and judgment that an agent cannot own, while mechanical write-ups do not. That is a taste call, and plenty of teams will draw the line elsewhere.\n\n## Rule 15: Review only code with high blast radius\n\nThis is the rule most likely to start an argument. Ball says there are fewer than five central files he reviews, plus database migrations. Closure versus class, a neater type, variable names, and even duplication: he does not care anymore. He reviews only when four answers are yes: does it work, does he understand it at the arrows-in-a-diagram level, did the agent test it end to end, and can he change it in a month.\n\nAn agent hands a finished change across a checkpoint where one reviewer checks the risky parts\n\nTo use it safely, make the blast radius explicit:\n\n| Review by hand | Skim or skip | \n|---|---|\n| Database migrations and schema changes | Variable and function names | \n| Auth, permissions, and payment paths | Closure versus class choices | \n| Public API contracts | Duplicated helper code | \n| The few central modules everything depends on | Internal refactors with passing end-to-end proof | \n\nList your own five files in AGENTS.md so both you and the agent know which changes need a human. The bet only pays off if your test and proof requirements from rule 9 are strong. Without them, \"skip review\" is just \"skip checking.\"\n\n## What people will ask, and our answers\n\n**Is this advice only for people on one tool?** No. Ball works on Amp, and rules 12 and 13 reference it, but the other rules apply to any harness that supports tool calls, long sessions, and scheduling.\n\n**Does it apply to beginners?** Partly. Rules 3, 8, and 9 help anyone. Rules 2 and 15 assume you can already judge what matters in a codebase. A newer developer should keep a wider review net until they can name their high-blast-radius files with confidence.\n\n**What is the risk if I follow all 15?** Concentrated failure. If your proof requirements are weak, a single confident wrong change can reach production. The list trades line-by-line review for outcome verification, so your verification has to be real.\n\n**What is missing from the list?** Cost and security get little space. Running many async agents with write access to production systems raises both. Budget caps and scoped credentials belong next to rules 4 and 10.\n\n## A one-week plan to adopt the list\n\n1. **Day 1:** switch to the newest model, and write three goals as \"what\" prompts with a number and a stop condition.\n2. **Day 2:** add an evidence section to AGENTS.md or CLAUDE.md.\n3. **Day 3:** wrap two lifecycle chores (logs and deploy status) as read-only tools.\n4. **Day 4:** run one control versus treatment experiment on a skill or doc you rely on.\n5. **Day 5:** ask for 10 variants plus a comparison page on a real problem.\n6. **Day 6:** schedule a daily check and a post-deploy check.\n7. **Day 7:** name your high-blast-radius files and write them down.\n\nIf you want to practice this with a mentor and other builders, the [explainx.ai workshops](https://explainx.ai/workshops) cover agent workflows hands-on, including setting up proof requirements and tool access.\n\n## The bottom line\n\nThe list reads as one idea repeated fifteen ways: stop being the bottleneck. Give the agent a goal, give it eyes on your real systems, make it prove its work, and spend your own attention on the few places where a mistake is expensive. The disagreement will be about how far to go on slop and review. Our suggestion is to adopt rules 3, 4, 8, 9, and 10 now, which are low risk, and adopt 2 and 15 only as fast as your proof and tests earn it.\n\nSource: Thorsten Ball, \"How I work with Agents... as of October 2026,\" posted on X on October 25, 2026. Views and figures are from the post at the time of writing; quotes are short excerpts used for commentary.\n\n## Related reading\n\n*Accurate as of October 26, 2026. Model names, tool features, and the original post may change after publication.*", "url": "https://wpnews.pro/news/how-to-work-with-ai-coding-agents-thorsten-ball-s-15-rules", "canonical_source": "https://explainx.ai/blog/how-i-work-with-agents-thorsten-ball-15-rules-october-2026-guide?utm_source=rss&utm_medium=feed&utm_campaign=blog", "published_at": "2026-10-26 00:00:00+00:00", "updated_at": "2026-10-26 07:11:16.680413+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "artificial-intelligence"], "entities": ["Thorsten Ball", "Amp", "Claude Code", "Codex", "Harvard", "Jellyfish"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-work-with-ai-coding-agents-thorsten-ball-s-15-rules", "markdown": "https://wpnews.pro/news/how-to-work-with-ai-coding-agents-thorsten-ball-s-15-rules.md", "text": "https://wpnews.pro/news/how-to-work-with-ai-coding-agents-thorsten-ball-s-15-rules.txt", "jsonld": "https://wpnews.pro/news/how-to-work-with-ai-coding-agents-thorsten-ball-s-15-rules.jsonld"}}