Teach Your Agents to Manage Up

Getting out of "review everything" hell.

AI agents can now build sophisticated apps that are usually correct. But for production software, “usually correct” isn’t good enough.

“Usually correct” is good enough for small vibe-coded apps, throwaway internal tools, personal projects, prototypes, and low-risk things like games. So for that kind of work, we are seeing massive increases in productivity.

But critical production code needs to not have security bugs. It needs to not lose data. It needs to not break the UI in embarrassing ways. It needs to not cause weird real-world consequences. And it needs to still be maintainable six months from now.

A lot of teams respond to this by putting humans in the loop for everything. Every plan gets reviewed. Every line of code gets reviewed. Every tool use gets reviewed. Every decision gets reviewed. Every possible source of risk gets routed through a human just in case.

This sounds prudent. But it also turns human attention into the bottleneck that prevents you from getting full value from AI.

That’s a big part of why the productivity story looks so different depending on who you ask. On one end, vibe coders are producing entire apps from a single prompt. On the other, production teams often report gains ranging from “maybe 2x on a good day” to “honestly not much.”

Worse, this review-everything approach isn’t even particularly effective.

Humans are bad at reviewing large volumes of mostly-correct output. We skim. We rubber-stamp. We go approval-blind. We spend time nitpicking harmless details and miss the one issue that actually matters. A lot of modern code review has quietly become a game of “let me Claude that for you.”

So if “review absolutely everything” doesn’t scale, and “just let the agents do whatever” is not acceptable, what should we do instead?

My answer is: teach your agents to manage up.

Don’t ask humans to make thousands of tiny decisions. Ask agents to handle the low-stakes work autonomously, and to bring humans the high-stakes decisions with the right context, in the right format, for the right person.

That’s what good employees do when they’re working well with senior leadership. They don’t just dump a pile of raw facts on someone and say “please decide.” They package the decision. They explain what matters. They identify the tradeoffs. They show the relevant evidence. They flag what’s reversible and what isn’t. They make it easy for the human to spend attention where attention actually matters.

In the world of AI, humans increasingly play the role of senior leadership. And that means your agents need to learn how to manage up.

---

The goal is not to remove humans

Let me be clear about what I am not arguing.

I am not arguing that we should let agents do whatever they want and just accept the risk. I am not arguing that production software no longer needs careful oversight. I am not arguing that humans are obsolete. I’m arguing for something much more practical:

Human attention is expensive. Agent computation is cheap. So we should spend human attention where it has the highest leverage.

If a decision is high-stakes - big impact, hard to undo, legally sensitive, security-sensitive, likely to affect users in important ways - then humans should absolutely be involved, and they should pay real attention.

If a decision is low-stakes - small impact, easy to reverse, low blast radius - then the default should be to let the agent do what it thinks is best, while keeping enough traceability that humans can inspect and correct things later if needed.

The mistake is treating every decision like it deserves equal human attention. If everything is important, then nothing is important. If every code change, every test run, every tool invocation, every minor design choice, and every refactor gets escalated to a human, then the genuinely important calls get buried in a haystack of noise.

The whole game is to take human attention away from the things that don’t matter, so it can be focused on the things that do.

---

What “manage up” means in practice

In practice, “teach your agents to manage up” means a few things.

1. Escalate decisions, not raw output

Don’t make a human manually inspect everything an agent did. Make the agent figure out what is actually worth asking about.

A good escalation should answer questions like:

• What decision needs to be made?

• Why does it matter?

• What are the realistic options?

• What tradeoffs do those options involve?

• How important is it to get this right?

• How easy would it be to recover if we get it wrong?

• What context from the codebase, product, team history, or prior discussions is relevant?

• Which humans, if any, should be consulted?

Don’t just ask a human “which of these should I do?” Show screenshots. Compare with existing patterns in the codebase. Explain how competing products solve similar problems. Mention prior attempts. Surface relevant architectural constraints. Say whether the choice is reversible.

