From Individual AI to Team AI: The Next Problem

Personal AI wins are real. Team AI wins are a different problem. I have been seeing this pattern in conversations all month, and I posted about it last week. Here is what I have been thinking about since.

The shift is real. The evidence is coming from everywhere.

MIT put a number on it. 95% of AI pilots that skip workflow restructuring deliver zero P&L return. Implementation: yes. Business outcome: no (or not yet). The companies that are seeing returns are doing different work than the ones that are not.

You see it in writing everywhere. Thariq Shihipar at Anthropic put it concretely: about one percent of the tokens he generates go into production code. The other ninety-nine percent is directing, evaluating, redirecting, and deciding which one percent was worth keeping. Elena Verna names it from the career angle: the new flex is going back to IC and completing an entire project solo, because the floor of what one person can deliver has moved. Others, from a16z to PM writers like Aakash Gupta to peer practitioners running working cohorts, are all describing the same underlying shift from their own seats.

And in comment threads under any serious post about AI workflows, experienced builders keep asking the same questions in plain language. Who do I hire when I need someone to run this? When does it make sense to spin up a sub-agent? What does good output actually look like?

None of these people coordinated. They are not using the same vocabulary. But they are all describing the same underlying shift.

Orchestration is the real work. Execution is the output. Judgment is the constraint. The artifact, whether code, copy, spec, or brief, is no longer the bottleneck. The bottleneck is knowing which artifact to produce, in what order, against what criteria, and how to evaluate whether the result is even right.

That is the new ground. Everything in the rest of this is downstream of accepting it.

What the ground means

The implications are fairly clean at the individual level. The orchestration layer is yours. Your own workflows and processes improve. You design it. You own the judgment. You build the system that does the execution, and you hold the evaluation function. A person who has done this well has genuine leverage. The gains are real.

At the team level, none of it transfers automatically.

That is the argument I make. None of this comes from adding tools. The team’s workflow has to fundamentally change. How work moves between people has to change. How handoff happens. What good looks like has to be defined together, not assumed. And those are not tool problems. They are operating problems.

For PDE (Product/Design/Engineering) teams specifically, the mechanics are concrete. Specs move from PM to design before they are stable. Designs move to engineering before the edge cases are resolved. Engineering ships before product has confirmed the right thing got built. Each of those handoffs already carries friction. Add AI acceleration to each seat and you get faster friction, not less of it.

Now add this: each of those seats can generate a working prototype in an afternoon. PMs spinning up clickable flows. Designers building functional drafts. Engineers prototyping multiple architectures in parallel. The artifacts pile up faster than the team can evaluate them, let alone agree on which ones to kill or not even pursue.

The evaluators fall behind. The team is running faster than it is deciding.

Four things that need to shift at team altitude

Saying no. I have always said the best PMs know when to say no. It is even more critical now. At the individual level, the kill function is personal. You decide something is not worth building. The cost is yours. At a team, “no” is distributed. The PM who says no to a feature idea that three engineers have been prototyping for two days carries a different cost than the same PM saying no to a solo draft they wrote in a session. When anyone on the team can generate a working prototype in an afternoon, the political cost of killing it does not go down. It goes up, because now there is a working thing, and someone made it. Naming the kill function as a shared practice, not a solo move, is part of the team’s new work.

Kill rate. I wrote about this earlier. When one person can generate 20 prototypes a week, the scarce skill is not building them. It is killing 16 of them fast. That argument holds at the individual level. At a team, the kill rate has to become a shared agreement. Who kills, on what evidence, by when. If that agreement does not exist, the team defaults to shipping everything that gets built, or to the person with the most authority stopping work they did not understand. Neither is a workflow. They are failure modes.

Judgment. AI absorbs the executable layer. Judgment is what does not move with it. One person’s judgment is hard enough to maintain well. Distributed across a team, it fractures. Every person on the team is building their own AI workflow, developing their own instinct for what good looks like, and none of them have necessarily named it. The team needs a shared definition of good and a shared instinct for “not yet.” It does not need the same tools. It needs the same standard. That standard does not come from the software. It has to be built deliberately.

Augmentation, not replacement. When AI takes over execution, what is left is direction, evaluation, and craft. The job does not disappear. It shifts upward. At the individual level, that shift is something the operator designs into their own workflow. At a team, the augmentation has to be designed into the workflow itself: into the handoff, into the review gate, into the moment where one person’s output becomes another person’s input. That design is not automatic. It is not seat-by-seat. It is not a consequence of everyone using better tools. It requires someone to ask: what does this team’s version of good look like at each stage of the work? And then build accordingly.

What gets freed

When the team gets this right, something real opens up. The execution gets handled. The scaffolding runs. The drafts appear. What is freed is the work that does not commoditize: strategy, direction, the judgment calls that compound over time. The craft that comes from knowing the product, the users, and what matters, not just in this sprint but over the arc of the thing being built.

That is what redesigning the workflow is actually for. Not speed. Not fewer headcount. Not AI seat utilization. The work that compounds. What good looks like in your context. The freed capacity for the decisions that only humans in the room can make.

What is still unsettled

I am not going to pretend this is solved. The companies I see doing it well are in early innings, and they are making it up alongside everyone else.

A few things I am still watching:

How does a team know when it is ready to redesign the work, not just adopt the tool? There is a stage where every person builds their own workflow and the team looks like it is moving fast. There is a later stage where all of those individual workflows need to be made legible to each other. The transition is not automatic and the signal that it is time is not always obvious.

How does a team define good together when each person has been building their own AI workflow? The definitions diverge quietly. The PM has one standard, the engineer has another, design has a third. The artifact comes back and nobody agrees on whether it is done. This is not a new problem, but AI makes it faster and more visible.

How does the kill function get distributed without becoming political theater? The answer probably involves making the criteria explicit before the work starts, not after. But “explicit criteria” and “shared agreement” are easier to say than to build with a real team under real time pressure.

I do not have clean answers to any of these. I have working hypotheses and I am testing them. That is where this field is.

One pattern I am watching: companies starting to set up shared repos of AI workflow assets. Reusable skills, hooks, context files that team members can pull from. Team-level scaffolding for what individuals have been building solo. Early days, but the right direction. The teams that do this thoughtfully are building shared substrate without flattening the individual judgment that produced the assets in the first place.

Close

This is the new frontier. Not for one person with a good system and fast fingers. But for teams that are deciding, right now, whether the AI acceleration they each built individually adds up to something collective, or just adds up to a faster version of the same friction.

The companies figuring this out are not the ones with the most AI seats. They are the ones redesigning how the work flows. That is the harder thing. It is also the more durable thing.

If you are leading a team trying to start: pick one workflow your team owns. Name what good looks like together before adding AI to it. Decide the kill criteria upfront, not after the prototypes appear. The hard part is not the tools. It is the conversation about what the team is actually for.

That is where I am pointing.