← Back to town

Agentic First

Ashley led our move to building with AI agents: he set the practices, wrote the documentation and skills, and rebuilt our core so agents could work in it. It changed how fast the front-end shipped.

Christo Bezuidenhout, CTO, MoonX
How I run a team of agents I set the direction. A lead agent plans and splits the work. Agents build in parallel, each in its own git worktree, all drawing on the project's rules, decisions and skills. A reviewer with a fresh context checks their changes, a challenger tries to disprove its findings, and the lead merges what holds up into main. Me direction, the big picture Lead agent plans, splits, merges Agent own worktree Agent own worktree Agent own worktree Context rules, decisions, the why, skills loaded when relevant changes Reviewer fresh context, no stake Challenger tries to disprove it what holds up, merged by the lead main

Agents write most of the code. I direct the engineering. These are the rules I work by.

  1. Context matters

    An agent's output is only as good as its input. Give it what it needs and nothing it doesn't: noise waters the context down. Rather than loading everything up front, point it to the right document at the right moment: a conditional reference in CLAUDE.md, a skill file, a lessons file, or a comment in the code that links to the decision behind it.

  2. Write the why down, or the next agent undoes it

    Agents start every session with no memory of the last, so the reasoning has to live in the project: a decisions log for what was decided and why, short notes beside structural code, and every correction written in as a rule. Point agents to them and treat them as binding, and a mistake corrected once stays corrected.

  3. Experiment and iterate

    Code agents are fast, so use it. Try ideas, features and implementations as quick spikes, see what works, measure it, and throw away the rest. A prototype costs minutes now, not weeks.

  4. Run them like a team

    Newer models coordinate well and can work on the same thing at once. It still pays to run them like a traditional team: a lead who plans and reviews, and the others each working in their own git worktree.

  5. Agents review for harmony

    Within their domain, agents review better than people do. A reviewer with a fresh context and no stake in the code reads every line, checks it against the project's rules and decisions, and doesn't tire at line two thousand or wave a colleague's work through. Put a second agent on disproving its findings, and what survives is real. People are still needed for the big picture: whether this is the right thing to build, and where it's all heading.

  6. Green tests don't mean done

    Passing tests only say the code does what the tests ask. Architecture and code quality need assessing too. Agents fall into bad architecture as easily as people do, and then they amplify it: every new change copies the pattern it finds.

  7. Give agents eyes and hands

    Agents can perceive and judge far more than you might think. Give them the tooling to see, run and understand what they're building: screenshots, logs, inspection tools, a harness that drives the running product. Then you stop babysitting the output.

  8. Slow is a signal

    If an agent isn't getting a task done quickly, either the task is badly framed or something has gone wrong. Stop and find out which. No amount of "just fix it", or waiting, will get you there.

  9. Make the codebase legible to agents

    One obvious way to do each thing, one data spec, small files, and layering enforced by tests. An agent that can find its way around a codebase won't reinvent it.

  10. Silo your agents

    Don't let them run wild. Left alone, they burn time and tokens on things like running the whole test suite for every line they change. Scope what each agent can touch and run, and orchestrate the rest.

  11. Adoption is onboarding

    Shared skills, docs and scripts the whole team builds on, and colleagues coached to write their own. A team takes on agents the way it takes on a new hire: by teaching them how things are done here.