If you want good human decisions, do the work to make good human decisions easy.

---

2. Remove humans from low-stakes loops

A huge amount of human time gets burned on tiny acts of babysitting.

Run this command. Click through this UI. Check whether the page looks okay. Copy this data. Re-run that test. Approve this harmless thing. Confirm this action in a sandbox. Paste the result back in.

If a human keeps finding themselves doing some small repetitive thing for an agent, that is usually a sign that the workflow is broken.

Don’t manually click through the app to test it. Have an agent assemble a screenshot-illustrated walkthrough, and check the result itself before showing it to you.

Don’t manually approve routine tool use. Run the agent inside an isolated environment where it can do what it needs to do safely, or use one agent to check the safety of actions done by another.

Don’t make a human provide data that an agent could fetch, derive, or validate itself.

Don’t make a human sit in the loop just because the workflow hasn’t yet been improved.

A lot of the productivity gain from agents doesn’t come from getting them to write code faster. It comes from getting humans out of low-risk loops.

---

3. Turn repeated review comments into rules

If a human notices a bad pattern in code, they should not have to point it out twice.

The first time a reviewer says “don’t do this,” that might be feedback. The second time, it should probably be a lint rule, a test, a validator, a codegen constraint, or some other automated check.

One of the most wasteful patterns in software development is humans repeatedly spotting the same classes of mistakes. This was already wasteful with human developers. With agents generating much larger volumes of code, it becomes unmanageable.

Move from nit-pick review to automated enforcement. If you don’t want giant functions, enforce that. If you don’t want direct database access from certain layers, enforce that. If you want every new feature to come with tests, enforce that. If you want every file to start with a structured comment explaining what it does and how it works, enforce that too.

A human should never have to point out the same bad habit forever.

---

4. Invest aggressively in verification

Building reliable software with agents requires lots of verification.

That sounds expensive. It is. But the key point is that much of this work can itself be done by agents.

You need tests. You need static checks. You need validations. You need environment isolation. You need policy enforcement. You need workflow constraints. You need automated review. You need regression detection. You need tools that catch subtle drift between intent and implementation.

Fortunately, agents are very good at building verification systems.

If your agents are generating a lot of code, then go a little wild on validators. Write custom linters. Write structural checks. Write comparison tools. Write tests that would have felt too annoying to build manually. Have agents build tools that inspect other agents’ work.

This is one of the biggest mindset shifts. The answer to “how do I trust agents more?” is often not “have humans manually check more stuff.” It’s “build better systems that make bad output harder to slip through.”

---

5. Ask agents what was hard

One of the most useful questions you can ask an agent is: what part of this task was difficult or confusing?

Agents are often surprisingly good at explaining what they struggled with.

Sometimes the answer reveals ambiguity in the requirement. Sometimes it reveals missing documentation. Sometimes it reveals a weak test setup. Sometimes it reveals that the workflow is forcing the agent to do something in a painfully inefficient way. Sometimes it reveals that the agent really needs a better tool.

And when you discover that a better tool is needed, you can often just spin up another agent to build it.

I’ve had agents build tools for themselves that compare rendered HTML against a Figma design and identify where they differ, tools that compare abstract syntax trees for equivalent Rust and C implementations, tools for doing large-scale code transformations, and various tools for validation and test generation.

Agents are bad at some structured algorithmic tasks, but they are often very good at building tools that handle those tasks, and then using those tools.

---

Agents are good at bureaucracy humans hate

A lot of best practices that humans resist become much more viable when the labor is mostly being done by agents.

For example, when I work with agents, I typically require that:

• every file starts with a comment explaining what it does and how it works

• every folder has a README describing the purpose of the folder and the files inside it

• documentation gets updated alongside code changes

• tests are thorough

• coding conventions are strict

• validation is comprehensive

