Programmers Dodge Management Roles—Then Coding Agents Push Them Back

Addy Osmani wrote a long post with a direct theme: your Coding Agent has turned you into a manager.

Many engineers choose a purely technical path precisely to avoid writing weekly reports, sitting through long meetings, and managing people. But on day one with a Coding Agent, the job changes: choose tasks, write context, define acceptance criteria, review code changes, decide what can ship. Less typing, more management actions. As Addy puts it, the engineer's core job shifts from writing code personally to making good code happen.

For readers who don't write code, think of a Coding Agent as an AI tool that can read a codebase, edit files, run commands, and open merge requests. It moves fast, but it can't read minds, and it won't take on shipping risk for you. That's why management actions become critical: tasks must be clearly specified, acceptance must be runnable automatically, and review must genuinely understand the changes.

Addy condenses the high-leverage lessons into five points, plus a few extra rules for long-running tasks and concurrency. The original link is at the end.

Highest Leverage: Give the Agent a Self-Verification Loop

The most valuable rule is to have the Agent verify its own work. Give it test cases, build commands, lint rules, or screenshot-based acceptance criteria; let it run, see failures, and fix them itself. Without self-check guardrails, you become the system's bottleneck: the Agent says “looks done,” and you're left acting as a human test machine.

Addy's post mentions an example from the Claude Code best-practices docs: reduce the p95 load time of /team dashboard to under 2 seconds for organizations with 10k+ members; constraints are not to change the schema and not to touch the UI; the check script is scripts/perf/team.sh, and it must show before-and-after numbers. With the task goal, constraints, non-goals, and acceptance method all written clearly, the Agent has a chance to close the loop itself.

Claude Code also offers several ways to tighten verification. You can use /goal to have another model check conditions after each round, which suits long-running background tasks. A Stop hook can block the turn until typecheck passes. /code-review hands the diff to a new sub-agent that has not seen the current conversation. The idea isn't complicated: automate verification actions and reserve human attention for judgment.

One developer replied that the most valuable of the five is the self-verification script: if you assign a task without test cases and acceptance criteria, you still have to re-verify what the Agent delivers—so the task was assigned for nothing.

After Two Failed Course Corrections, Hit Esc and Reset

When you see the model going off track, hit Esc immediately to stop it. If you correct it twice in a row and the model still doesn't understand, don't open a third debate. Clear the session and rewrite a clearer prompt. A third correction often just adds noise to an already noisy history context.

This applies to ordinary users too. If you've gone three rounds with AI and are still stuck in place, it's usually not that it suddenly got dumber—the earlier context has become polluted. Starting over with clear goals, constraints, and acceptance criteria is cheaper than continuing to argue.

Orchestration Tax: Running Five Agents at Once Is Not 5x Output

Running Agents concurrently is not a case of more is better. Beyond three to five, every additional agent exponentially cannibalizes your review attention. Addy calls this the orchestration tax. Most days he runs four or five background agents plus a few local sessions; some days that's already too many.

The solution isn't to watch more closely; it's to delegate monitoring to self-evaluation, goal checks, and reviewers with fresh context, while reserving human attention for architectural decisions. Without a centralized view and notifications, relying only on polling will quickly leave you drowning in sessions.

Code review also must not become rubber-stamping. Tests all green, reasonable naming, and files that look normal do not mean you understand the logic. Approving without understanding the logic leaves the review action intact while cognition has already surrendered. Addy gives an example from his own work: he had an Agent research competitor gaps and write a local PR. He read the research and skimmed the code, and nearly pushed a pile of changes that added complexity for little benefit. The work was delegated—and judgment almost got delegated along with it.

Turn Corrections into Institutional Memory

If the same mistake appears more than twice across different tasks, write it into CLAUDE.md or package it as a dedicated Skill. Turn corrections in one person's head into system rules that every agent can inherit. Keep CLAUDE.md short; it's a good place for things like: how to verify, which areas of the code are misleading, decisions that do not exist in the repo, and things that have already been corrected twice.

One commenter said managing Agents is like managing people: what's often missing is acceptance criteria; instructions are less scarce. Give sub-agents fixed roles and have them debate against the spec first; humans only check whether the argument hits real risks. Writing judgment into the process is more useful than adding another prompt.

Keep Soft Suggestions and Hard Constraints Separate

Prompts, CLAUDE.md, and Skills are requests; the model can consider them and decide what to do. Hooks and Deny Rules are requirements that must be enforced. In most cases, let the Agent look at the real code and use its own judgment. Only for non-negotiables like “never modify generated clients” or “must run the license-header script” should you impose hard constraints.

Addy also warns that old habits should retire. All-caps instructions, “think harder,” and “don't be lazy” tend to cause over-execution and overwork on current models. Excessive process is the new micromanagement.

Plan First, Then Let the Agent Act

Enter plan mode first, iterate the plan until it's right, and then delegate the coding. When the plan is right, the model can often finish in one pass. For large tasks, open a second session to do a design review like a senior engineer, focusing on underlying assumptions.

Task decomposition must also avoid overlap. Claude Code's /batch can split a large mechanical change into 5 to 30 tasks, run them in separate worktrees, and open one PR per task. Humans only need to check whether the slices overlap and whether shared interfaces are landed first. Five Agents taking overlapping tasks will not produce 5x output; it will produce a merge conflict with five authors.

Long-Running Tasks Should Be Designed So They Don't Need You Watching

Before deploying autonomous tasks, define completion criteria, self-verification mechanisms, boundaries, guardrails, and human approval points. Don't start a long-running task before bed without a stopping condition and wake up to find the model has worked all night on a wrong premise.

The questions to answer are very managerial: Does it know what “done” means? Does it have a verification mechanism? Where are the boundaries? What is the turn or cost limit? Where does the output land, and who approves irreversible operations? Pilot on three files first, watch the first few runs, and then let go.

What Should Scale Up Is Verification, Not Attention

The number of Agents should scale together with review capacity. PR cycle time, rework frequency, and rollback count are more useful than “how much code AI wrote.” If you measure the number of merged PRs, you must also look at reverts and rework.

Addy also acknowledges the limits of the management analogy. Managing people is harder, and the skills do not transfer back. Agent rework is nearly free, so you can compare two or three technical approaches in parallel. Agents have no experience, only notebooks, and memory is not automatically passed to colleagues. Agents are more obedient, and people are also more likely to over-trust them. Human teams still matter—don't spend all day managing Agents and squeeze out time for building the team.

Programmers don't have to want to be managers. But engineers who use Coding Agents well will most likely learn management in their day-to-day development: provide context, define completion criteria, set checkpoints, review key changes, and decide what not to do. The title may be missing, but the full set of management actions is already there.

Addy Osmani original article: https://x.com/i/article/2118901185377964033

Referenced tweet: https://x.com/addyosmani/status/2119332146485891501

Main post link: https://x.com/AYi_AInotes/status/2119462929682579610