🎯 The Premise
11 easy-to-implement tips to make coding agents more reliable — no workflow scrapping, agent-agnostic, useful whether you're new or have an evolved workflow. "The best guidance comes in the form of simple tips and tricks that have a disproportionately large benefit." 0:00
🔧 All 11 Tips
Agents need specificity and shouldn't make assumptions. Your #1 job is to reduce the number of assumptions the agent makes. Humans can interpret "keep the database code organized sensibly" — an agent needs "all SQL lives in the database/ folder." Be specific on file paths, numbers, and commands.
Because you write so specifically, commands/file paths go stale as the codebase evolves. Stale rules (referencing deleted files, replaced databases, renamed folders) severely confuse the agent. 1 in 4 repos with AI rules have stale rules. Run the rules-check-drift skill to audit your rules against the codebase periodically.
/compact is not worth it.
Smashing a bloated conversation into a summary relies on the agent remembering what's important → hallucination. Only ~10% of specific details survive the summary. Recommendation: give smaller work sets (never reach the point of needing it); if you go too far, write a handoff doc and start a new session — "Slash Compact is a handoff doc you have barely any visibility into."
Rules are probabilistic — an LLM isn't guaranteed to follow them. If something must happen every time (e.g. "run tests after every implementation"), make it a hook, not a rule. A hook triggers deterministically on an event (before a tool, on "done"), runs the tests, and routes failures back: "you said you're done, but go fix these." Anytime you call out a specific event or ordering in a rule, it should be a hook.
Too many rules hurt more than help as models get more capable. Don't tell an LLM "how to write a PR" or "don't repeat yourself" — it bloat. Anthropic recommends <200 lines of global rules (Cole says <300). Keep global rules to project specifics (constraints/conventions that apply always); move the rest to task-specific context files the agent reads on demand.
Fanouts / parallel agents / sub-agents cost way more tokens than you think. Cole's own /usage showed 39% of his weekly limit went to running 4+ sessions in parallel. Claude Code is "way too prone to spinning up dozens of sub-agents without you asking." Sub-agents are great for protecting context — just don't use them too liberally.
Switching to a bigger model mid-conversation (via /model) when the agent is stuck doesn't fix anything — the conversation is already "tainted" with biases and mistakes that carry over. LLMs develop error patterns within a single conversation (prediction machines). Instead: write a handoff doc and burn the conversation to the ground — fresh session, much better results.
Elaborate frameworks with a team lead distributing work and agents messaging each other are not reliable — Claude left "agent teams" experimental for months for a reason. For parallel/scale work: just have your main agent describe what you want in plain English and let it delegate to background agents. "You don't need teammates, a shared task list, or a mailbox. It sounds cool — but it's not how you build production-grade software."
The writer builds up bias and assumptions — it'll say things are great when they're not. Always get a fresh set of eyes: finish in the implementation conversation (run tests), then open a new conversation with a handoff doc and have it review the PR / uncommitted changes. "No bias, no assumptions — or at least a lot less."
Forcing too many iterations degrades quality — the agent finds "corrections" just to appease you. 85% of the time there was an earlier iteration that was far better than the last. "More iterations does not always equal better code." (Especially tempting right before a rate-limit reset.)
Don't make testing an afterthought. Before writing any code, plan the full validation harness: tools for the agent to check its own work, conventions for unit/integration tests, how you'll test after, how to look for edge cases. "Planning those things before you write the code is one of the best ways to make your coding workflows more reliable."
📚 The Studies (referenced in the video)
| Tip | Finding | arXiv |
|---|---|---|
| 1 | Writing for the agent (specificity) | 2608.20195 |
| 2 | 1 in 4 repos have stale rules | 2606.09090 |
| 3 | Only ~10% survives a compaction | 2608.22752 |
| 4 | Compaction erodes safety constraints | 2606.22528 |
| 5 | Less context beats more context (+ no AI config → 2× complexity) | 2606.10209, 2608.25241 |
| 7 | Escalating mid-task recovers < half the gap | 2608.24358 |
| 8 | Naming a coordinator does not improve results | 2608.16801 |
| 10 | 85% had a better answer before the last iteration | 2607.24604 |
| 11 | Where agent reliability actually comes from | 2607.17044 |
🔗 github.com/coleam00/skills (incl. the rules-check-drift skill from tip 2)
💡 Key Takeaways
- Reduce assumptions — write for the agent (specific paths, commands, numbers), not for a human reader.
- Rule drift is real — 1 in 4 repos have stale rules; audit them with a drift-check skill.
- Avoid
/compact— 90% of detail is lost. Use smaller work sets + handoff docs instead. - Hooks, not rules, for anything that must always happen (tests, deterministic checks).
- Less context wins — keep global rules <200–300 lines; the rest goes to task-specific files.
- Fresh sessions beat escalation and over-iteration — a tainted conversation can't be rescued by a bigger model; 85% of runs had an earlier iteration better than the last.
- Validation is a system, planned before code — and the writer never approves its own work.