Ansh Bhalala

< all notes

Notes from running many coding agents at once

, 2 min read. Ansh Bhalala, co-written with AI from my own repos, notes, and session logs.

I use more than one coding agent, and sometimes many at once. These are the habits that have held up.

Route work on purpose

My repos carry an AGENTS.md with an engine guidance table, so I don't decide from scratch each time:

  • Multi-file changes go to Claude Code.
  • Quick single-file fixes go to Codex.
  • Deploys, monitoring, notifications, and schedules go to Hermes, a bot.
  • UI exploration is a human step.

When I'm not sure, I ask Hermes to run a choose-engine routine. The AGENTS.md in doris is public and addressed to all three.

Parallel agents need small inputs

For OpenUmbra, a browser fighting game I'm building, a panel of architect agents wrote 22 design records, and later runs had agents working in parallel git worktrees. All 27 commits carry a model co-author line. The first big design run died because judge agents tried to cat 250 KB of research into their context. The fix was one line in every prompt: grep for what you need, never cat a research folder. Also, keep the laptop awake. Subagents stall when it sleeps.

For the ORRN rebuild, a research run with 102 agents audited the old codebase and weighed a rewrite against adopting Frappe and ERPNext. The rewrite won.

Give a team one memory

My capstone team has four people, some technical and some on the business side. Personal AI memory doesn't help a team, because each person's assistant knows something different. So the memory lives in the repo:

  • A git-tracked memory/ folder is the shared store.
  • Taiga is the source of truth for who is doing what, connected through an MCP server. One catch: its list calls stop at 30 rows unless you pass page_size: 200.
  • Meeting captions, standups, and backlog exports go into memory/sources/, and the summaries go into memory/meetings/.
  • Discord bots answer from that memory, so a teammate can ask what changed without opening the repo.

Keep your own review log

Grok's /implement keeps a log of what its reviews found on an earlier version of this site. The repeat offenders were async handlers with no error handling, server-only values leaking to the client, raw request params used instead of validated data, CSS selectors that didn't match the markup, and README examples that drifted from the real config. A list like that beats a generic checklist, because it's your own failure pattern.

Memory with reasons

The notes my agents keep about me are split by type: who I am, how I want things done, project state, and where things live. Every rule carries a "why" and a "how to apply". A rule without a reason gets applied in the wrong place.

Related projects

More notes