Everyone Is an IC Now, and Nobody Is in Flow

Two complaints are going around at the same time, and they sound like they come from different people.

The first is from managers, product leads, staff engineers, anyone whose job used to be mostly talking. They say the job got lonely. The meetings still happen, but the work happens afterwards, alone, in a terminal, with an AI. They have become individual contributors again without anyone deciding that.

The second is from engineers who were already individual contributors. They say the job got shallow. They spend the day steering a model instead of building something, and the deep, absorbed hours that made the work worth doing have gone missing. Nolan Lawson named the feeling in “We mourn our craft”: the tools are too capable to refuse, and what they replace is the part you loved. Some mourn in public. Some are quietly leaving over it. The tools work fine. The work just stopped feeling like the work they chose.

I think these are the same complaint. Both groups have been pushed into a single new mode of working, one that is neither collaboration nor flow. To see why, you have to look at the shape of an AI session, because the shape is what does the pushing.

One driver

Here is what a productive session with a coding agent looks like. You describe what you want. The agent goes off for thirty seconds or three minutes. You read what it did. You correct it, or narrow it, or tell it to keep going. It goes off again. Repeat for an hour.

Every step of that loop belongs to one person. One person writes the prompt. One person judges whether the output is right, in their head, faster than they could explain it to anyone. One person types the correction.

Try adding a second human. They can watch the screen. They can suggest a prompt. But by the time they have said “maybe tell it to use the existing helper,” you have already read the diff, decided, and typed the next instruction. The second person is commentating, and commentary is slower than the loop.

Pair programming worked because the driver and navigator ran at the same speed. When Alistair Cockburn and Laurie Williams studied pairs, much of the value came from continuous review: the navigator reads the driver’s code as it appears, at typing speed, and catches mistakes as they are entered. The agent loop breaks that. Code appears in bursts, faster than either human can read, and then nothing happens while the model thinks. There is no steady stream for a navigator to ride.

Pair programming gave the navigator a stream to read at the same tempo it was written. The agent loop gives them nothing to ride.

Think of it as driving a car. Two people can plan the route and argue about the destination, but only one holds the wheel, and everyone has been in a car where the passenger tried to drive from the other seat. It is worse than silence.

So teams settle, without discussing it, into two modes. Either two people work together and use the AI lightly (autocomplete, quick questions) and give up most of what the tools can do. Or two people talk, one of them captures the conversation as context, and then goes off alone to do the real work with the agent. The second mode wins because it gets more done, or at least because everyone involved believes it does, which turns out to be enough. That is the mechanism that turns a manager into an IC. Nobody assigned them tickets. The loop has room for one.

Not the IC work you remember

If the story ended there, the fix would be obvious: give everyone maker blocks. Paul Graham described the split between the maker’s schedule and the manager’s schedule in 2009. Makers need long uninterrupted stretches because a single meeting can wreck an afternoon; managers live in hour-sized units where interruptions cost nothing. If everyone is a maker now, put everyone on the maker’s calendar and protect the blocks.

Plenty of teams are doing exactly that, and it is not working, because the block is not what people think it is.

Flow, in the sense engineers mean it, is a state where the task holds your whole attention for a long time and the outside world drops away. You get it when you are building something at the edge of your ability and the feedback comes continuously from the work itself. Debugging a race condition. Turning an architecture over in your head until it settles. The hours disappear.

An agent session has the calendar shape of flow with none of the interior. You are not holding the problem; the model is. Your attention comes in short pulses: read this diff, decide, type the next instruction, wait. The wait is the killer. Thirty seconds is too short to start something else and too long to stay absorbed. So people do what anyone would do with a dead thirty seconds. They check a message. They open a second session. They start a third.

Now the engineer who wanted uninterrupted time has three agents running and is switching between them every minute. They are alone, on a maker’s calendar, doing manager-shaped work: checking in on parallel streams, making quick judgment calls, moving on to the next one. This is what the people leaving are describing. The work did not get harder. It turned into supervision, and supervision is not what they signed up for.

The block looks identical in the calendar. The attention inside it is a different animal.

So both groups have converged. The manager lost the room and gained a terminal. The engineer kept the terminal and lost the zone. They are both sitting alone, watching a model work, deciding in short bursts whether it is right. Everyone got the maker’s calendar. Nobody got the maker’s flow.

Supervision is its own skill

The tempting conclusion is that the tools are making work worse and we should use them less. The evidence is messier than either camp admits, and it is moving. In early 2025, METR ran a randomized trial and found experienced open-source developers were 19 percent slower with AI tools allowed, while estimating afterwards that the tools had made them 20 percent faster. When METR reran the experiment across late 2025 and early 2026, the window in which agentic tools actually took hold, the estimate tipped toward a speedup, though they are careful to call the newer evidence weak. Some of that flip is better models. Some of it, I suspect, is people getting better at the loop. But the finding from the first study that no better model retires is the perception gap: nobody in the slower group felt slow. That is what untrained supervision looks like from the inside. A third mode of work has appeared, with its own rules, and we keep trying to run it with rules borrowed from the other two.

Collaboration’s rule is: get the right people in the room. Flow’s rule is: protect the block. Supervision’s rules are different, and teams are mostly discovering them by accident. Here is what I have seen work.

Batch your steering. The reflex is to correct the agent the instant it drifts, which keeps you glued to the loop with attention that has nowhere to go between corrections. The alternative is to give it a larger, better-specified chunk, let it run for real, and review the whole result once. Fewer, bigger turns. It sounds obvious. Few people do it, because tight steering feels like control.

Cap parallelism on purpose. Running five sessions feels like getting five times as much done. In practice it is the exact context switching everyone complains about, self-inflicted. Two sessions, one doing the work you care about and one doing something rote, is usually the ceiling before your judgment gets sloppy. Pick the number deliberately instead of letting the idle thirty seconds pick it for you.

Use the wait as review time. The gap while the model works is about as long as a careful read of what it did last time. That is no accident: the loop generates review work at roughly the rate you can consume it. Treat the gap that way and the fragmentation stops feeling like fragmentation.

Move the deep thinking upstream, and say so. If the session can’t hold your whole attention, the conversation before it has to. This is where collaboration lives now: two people working out what should be built, what the constraints are, what “done” means, until the result is precise enough to hand to one person and an agent. Meetings that produce a specification instead of vague alignment. Most teams already do a bad version of this (“I’ll go try it and let you know”). Doing it well means treating the pre-session conversation as the design work, because it is.

What a team looks like now

Put this together and the shape of the day changes for everyone.

Collaboration moved to the edges. Upstream, where people figure out what to build and write it down well enough to hand off. Downstream, where they review what came back, together, with the judgment the agent lacks. The middle, where the work actually happens, is solo, and the solo part is supervision: a mode of attention most of us were never trained in and are currently improvising.

Collaboration didn’t disappear. It moved upstream to the spec and downstream to the review, and the middle became supervision.

That is a reasonable shape for a team. It is a bad shape to fall into by accident, which is how nearly everyone arrived here. The managers who feel lonely are right; their job really did lose its most social part. The engineers who feel scattered are right too; their job really did lose its most absorbing part. Neither loss is a bug in the tools. Both are the cost of a loop that has room for one person and a tempo that belongs to neither.

The teams that will do well are the ones that name the third mode and design for it, instead of handing everyone a calendar block and wondering why nobody is in the zone.