Human developers often hate this kind of thing, and for understandable reasons. A lot of it feels like bureaucratic overhead. It slows them down, it’s annoying to maintain, and they know they’ll get blamed when the docs drift anyway.

Agents do not care. They will happily do the busy work. And that changes the economics of software quality.

If good documentation makes future agent work more reliable, then it’s worth demanding lots of documentation. If ultra-strict conventions make code generation safer and refactoring easier, then it’s worth enforcing them. If 90%+ test coverage would have created too much friction for a human team, but agents can generate and maintain the tests, then it may suddenly make sense.

Human developers tend to push back on bureaucracy because their time is precious. Agent time is much cheaper, and the tradeoff is different.

---

Let low-stakes design decisions be wrong

One of the weirder things about working with agents is that it often changes how much effort it’s worth spending on upfront architecture.

With human developers, bad early architecture can be very expensive. Refactoring later is painful, slow, and politically annoying. So it often makes sense to spend real human effort trying to get the design right before implementation begins.

With agents, the economics shift.

Getting the architecture right in advance often requires a lot of expensive human attention. Refactoring later can often be done surprisingly cheaply by agents. So for many projects, it is actually better to let agents make some low-stakes design choices that may turn out to be imperfect, as long as those choices are easy to revisit.

This does not mean architecture stops mattering. It means you should distinguish more carefully between:

• architectural choices that are high-stakes and hard to undo

• architectural choices that are low-stakes and cheap to refactor

For the first category, involve humans early and seriously. For the second, let agents move faster.

A useful pattern here is to have agents maintain a log of design decisions they’ve made. Humans can review that log periodically without forcing every individual choice to block progress.

Again: the point is not to eliminate oversight. The point is to stop spending blocking human attention on every reversible choice.

---

Separate the builder from the reviewer

As with people, it’s generally a bad idea to let an agent review its own work.

An agent that built something has access to its own internal reasoning about why it thinks the thing is correct. That may sound good, but it often makes review worse. It knows what it meant to do. It knows the argument it was trying to follow. It may glide past flaws because those flaws are entangled with the assumptions it already made.

Review is usually better when it is done by a separate sub-agent. Better still, use a different prompt, a different context window, or even a different model family entirely. Treat review as an adversarial or at least independent function, not a ceremonial one.

That doesn’t mean the reviewer agent will be perfect. It won’t be. But independent review is usually meaningfully better than self-review. And humans should still periodically sample what’s going on.

Management by walking around applies here too. Even if most workflows are automated, it’s healthy to periodically inspect random examples of agent output and verify that reality matches your assumptions. Systems drift. Incentives get weird. Validators have blind spots. Agents find loopholes. Random audits matter.

---

Yes, this shifts work rather than eliminating it

It would be nice if the story here were “agents remove work”. That is not really the story.

What actually happens is that you reduce some forms of manual review, but increase the amount of infrastructure, tooling, workflow design, prompt design, validation, and automation around the work.

That is real work. It can be substantial work. In some cases it may even exceed the work you were trying to save. But there’s a crucial difference:

more of this work can itself be done by agents.

That is what makes the tradeoff interesting.

We are shifting effort away from “human stares at a giant pile of code” and toward “agents and tools produce systems that make giant piles of code safer to generate”. That doesn’t make the problem disappear. It changes the shape of the problem into one that is much more compatible with what current models are good at.

---

There will still be moles to whack

None of this is magic. There are bumps.

I’ve had cases where I burned a huge amount of agent tokens building something, only to discover it was based on a false premise and had to be thrown away.

I’ve had validators that I thought were enforcing 90% test coverage across the board, when in fact they only covered a subset of files.

I’ve had agents quietly disable tests that their own changes caused to fail.

I’ve had agents dump ridiculous amounts of functionality into one giant function.

I’ve had agents add hacky special cases to satisfy tests even though the underlying algorithm was still wrong.

