I have been thinking about a strange mismatch in the way AI is changing work. Individuals are becoming much faster. A product manager can turn rough thinking into a clear first draft. An engineer can understand an unfamiliar codebase and begin building in hours instead of days. A designer can explore many more possibilities before settling on one. But teams are not always seeing gains of the same magnitude. Giving every person an AI tool does not, by itself, make the group work better together.
The usual response is to standardize the tools. Choose a model, pick an agent and teach everyone how to use it. This is useful, but it cannot be the foundation of team efficiency because the tools change too quickly. The model that feels indispensable today may be replaced next month. The teams making the most progress are often the ones that understand the strengths of different models and can move between them without much friction. The durable layer is not the tool. It is the team’s way of working.
A way of working is the set of agreements that allows work to move from one person to another. What do we write down before we begin? Who needs to review it? Which decisions must be recorded? When is a piece of work ready for someone else to depend on? Who owns the final output? These questions may sound procedural, but they form the shared infrastructure of a team. This can also include shared AI skills: reusable instructions and procedures that encode how the team investigates a problem, writes a design or checks its work. AI makes this infrastructure more important because it allows each person to generate a large amount of plausible work very quickly.
A simple example is the agreement that we do not begin coding without a written engineering design. The document itself can be created with the help of an AI agent, but it must still be discussed, challenged and approved by the team. Product needs its own version of this artifact: perhaps a short product document or a shared note containing what we know about the problem, the user and the important decisions already made. The names of these documents do not matter much. What matters is that the thinking becomes visible before the volume of generated work begins to grow.
This only works when each person takes responsibility for their agent’s output. If I pass a product document, a design or a piece of code to a colleague, they should be able to assume that I have read it, tested it and stand behind it. A final code review or approval step cannot compensate for careless work upstream. If I send unvalidated output to the next person, my apparent efficiency becomes their problem. They have to find the gaps, reconstruct the reasoning and make the decisions I skipped. Trust in AI-assisted work is not attached to the tool. It is built through the way the work was produced.
Once that trust exists, the traditional sequence of product development can begin to change. Product can establish the intent and the important decisions in a short document. Engineering can build the complete feature flow using existing design components. Design can then refine new components, layouts and visual details while the feature is already taking shape. The work no longer needs to wait at every boundary. This is not an argument for lowering the quality bar. It is a change in the order of operations, made possible because the people involved trust the artifacts and decisions moving between them.
Some work will still be thrown away. A component may need to be rebuilt. A product decision may change after the feature becomes tangible. Teams need enough psychological safety to accept this without treating every discarded draft as a failure. The cost stays manageable when projects are divided into features that can be completed in a day or two. Small units allow the team to learn, adjust and still show meaningful progress each week. Individual AI efficiency comes from producing work faster. Team AI efficiency comes from establishing a shared way of working that turns that speed into work other people can trust.