You Have a New Job Title: Agent Manager

Nobody announced it, but your job changed. You used to write code. Now you also manage something that writes code: an AI agent that can read your repository, make changes across many files, run commands, and report back. It is fast, tireless, and eager — and it has the judgement of a brilliant intern on their first day.

That last part is the whole story. Agents do not know when they are wrong. They do not feel the hesitation a human feels before deleting a table or changing an authentication flow. They produce confident output for correct and incorrect work alike, at the same speed, in the same tone. Managing one is therefore not a prompting trick. It is management: scope, standards, verification, and knowing when to intervene.

Rule One: Tests Are the Contract

Before you hand an agent a task, write down what “done” means in a form a machine can check. Usually that is a test. Not a vibe — a test:

# The contract for "fix the discount bug" is not "make it work".
# It is this, and the agent does not get to redefine it:
def test_discount(): assert price_after_discount(100, 10, member=True) == 85 assert price_after_discount(100, 10, member=False) == 90 assert price_after_discount(0, 10, member=True) == 0 # A good agent task starts with the tests already written,
# or with the instruction: "write the failing test first,
# then make it pass, then show me both."

This single habit prevents the most common agent failure: the agent “completing” a task by quietly changing what the task means. If the tests exist before the work starts, success is measurable. If they do not, the agent will optimise for looking finished, which is a very different thing from being finished.

Rule Two: Small Tasks, Named Files, Hard Edges

Agents fail on vague epics and succeed on scoped jobs. Compare these two assignments:

  • Vague: “Improve the checkout flow.” The agent must guess what improvement means, which files matter, and when to stop. It will guess wrong on at least one of those.
  • Scoped: “In src/billing/checkout.ts only, fix the bug where a discount is applied twice when a promo code is re-entered. Add a failing test first, then fix it. Do not change any other file, and do not add dependencies.” The agent knows the job, the boundary, and the proof.

Name the files it may touch. Name the files it may not. Forbid the dangerous moves explicitly: no database migrations, no changes to authentication, no new dependencies, no secrets in code — without your review. An agent that cannot do something harmful without asking is an agent you can actually delegate to.

Rule Three: Review Every Diff, Especially the Ones That Pass

It is tempting to wave through agent work when the tests are green. Resist it. Tests check what you thought to test. Review catches everything else: a validation quietly weakened to make a test pass, a dependency added that nobody vetted, a default changed in a file you did not expect, or a correct-looking solution to the wrong problem.

Review agent diffs the way you would review a new teammate's first pull request: line by line, with questions. Why this approach and not the simpler one? What happens on empty input? What did you not change, and why? The agent can answer those questions well — but only if someone asks. You are that someone.

Rule Four: Know When to Take the Keyboard Back

Three situations call for you, not the agent. First, when the requirements are genuinely unclear: if you cannot describe the task in two sentences, the agent cannot execute it in two hundred steps. Clarify first, delegate second. Second, when the change touches security-sensitive ground — authentication, payments, personal data, or permissions. There, your judgement is the product, and delegating it is not efficiency, it is abdication.

Third, when the agent is stuck in a loop: it has failed the same tests three times with three different guesses. At that point it is not converging, it is guessing, and each guess costs you review time. Stop it, read the failing test yourself, and either fix the test's expectation or do the work directly. The fastest agent session is sometimes the one you end early.

A Workflow That Works

Put together, a healthy agent session looks like this: you write the task and the tests (ten minutes). The agent implements in a branch, touching only named files (its time, not yours). You review the diff line by line and ask two questions about anything surprising (ten minutes). You run the full test suite yourself before merging. Total human time: under half an hour for work that would have taken hours alone — with quality you can defend.

That is the real promise of the AI teammate, and it is less glamorous than the demos: not that it replaces you, but that it makes your judgement go further. Your taste, your tests, and your review are the scarce resources. The agent multiplies them — but only if you stay in the manager's chair.

Try it on a small, safe task first: a bug fix with a failing test, in a browser editor, where you can run the tests and read the diff without touching your main codebase. And if you are setting this up for a team, check CoderFile's Team plan ($19/user/month, or $15/user/month billed annually) for shared, collaborative workspaces. The agent is ready to work. The question is whether you are ready to manage it.