Agents in the service of a project

You know what an agent is and how it loops. But as long as we stay at “it wrote me a function”, we miss the point. The real click comes the day you stop seeing the agent as autocomplete++ and start seeing it as a teammate you point at a bounded task. Then it’s no longer a gadget: it changes how you work. And all the value rests on a few patterns: ways of using it that we’ll go through one by one.

Four ways to use it day to day

An agent isn’t one thing. It’s a role you assign to it. Depending on what you ask, the same tool becomes four different teammates.

The doer

The daily bread. You describe a feature in plain English, “add an endpoint that returns the 10 latest articles, with pagination and a test”, and the agent implements it: it reads the existing code to align with your conventions, writes the function, writes the test, runs it, fixes if it breaks. You, you review the diff. You’ve gone from “the one who types” to “the one who validates”. It’s 80% of your usage, and that’s already huge.

The reviewer

This one we forget too often. Instead of asking the agent to write, you ask it to review: it takes your diff and goes through it with a fine-tooth comb, logic bugs, a secret forgotten in a commit, a silent regression, an unhandled edge case. It’s a tireless second pair of eyes, one that never gets weary at 6 p.m. on a Friday. Claude Code ships this out of the box, nothing to install: /review (an alias of /code-review) goes through the current diff looking for bugs, and /security-review combs your branch’s changes for security flaws, injections, authentication, data exposure. We cover the method in Review, audit, secure. A dedicated reviewer catches what your eye, tired from writing the code, no longer sees.

The researcher

“Where is authentication handled in this project?” “How does this lib actually do its caching?” Instead of opening 40 files by hand, you send an agent to dig, your codebase, the docs, the web, and it brings back the answer, minus the pile of files. It’s an explorer that reads fast, keeps the essentials, and summarizes them for you. You keep your focus for deciding, it does the grunt work.

The cleaner-upper

Renaming a variable across 60 files. Migrating from an old API to the new one everywhere. Updating dependencies and fixing what breaks. These tasks are repetitive, mechanical, mind-numbing for a human, and perfect for an agent that doesn’t tire and doesn’t skip a line out of distraction. You describe the transformation once, it applies it everywhere, methodically.

Multi-agent: divide to rule better

For a small job, a single agent is plenty. But on a big undertaking, auditing a whole codebase, leading a deep migration, a single agent eventually chokes: its context fills with a thousand details, it loses the thread, it confuses files. The answer is orchestration. A lead agent splits the work, delegates pieces to several sub-agents that work in parallel, each with its own clean context, then gathers their feedback and synthesizes.

Lead Orchestrator agent splits the task, dispatches, synthesizes

delegates in parallel

• Sub-agent 1 · its own context Research reads the docs, the web
• Sub-agent 2 · its own context Code writes the feature
• Sub-agent 3 · its own context Review hunts for bugs

Each has its own context: more work done without saturating a single window.

Why is this better than one big agent? Three concrete reasons:

• Clean context per task. The sub-agent looking for where auth lives doesn’t need to know how rendering is done. Each one keeps a clear head, focused on its piece. No pollution, no confusion.
• Parallelism. Three sub-agents combing through three corners of the code at once is three times faster than one waiting in line. On an audit, that counts.
• Cross-checking. A sub-agent verifying another’s work means fewer mistakes. The code goes through one head, the review through another, exactly like a real team where nobody signs off on their own work.

This is precisely how a workflow (or a “fleet”) of agents tackles a security audit or a big migration: an orchestrator, specialists, a synthesis. Claude Code ships a ready-made pattern for it: /batch followed by an instruction studies the codebase, splits the change into independent units, shows you the plan, then launches one sub-agent per unit, each in its own git working copy (a worktree).

Agents that run on their own

So far, you launch the agent and you wait. But an agent can also run in the background or on a schedule, without you sitting there. An automatic PR review every morning before you arrive. A tech watch that summarizes the day’s news. A monitor that watches a service and pings you if it goes off the rails. This is where the mini-machine truly comes into its own: a small PC that never sleeps, with an agent working while you live your life. We dig into all this in the next guide, for now, just remember it’s possible.

How to use it well

The patterns are the what. Here’s the how, five reflexes that make the difference between an agent that helps you and one that wastes your time.