You're A Manager Now

A former principal engineer at Meta wrote down how he works now, and one number stopped me cold. Shipping 30-plus pull requests in a day — real ones, the kind that clear his own quality bar — used to be hard to imagine. It's now a slow day.

That's Kun Chen, a former L8 who led Atlassian's AI developer product before leaving big tech to build solo. In a guest post on ByteByteGo he walks through his entire setup, and the number isn't the part worth stealing. This is: "I stopped writing most of the code myself and started acting like an engineering manager directing a team of agents."

I read the whole thing nodding, because it described most of my own desk back to me. I plan before I let an agent build. I make agents prove their work actually runs. I run several at once in isolated worktrees so they don't trip over each other. I prompt by talking, not typing. None of that felt novel — which is exactly why the two things I don't do jumped off the page. More on those at the end.

But first the idea underneath all of it, because the tools are downstream of it.

The promotion nobody handed you

In an earlier post I argued that the thing separating an agent from a chatbot is the loop: it acts, looks at what happened, decides what's next, and keeps going without you pushing it along. Once you have a worker that runs its own loop, your job quietly changes. You are no longer the person doing the work. You're the person deciding what work to do and whether it came back good.

That's management. Not the calendar-and-headcount kind — the actual craft of it: deciding what to build, handing it off cleanly, and judging the result without doing it yourself.

Most engineers are bad at this at first, for the same reason new tech leads are bad at it. The skills that made you a great individual contributor — doing the thing, fast, yourself — are the exact skills you now have to suppress. The bottleneck stops being how fast you type. It becomes how clearly you can describe an outcome, and how well you can tell good work from bad.

The model isn't your bottleneck anymore. Your ability to delegate is.

Delegate outcomes, not keystrokes

Kun names the three classic delegation mistakes, and they're the same whether you're handing work to a junior engineer or an agent: you ask for an action instead of an outcome, you don't explain the why, and the moment something goes wrong you snatch the work back.

"Rename this variable" is the trap. The agent does it in two seconds and hands control straight back to you — you've saved nothing, and you're still the bottleneck. Worse, you told it what to do but not why, so it can't suggest anything better and won't know to do it right next time. "Audit this module and make our variable names follow this convention" is the same task pointed at an outcome. Now it can run for ten minutes, and the standard sticks for the rest of the session.

This is the part I'd already internalized, and the highest-leverage version of it is what you do when the agent gets something wrong. The instinct is to fix it yourself. Don't — that's snatching the work back, and it's how you make yourself the ceiling. Give feedback instead, and make the feedback permanent: write the correction into CLAUDE.md or AGENTS.md so the agent stops making that mistake everywhere, not just this once. Those files are the agent's standing orders — editing them is the closest thing you have to actually training your report.

It's also why I prompt by voice now. You describe an outcome and its reasons far faster out loud than you do by typing, and the friction of explaining the why mostly disappears when explaining is just talking.

Plan before you hand off the keys

There's a camp in the agent world that says don't bother planning — just talk to the agent and feel your way there. I'm with Kun on the other side, and the reason is operational, not aesthetic.

If you "just talk to it," you have to stay in the conversation. You get pulled back every few turns, the actual plan lives in a wall of scrollback nobody can parse, and you can't hand the thing off and walk away. Spending concentrated time up front to get a plan into a state you're confident in is what buys you the autonomous run afterward — and it's what frees you to start a second task while the first one builds.

This is just what good managers do before delegating anything that matters: agree on the shape of the work before someone spends a week building the wrong thing. I already write the plan first and argue with it before a single line gets written. Kun took it a step further and built a tool, lavish-axi, that has the agent render the plan as an interactive page in the browser — so for a UI feature you're clicking and annotating the actual mockup instead of reading paragraphs about it. I haven't used it, but the instinct is exactly right: the plan is the highest-leverage artifact in the whole loop, so make it as easy as possible to get right.

Managers don't read every line — they ask for proof

Here's where I caught myself.

Ask any engineering manager if they read every line their team ships. They don't. They can't. What they do instead is insist on two things: someone other than the author reviews it, and before it merges, there's evidence it actually works.

I do the second one religiously. I don't trust a green test suite — I make the agent prove the change works end to end, drive the real app, show me the thing happening. Kun is blunt about why: frontier models lean on unit tests because of how they're trained, and he's watched countless changes pass every unit test and still ship broken. Passing tests is a claim. Working software is the evidence.

What I don't do by reflex is the first one: review with fresh eyes. If you ask the same session that just wrote the code to review it, you're asking someone to grade their own homework — it assumes its own choices were correct and waves them through. A reviewer spun up in a clean context, with no memory of having written it, catches things the author is constitutionally blind to. Kun packaged his whole review pipeline into a tool he calls no-mistakes — fresh-context peer review, end-to-end evidence with screenshots, lint and CI babysitting, and crucially it escalates the genuinely ambiguous product calls back to him instead of guessing. The stat that stuck with me: 68% of the changes he pushed through it had bugs the pipeline caught.

I have the pieces for this already — Claude Code ships a /code-review that runs in its own context. I just don't reach for it by default. That's habit number one I'm fixing: the author never signs off on their own work.

Run a team, not a soloist

A manager with one report isn't really managing. The leverage shows up when several things run at once.

This part I live in. I usually have a handful of agents going, each in its own git worktree — an isolated checkout of the repo — so they're not editing the same files and clobbering each other. The thing that makes it survivable is being able to see, at a glance, which agent is working, which is done, and which is blocked waiting on me. Kun keeps each task in its own terminal pane with the status in the tab title, and built a tool called treehouse that manages a pool of ready worktrees so he never thinks about where to put a new task — he just starts it.

The same mindset is why "where am I sitting" stopped mattering. A manager checks in on the team from wherever they are; I can pick up the same session from my phone if I'm out. The work doesn't pause because I stood up.

The tools are just the mindset, hardened

Notice the pattern. lavish-axi, no-mistakes, treehouse, the overnight orchestrator he calls gnhf — none of these is the lesson. Each one is what happens when a manager hits the same friction enough times and refuses to keep paying it. The mindset comes first; the tool is just the mindset made permanent.

That reframes the takeaway. The win isn't installing his tools — most are his own, built for his own friction. It's developing the reflex that produced them: notice the thing slowing you down, and either find the tool that kills it or build a small one that does.

Which brings me to habit number two I'm stealing. The one piece of his setup I have no equivalent for is gnhf — "good night, have fun" — a loop he kicks off for tasks too big for a single context window. It breaks the job into steps, runs each in a fresh context seeded with what the last step learned, rolls back failed attempts, and respects a token budget so he doesn't wake up broke. He comes back to a branch of clean commits and a notes file. I've been treating context limits as a wall to babysit around. Treating them as something to orchestrate through is the better frame, and it's next on my list.

You're the manager now

The uncomfortable part of all this is that the promotion already happened. The moment you handed an agent a real task and it ran its own loop, you became a manager — whether or not you're any good at it yet.

Most of getting good is unlearning the IC reflexes: stop reaching for the keyboard to fix it yourself, stop describing keystrokes when you mean outcomes, stop trusting work nobody independently checked. The engineers who get the most out of agents over the next year won't be the ones with the best model. Everyone has the same models. They'll be the ones who learned to manage.

So the question isn't whether you're a manager. It's whether you're a good one.