Engineers dodged managing people, but couldn't dodge managing agents

Addy Osmani wrote an article titled “Your Coding agents made you a manager.” After reading it, Viking's take was blunt: engineers' daily work is shifting toward management. Some people originally chose the IC path precisely to stay closer to code, have fewer meetings, and be chopped up less by the calendar. Now the calendar isn't full—but the task queue is.

A commenter put it more wickedly: question the manager, understand the manager, become the manager.

Spend every day with agents, and you're already managing

Addy's core claim is that if someone works with coding agents all day, they're already doing management: choosing tasks, writing instructions, delegating, following up, evaluating results, and deciding what ships. The people who get dramatically different results from agents aren't necessarily the flashiest prompt writers; they're often the ones who learned management earlier.

Management here means producing good outcomes by making other people's work go smoothly. It doesn't require becoming the kind of manager whose calendar is packed with meetings. Addy also doesn't claim agents can replace managers or colleagues.

One line of his hits hard: every complaint you have about a bad manager is a bug report for working with agents. Vague handoffs, missing context, shifting expectations—none of these old problems are absent with agents. The difference is that you used to be the person receiving work; now you're the person assigning it.

First, give the agent a way to check itself

Addy puts this first. The best practice is to give the agent a mechanism for verifying its work—a test suite, build, linter, screenshot—and to make it present the results as evidence. The anti-pattern is nodding when something “looks done.” That turns you into the agent's test suite, with all the errors piling up until you have time to notice.

Experienced managers don't confirm the team is doing well by reading every line of code; they rely on guardrails: CI, code review, dashboards, on-call. A manager without guardrails becomes the bottleneck within a quarter. The same goes for agents. An agent stops when the work looks complete. Without verification, “looks complete” is its only acceptance criterion.

Claude Code's docs put it more plainly: give Claude a check that can produce pass or fail. Tests, build exit codes, linters, scripts that compare fixtures, browser screenshots—any of these work. When such checks already exist in the repo, the most useful line in CLAUDE.md is the command to run them.

There are several ways to put this into your workflow: require the agent in the prompt to run the authentication tests before continuing; use /goal to set a condition so an independent model checks every round; use a Stop hook to block the turn so it can't end until typecheck passes; or use /code-review to hand the diff to a fresh subagent that hasn't seen the conversation. Authors don't approve their own PRs, and neither should the code an agent writes.

One detail worth remembering: ask a reviewer to “find problems,” and it will always find some. Ask it to “find problems that affect correctness and skip style,” and it will converge. The same is true when a good manager asks for feedback: the clearer the scope, the less rework.

AGTP's tweet calls this kind of practice harness engineering: rather than only changing prompts, build a whole system around the agent. That framing lines up with Addy's article. The focus shifts from “which model to choose” to “how to make agents reliable.”

Explain what the agent can't see

Addy suggests giving the agent a summary of things it can't infer by looking at the repo itself: the task goal, why it matters, constraints, out-of-scope items, and success criteria. The anti-pattern is dropping in a one-line task while keeping the real expectations in your head, or writing reams of things the agent could discover by reading the code.

He gives an example. Rewrite “make the dashboard faster” as: make p95 load time for the /team dashboard for organizations with 10k+ members under 2 seconds. Why: enterprise admins open it every day, and slow loading is the biggest source of support tickets. Constraints: don't change the schema; keep the API response structure. Out of scope: UI changes, full-page caching. Check: run scripts/perf/team.sh and provide before/after numbers.

The management concept behind this is called commander's intent in the military and context, not control at Netflix. In plain language: tell the other party what outcome to achieve and where the boundaries are; don't grip every step.

If you haven't thought the task through yet, Addy offers a very practical approach: have the agent interview you in reverse until it can write a spec, save the spec as a file, then start a new session to execute it. That spec can also be used for review later.

If the same correction shows up twice, codify it

Addy's advice is that if you correct the same thing more than once, write it into the team's CLAUDE.md or turn it into a shared skill. Recheck after a while to see whether new models still need those corrections. The anti-pattern is manually fixing it again in every session, or relying on hidden knowledge that exists only on your machine.

CLAUDE.md should stay short. Suitable content includes: how to verify things and exact commands; places in the code that are easy to misread; decisions that aren't in the repo; and things you've corrected twice.

This is easy for ordinary readers to understand too. Agents haven't been on the team; they don't know why a proposal was rejected in last week's meeting, and they don't know whose head the deployment process lives in. Writing these things down saves the next session from rediscovering them.

Default to letting it decide; hard-code only what absolutely cannot bend

Addy cites Andy Grove's task-relevant maturity: the level of supervision should depend on the person's track record on the specific task, not on their overall ability. Applied to agents, most of the time you should let them judge for themselves; only the few things that must always happen or must never happen should be enforced with hooks, deny rules, and managed settings.

Claude Code's docs split this clearly. Prompts, CLAUDE.md, and skills are non-deterministic instructions: the model reads them, considers them, and usually follows them, but there's no guarantee. Hooks, deny rules, and managed settings are deterministic rules: the harness enforces them every time, regardless of what the model thinks.

The anti-pattern is a screen full of all-caps rules, hooks for preferences, and old habits kept around for things new models learned long ago. Addy puts it sharply: for agents, excessive process is the new micromanagement.

Plan first, then let it write

