🚀Agents in the service of a project
Concretely, what is an agent good for in a real project? Code review, research, parallel execution, tasks that run on their own. The patterns that change how you work.
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 even formalizes this in a dedicated command, the /review skill, which we cover in Skills. 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, not 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.
Orchestrator agent
splits the task, dispatches, synthesizes
Sub-agent
Research
reads the docs, the web
Sub-agent
Code
writes the feature
Sub-agent
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.
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.
Bound the task
An agent shines on the precise and flounders on the vague. “Redo the frontend” sends it in circles; “add a sort button on the date column, like the one on the name column” puts it on rails. The more framed your request, the better the result. That’s the whole point of Framing a task with an LLM.
Give it the context
The agent doesn’t know your project by heart. Give it the conventions, the pitfalls, the architectural choices, once and for all, in a memory file it rereads every session. See Memory files. A well-briefed agent does in one shot what a blind agent fails at three times.
Choose the right level of autonomy
Sensitive task or kickoff of a session? You validate every move. Reversible refactor covered by tests? Let it run and review at the end. Autonomy is a dial you set according to the stakes, not a switch.
Review the result. Always.
Even when it’s green, even when it compiles. The agent may have “succeeded” at the task by taking a shortcut you wouldn’t have, or by breaking something elsewhere. You remain the last filter. It’s your name on the commit.
Capitalize
What works once and you’ll do ten more times, a quality check, a deployment procedure, a review format, turn it into a skill. You codify the know-how once and for all, and all your future agents benefit. See Skills.