Stop Micromanaging Your Agents

Last week, my OpenAPI toolchain repo merged 110 pull requests.

I wrote almost none of the code. I filed almost none of the issues. I did not catch the bugs. Most of those PRs were small and scoped, fixes and refactors more than features. In the same seven days, 52 issues were opened and 33 were closed, and I opened maybe two of them by hand. The rest of the work was done by agents, and the one thing that would have wrecked it was the thing every senior engineer’s instinct screams to do: manage them closely.

I didn’t. That’s the whole point.

---

The instinct that breaks agents

Here is what I learned the expensive way. The harder you force an agent down your exact path, the worse it performs. Every constraint you add, every “no, do it this way,” pulls it away from the behavior it was trained to produce and toward a worse imitation of you. Micromanaging an agent is not control. It’s sabotage with extra steps.

So I stopped starting with a master plan.

When I built openapi-zod-ts, the toolchain I always wished existed, I didn’t know half the mechanics. I had never published to npm. I didn’t know which dependencies I needed or how to make a release pipeline work. So I didn’t pretend to. I had a direction, not a blueprint, and I moved one micro-step at a time: spin up a GitHub org, publish something, anything, to npm, get a workflow file running. Each step small enough to actually finish. Once it narrowed to implementation, features, and tests, I let the agent run on its own.

It worked over a handful of evenings. The speed was not the surprise. The surprise was how little of it was me.

---

You don’t correct it. You challenge it.

If you’re not steering line by line, what are you doing? You’re raising the bar.

When the agent was doing well, I didn’t pat it on the head and move on. I made the next thing harder. A dedicated integration-test package, to prove the three packages actually work together, not just in isolation. Smoke tests. A full Pet Store demo wired end to end. And finally, 128 real-world OpenAPI specs thrown at it at once, the messy, inconsistent, spec-violating kind that real APIs ship.

Then I fed it real pain. At my day job I opened a pull request to migrate our production systems onto the library, never merged, but the experience was real, the breakage was real, and I QA’d the whole thing locally with a separate Claude session. Real specs and real migrations surface problems no unit test invents.

That’s the shift. You don’t tell an agent how to be good. You hand it harder things to be good at.

---

The best fix I made, I didn’t make

Somewhere in there, the agent reached for .passthrough() on a response schema, keep every unknown field that comes off the wire. Wrong call for a response contract. You want .strip() there, so a backend that suddenly starts sending an extra field can’t leak it into typed code that never expected it.

I want to be honest, because this is the part most posts dress up: I did not catch that. I was not reading the diff line by line going “aha.” What I did was ask a question from the outside, “do we have tests where we enhance the Zod schema with custom error messages, and does it actually work?”, and I spawned a neutral AI reviewer agent to look with fresh eyes. My question plus the reviewer’s read surfaced the misalignment. The fix followed as a consequence. The system caught itself. I just kept poking it from the edges.

That is the real engine. I don’t review the code. I run critics that do, and I let them file issues like real users would. In 2026 you don’t hand-write a bug report; an agent writes a sharper one in seconds. So the repo generates its own work: 52 issues opened last week, 33 closed, 19 still open as I write this. I wrote almost none of them.

---

Is this a machine inventing its own work?

I have to sit with the honest version of this. Fifty-two issues opened, thirty-three closed. The backlog grew. A loop that only generates more work for itself is not a feedback loop, it’s a hamster wheel, and from the outside they can look identical.

So I keep challenging the system to judge its own issues the way it judges code: is this real, is this worth it, does fixing it raise quality or just raise the count? So far the answer holds up, and the proof is what the loop throws away. An agent filed a clean, reasonable request to emit z.discriminatedUnion for discriminated oneOf schemas. It got closed as not worth the complexity it would add. A loop that couldn’t say no to its own ideas would have built it. The issues that do get fixed are real bugs and refactors that fight genuine complexity, with the test battery underneath keeping the quality from drifting. When good issues still outrun the pipeline’s capacity to fix them, that’s a prioritization problem, and prioritization is one of the few jobs that stays mine.

I watch this closely. The day the loop starts producing busywork that passes its own review, the philosophy is wrong. It hasn’t happened yet. But “yet” is the operative word, and I’d rather name that out loud than pretend the loop is self-evidently virtuous.

---

Where it actually stops

One prompt buys me about ten minutes of agentic work. In that gap I am not watching a progress bar. I’m in another terminal, on another project. Right now I have seven sessions open across five codebases: day-job work, this website, a second content site, the OpenAPI toolchain, and a SEPA XML library. When one needs a nudge without disturbing the agent mid-flight, I open a read-only session or split off a git worktree and merge it back later.

The ceiling I hit is not my attention, and it’s not my typing speed. It’s 36GB of RAM. I once had around 60 agents running at once and my MacBook ran out of memory, one time it recovered, one time it needed a hard reboot. That’s a story for another post, but it tells you where the real constraint moved. Not to the human.

---

I’ve become the software engineering manager of agents, and it suits my dream job better than any role I’ve held. The work isn’t writing code anymore. It isn’t even reviewing it. It’s setting a direction, raising the bar, standing up critics, judging what’s worth doing, and then doing it again in five other terminals.

Manage an agent like a junior developer who needs watching, and you’ll get a junior developer’s ceiling. Challenge it like a system, and it runs while you sleep.