An engineer finishes a change in an afternoon. It waits two days for review, returns with a question about intended behavior, then waits again while someone finds the person who made the original decision. The coding assistant may have saved several hours. The customer is still waiting.
AI productivity gains can be real at the task level while remaining difficult to see across a company. Work passes through people, systems and decisions with different constraints. Improving one activity changes how much work reaches the next one, but it does not automatically make that activity easier to complete.
Understanding this gap requires looking at the path from a request to a useful result. That path often reveals a more valuable opportunity for AI than producing another draft faster.
The time between the tasks
Consider a software team changing how users recover access to an account. The implementation is relatively small. The team must also confirm which identity checks apply, update the help material and prepare support staff for customers who cannot complete the new process.
An assistant helps the developer finish the implementation quickly. A separate assistant drafts help content from an older specification. The security reviewer receives the code without the decision explaining why one recovery option was excluded. Support sees a polished draft and assumes the feature is ready.
Nothing in this illustrative situation requires a poor model response. The participants can each produce reasonable work from the information they receive. The delay comes from the relationship between their work: the code, guidance and review describe different understandings of the same change.
The developer then becomes the person who reconciles those understandings. Time saved writing code is spent locating sources, explaining a decision again and correcting material that was prepared too early.
For this change, a timeline would separate these events:
| Stage | What the team needs to establish | A delay worth investigating |
|---|---|---|
| Request | The account recovery behavior the company intends to support | An unresolved policy question is treated as an implementation detail |
| Implementation | The change and evidence that it behaves as intended | The developer receives incompatible requirements |
| Review | The relevant scope, reasoning and test evidence | A reviewer has to reconstruct why the change exists |
| Readiness | Accurate guidance and an owner for difficult cases | Documentation describes an abandoned option |
| Release | A decision based on the completed checks | Teams disagree about what has actually been accepted |
This view makes the waiting visible. It also distinguishes a necessary decision from avoidable reconstruction. A careful security review may be valuable time; asking three people for the same missing rationale is a different kind of cost.
What the productivity research tells us
Atlassian's 2026 State of Developer Experience report, based on a survey of more than 1,500 software practitioners, reports that 87% of developers say AI helps them ship work faster. Yet only 28% report noticeably less friction in their daily workflow than before AI.
Those are reported experiences, not a controlled measurement of how much faster every company delivers. They point to a question a team can investigate: where does individual acceleration appear in the larger process, and where does it stop improving the outcome?
There is no single answer. Review capacity, product uncertainty, unreliable tests, competing priorities and difficult integrations can all affect delivery. Shared information is one part of that system. It deserves attention when people repeatedly lose time establishing facts that someone else has already established.
Measure the local situation before selecting a remedy. If the constraint is a weekly release window, a better project summary may improve preparation without changing the release date. If reviewers are waiting for missing evidence, the same summary could make a meaningful difference.
Trace one change before counting everything
Choose a small set of recently completed changes with a recognizable outcome. Follow each from its first accepted request through release and the first useful customer feedback. Include work that became blocked or was abandoned, since completed work alone can hide expensive failures.
Ask the people involved what happened at each boundary. When was the work ready for review? What did the reviewer lack? Did someone have to repeat an investigation? Which decision changed after another team had started acting on it?
Capture dates and source references where available. An issue opening date is not necessarily the beginning of work, and a merged change may still be waiting for release. Record those distinctions before calculating elapsed time.
Three measurements are particularly useful together:
Elapsed time from an accepted request to an outcome available to its intended users.
Time spent actively producing, checking or correcting the work.
Time waiting for information, access, review capacity or a decision.
These categories need a consistent definition, but they do not require tracking every minute of an employee's day. A short review of the work record and interviews with participants can identify a recurring delay without building a surveillance system.
Avoid treating every interruption as waste. A reviewer who discovers an unsafe recovery path has improved the outcome. The question is whether the team supplied what that reviewer needed and acted efficiently on the finding.
Faster output can increase the review burden
Suppose developers begin submitting larger changes because generating code has become easier. Reviewers now face more behavior to understand, more tests to inspect and more explanations to request. A rising count of completed drafts may coexist with a growing queue of unfinished work.
The appropriate response may be to reduce the size of the work being passed along. DORA's guidance on small batches connects smaller changes with faster feedback and recommends keeping them independently valuable and testable.
For the recovery change, the team could agree on one supported path, implement it, and review the corresponding tests and guidance together. A second recovery option can follow after the first has produced useful evidence. Reviewers would examine a coherent decision with a smaller set of consequences.
AI can help prepare that package. It can compare the implementation brief with the draft guidance, identify references to the excluded option and collect the tests relevant to the agreed behavior. Someone still needs to inspect the findings and resolve policy questions.
Be selective about additional automation. Generating a separate summary for every participant can create another set of documents to maintain. A concise shared account of the current decision may serve several roles, with restricted evidence kept available only to the people who need it.
Improve a handover where information changes meaning
Pay particular attention to boundaries where the next participant must interpret what the previous one produced.
For a code review, that might mean preserving the requirement and the reason for an unusual implementation choice. For customer guidance, it might mean distinguishing supported behavior from a proposal that appeared in an early planning discussion. For release approval, it might mean identifying the checks that remain open.
The handover should answer the next person's immediate question. A reviewer needs to know what decision the change implements. Support needs to know what a customer can do and where an unresolved case goes. Both may need the same underlying evidence, but their working views will differ.
Our article on context engineering explains how to select relevant information for an agent. The organizational version of that problem is similar: the company must first maintain a record whose meaning survives movement between teams.
Make an owner responsible for important updates. When the accepted recovery behavior changes, the team should identify affected work and request the necessary revisions. A saved decision is useful only if people and agents know which version applies when they continue.
Test a change to the process
Run a limited improvement around one recurring responsibility. For example, require each account recovery change to reach review with an accepted behavior brief, relevant test evidence and a short account of unresolved questions.
Compare it with similar work using the existing process. Record differences in complexity, urgency and staffing. A straightforward correction and a major redesign will produce misleading comparisons even when their issue labels match.
Look for a reduction in repeated questions, revisions caused by missing context and elapsed time to a reviewed outcome. Also check whether the new preparation adds enough work to offset the benefit. Count the effort of maintaining the record, including human review of AI contributions.
If the team wants to isolate the effect more carefully, alternate the process across comparable changes or introduce it gradually while recording other changes to the environment. Small samples are useful for learning, but they should not become broad claims about company productivity.
An assistant may reduce preparation time without changing overall delivery time. That is still useful information. It suggests that another constraint, such as review availability, needs attention before further automation can improve the complete workflow.
Give the shared work a durable record
Swarm Spaces provide a place for the brief, discussion, outputs, agent Runs and human decisions surrounding a project. In the recovery example, the team can keep the accepted behavior and review evidence together, then ask authorized agents to prepare scoped checks against that record.
An incoming participant can inspect the relevant decision, examine its evidence and understand what remains unfinished. That gives their next contribution a starting point grounded in the project. The Swarm connection guide explains how agents can access permitted Spaces from compatible tools.
The repository, delivery pipeline and other business systems continue to hold their respective operational records. Keep references to the versions that matter. A shared project record should help the team interpret those systems without turning an unverified summary into a release decision.
For the broader coordination model, see our guide to agentic workflows. Start with one boundary where reconstructing context causes a visible delay, and evaluate the effect on the next person's work.
Look for the result the next person can use
The most revealing productivity question is often simple: what became easier for the person receiving this work?
A developer may have produced the change sooner. A useful organizational improvement also helps someone review it, support it or make a decision about it. When those steps become clearer, the saved effort has a better chance of reaching the customer.
Measure that path. Keep the work small enough to inspect, preserve the reasoning that affects the next decision, and use AI where it removes an observed obstacle. The goal is a company that can complete useful work with less avoidable reconstruction.