The Management Layer Nobody Trained For
There’s a science fiction series called We Are Bob where a software engineer gets uploaded into a self-replicating space probe. He copies himself dozens of times, sends those copies across the galaxy, and each one develops its own personality. It’s a great read — and if you pick it up, you’ll notice that Bob spends a surprising amount of time not exploring the galaxy but managing things he’s built. Roamers exploring alien terrain, mining drones extracting resources — even construction units building habitats. He sends them out, monitors their progress, adjusts their tasks when conditions change, and decides which ones need close oversight versus which ones he can leave alone for a while.
I thought it was a fun detail when I read it. Now it feels like a job description.
The messaging from AI companies shifted recently. It used to be “chat with AI to get things done.” Now it’s “stop chatting and start managing.” The new generation of tools — agent frameworks, autonomous coding assistants, multi-step task runners — assumes you’re not doing the work anymore. You’re supervising it.
Are we ready for that shift?
The Supervision Pitch vs. What Actually Works
The implied model is: tell the AI what to do, let it work, review what comes back. Manage from above. Delegate and evaluate.
That’s not how it plays out — at least not for me. I’ve tried a lot of approaches with AI tools. For anything that matters, what I keep coming back to is staying in the middle of the work. Directing it, reading the output as it forms, course-correcting when it drifts, pushing back when the approach is wrong. It’s less like managing a team and more like pair programming with a very fast partner who has no institutional memory.
The danger shows up when you treat AI output as a finished deliverable — something you review after the fact instead of shaping along the way. When the work arrives fully formed and your only job is to evaluate it, you’re doing a code review with no context about the decisions that were made. Someone in that position isn’t collaborating — they’re auditing something they didn’t build.
That’s where things break down. Not because the output is bad, but because the person reviewing it wasn’t close enough to the work to know whether it’s right.
Context Isn’t Just for the AI
When I stay close to the work, I have context. I know why a decision was made three steps ago, I can feel when something drifts off course, and I can catch problems before they compound. When I review a finished result cold, I’m evaluating something I wasn’t part of — and my ability to spot what’s wrong drops significantly.
There’s an irony here. We spend a lot of energy making sure AI has enough context to do good work — detailed prompts, background documents, examples of what we want. But the human reviewing the output needs context too. And that comes from staying in the middle of the process, not waiting at the end of it.
This Isn’t Actually New
“Managing work you don’t fully do yourself” is what leadership tends to look like at a certain level. A VP of Engineering doesn’t write code, a CPO doesn’t build wireframes — but both earned their judgment by spending years doing exactly that. The judgment came from doing, not from reading. They can spot a flawed architecture because they’ve built flawed architectures. They can tell when a product spec is missing something because they’ve shipped products where that something was missing.
What’s happening now is that we’re asking people to jump to the supervision layer without the reps. A mid-level developer is suddenly reviewing AI-generated code across patterns they haven’t personally worked with. A junior product manager is evaluating AI-generated market analyses against data they haven’t manually gathered before. The management layer is expanding faster than the experience base that makes management effective.
How I Stay in the Middle
I treat AI output as a first draft, not a deliverable. The review isn’t a rubber stamp — it’s an active rewrite. That takes more time than people expect, but it means I have context when I’m evaluating the result. I wrote the core logic; the AI handled the boilerplate. I know which parts I trust and which ones I need to scrutinize because I was there when the decisions got made.
The hardest part is being honest about where my knowledge ends. The most dangerous position isn’t using AI for something I know well — it’s using it for something I kind of know, where my ability to spot errors is weakest and my confidence that I could spot them is highest.
What Bob Had That We Don’t
Bob got better at this over time. He learned which missions needed constant monitoring and which ones he could check on periodically. He figured out how to design tasks that gave his drones enough autonomy to be useful without enough rope to go sideways. And he understood the work well enough — the physics and engineering, the terrain — to know when a report from a drone didn’t add up.
The AI agents people are being asked to manage don’t come with that same intuition. They’re autonomous tools producing polished output that almost always looks good. Telling the difference between good and good-looking — that’s the part that takes experience.
That’s not a technology question. And the answer isn’t going to come from better tools.
The output always looks good. The question is whether you’ve done enough of the work to know if it is.