To some extent, coding with agents out of the loop is a game of whack-a-mole. You run the system. You notice a class of failure. You add validation or tooling to prevent that class of failure. Then you repeat.

Realistically, you will probably never eliminate all the moles. But that’s true of human teams too.

The real question is not whether the system is perfect. The real question is whether the combination of speed and quality beats the alternative. Can you get to a point where the system, with all its validators and sub-agents and weird little guardrails, produces better results than a more manual workflow with more direct human involvement?

For at least some codebases, I think the answer is increasingly yes.

---

From building to sculpting

One metaphor I’ve found useful is that this style of development feels less like building and more like sculpting.

When you build something in the traditional sense, you assemble it piece by piece. You start small and add carefully chosen bricks one at a time.

When you sculpt, you start with something much larger and rougher. Then you use tools to gradually shape it into what you actually want.

AI makes it very easy to produce a lot of code quickly. But raw code volume is not the same thing as good software. The job becomes shaping that code: making it secure, maintainable, well-tested, comprehensible, and aligned with the actual requirements.

That is a different style of work.

Not every project wants this. Some projects are too simple for the overhead to be worth it. Some projects have compliance constraints that make the workflow unattractive. Some environments make field updates difficult enough that reversibility can’t be assumed.

But for a lot of modern software, I think sculpting is closer to the right mental model than hand-placing every brick.

---

This workflow needs better tools

Once you start working this way, regular IDEs start to feel oddly mismatched to the job.

Most IDEs assume one developer, working on one thing at a time, manually verifying correctness as they go. That is not the workflow we increasingly want.

I want multiple agents running in parallel. I want work broken into many concurrent threads. I want humans acting more like sculptors, editors, and decision-makers than line-by-line approvers. I want important escalations to be surfaced clearly. I want routine workflows compressed into one-click actions. I want agents to move through structured processes without needing constant babysitting.

I tried a bunch of setups for this: multiple full-screen VS Code windows, a forest of terminal tabs, various hacked-together workflows. They all kind of worked, but they required way too much effort to keep track of what all the agents were doing and to steer them effectively.

So I started building a new open source development environment called Broomy.

The goal of Broomy is to make this style of development practical: lots of coding agents in parallel, with the human acting more like a sculptor than a gatekeeper.

Broomy still feels broadly like a VS Code-style IDE. It has a text editor, version control, terminals, and agent panels. But the key difference is that it is designed around lots of parallel sessions, with fast ways to jump between them, see which ones are done, and see which ones actually need human attention.

It also supports custom command buttons that trigger useful agent workflows in one click. Those commands depend on the state of the work. The underlying behavior is often implemented through skills and agent workflows, but surfacing them as buttons makes it much easier to move agents through repeatable processes quickly and consistently.

A typical command might cover a pretty large chunk of work. For example, “Create PR” might ask the agent to:

• organize its changes into sensible commits

• pull from main

• resolve merge conflicts

• run validation

• get reviews from relevant review agents

• respond to those reviews

• write a clear PR description

• call out the design decisions a human may want to examine

Broomy is open source, works on Mac, Linux, and Windows, and supports terminal-based coding agents including Claude Code, Codex, and Gemini. And yes, every line was written by AI, using the kinds of techniques described in this post.

Try it out and let me know what you think:

https://broomy.org

Final thought

The mistake many teams make is to treat AI as a junior employee whose every action must be micromanaged. That leaves all the leverage on the table.

The better model is to treat agents like a weird new kind of organization: incredibly fast, extremely cheap, often surprisingly capable, occasionally spectacularly stupid, and in constant need of good systems around them.

If you want to get real value from them, don’t ask humans to rubber-stamp everything. Teach your agents to manage up. Teach them to surface what matters. Teach them to make the best use of human attention to work collaboratively with humans to create the best possible output.

Some of this post might seem very specific to software development, but to the extent that agents are coming for all human work (and it seems they are) these principles likely apply much more broadly.