Addy suggests setting a plan before the agent starts coding, reading the plan for underlying assumptions, and splitting work into non-overlapping parallel tasks. The anti-pattern is multiple agents working on overlapping tasks at the same time, then spending the afternoon resolving merge conflicts and duplicate decisions.

A good process is to enter plan mode first, iterate on the plan until it's right, then delegate the coding. When the plan is good enough, the model can often build it in one pass. For large tasks, you can open a second session and have another session look at the plan like a staff engineer doing a design review. Design review is the cheapest place to catch going in the wrong direction.

Correct early, restart fast

Addy's advice is to watch the first minute and correct the agent as soon as it goes off track. If you've already tried to correct it twice and failed, start a new session and write a better prompt. The anti-pattern is continuing to patch it a third and fourth time—what you're patching is the request itself.

This analogy is very managerial. If a capable person keeps getting the same thing wrong, the problem may be upstream: instructions, context, scope. The agent version is more direct. If it goes off track, press Esc. If two corrections don't fix it, clear the session and write the lessons learned into a new prompt. A third correction mostly just makes the model read more failure logs over and over.

Capabilities like /rewind are still changing the cost of trial and error. When rollback is cheap, you can try bolder approaches first and back out if they don't work. Good managers do this with employees too: when mistakes are reversible, give people some room.

Tasks can be delegated; judgment cannot

Addy draws the boundary clearly: agents do the work; humans decide the important things—product judgment, security boundaries, what ships. Treat every diff as a change you'll be paged for. The anti-pattern is approving a huge diff because tests are green and the naming looks reasonable. That isn't code review; it's code ratification.

In the article he admits he almost fell into it. He had an agent research competitor gaps and write a local PR to close them. He read the research, skimmed the code, and almost pushed a batch of changes that added complexity for users with very little benefit. The work had been delegated, and the decision almost got delegated along with it. A 600-line diff, reasonable naming, green tests—it's too easy to click approve.

A more reasonable division of labor: agents handle styling, lint, post-review follow-ups, common bugs, and unit tests; humans handle security boundaries, compliance, and product decisions. Coordination is the same. Agents can track handoffs, but choosing between competing requirements still has to be decided by humans.

Humans don't need to be in the inner loop of every change. What must be protected is the outer loop: what the constraints are, how much of the output you actually read, what evidence you keep, and what must be signed off by a human. Keep changes as small as possible; the unit of review is the unit of understanding.

Design a run that doesn't need you present

Addy lists five questions for unattended tasks: Does it know what done looks like? Does it have a self-check mechanism? What are the boundaries? What can make it stop? Where does the output go, and who approves it?

These five questions are almost identical to what a good manager would ask before giving a senior engineer a project and going on vacation. Goal conditions, a spec file, a failing test that must go green; a test suite, Stop hook, review step; permission controls, sandbox, worktree, push-only branches; turn limits or spend limits; a PR or summary, plus human approval for irreversible operations.

When scaling the number of agents, verification capacity needs to scale with it; attention should not. Addy mentions an orchestration tax: beyond the first few agents, every additional one demands more attention. Most days he runs four or five background agents and a few local sessions; some days that's already too many. More monitoring won't save scaling. Only letting the system monitor itself frees up humans to make decisions.

Measure the system, not just activity. PR cycle time, ramp-up time for new hires, and the frequency of reverts and rework are more meaningful than “what percentage of code was written by AI.” Grove's countermeasure rule applies too: if you measure merged PRs, also measure rollbacks and rework.

AGTP also mentions a double-refund case: Agent A hands a refund to Agent B, B's API call succeeds but times out before reporting back, and A retries. Without an idempotency key, the customer gets refunded twice. Both agents pass their own evaluations; the bug exists only in the interaction. This kind of problem shows that verification can't just check whether a single agent “finished”; it also has to look at system boundaries and retry semantics.

Decide what not to do

Addy says a manager's most important word is often no. With agents, saying no is harder. Starting work is almost free; before lunch you can throw every seemingly viable idea into a PR. Then the team ends up with a pile of PRs that need review, security checks, support, and maintenance. Review and verification become the scarce resources.

The old questions matter more now: Who wants this? How do we measure success? When do we stop? If building is cheap, the hard question shifts from “Can we build it?” to “Should we build it?”

Where the analogy breaks down

Addy doesn't present agents as a drop-in replacement for junior developers. He lists the boundaries: managing people is harder, and the skills don't transfer in reverse; rework is nearly free, so you can have a person and an agent work on two or three approaches at the same time and compare; agents have no experience, only a notebook, and automatic memory is stored on only one machine; agents are more eager to agree, people tend to over-trust them, and you can ask them to rebut their own answers; you have only one agent archetype, and it changes every few months as models update; the fundamentals of training junior developers still have to be done by humans; human teams still matter—don't manage agents so much that you squeeze out the time to build the team.

No title required

Addy's ending is calm. Good staff engineers have always done these things: write design docs, set context, review carefully, and make the people around them better. Agents let every engineer practice these from day one, with feedback in minutes and reversible mistakes. The work is shifting from writing code to making good code have a reason to be written.

It's fine not to want to be a manager. Engineers who use agents well will have to learn management along the way.

You can start with a few moves: give every task a runnable check; tell the agent what it can't see; discuss the plan before writing code; when the same correction appears twice, record it in CLAUDE.md; after two failed corrections, start a new session; and when reviewing a diff, assume you'll be paged for it.