Al Made Your Engineers 10x Faster. Your Team Didn’t Get 10x Better.

Individual output exploded. Team performance didn’t. The gains are evaporating in coordination — and Umaku makes that evaporation visible, measurable, and stoppable.

For CTOs, VPs of Engineering, Heads of Product  ·  Umaku field notes

Software production cost has collapsed. Coordination cost has not — and in AI-augmented teams it is compounding. This essay names the five places that compounding shows up, gives engineering leaders three new metrics worth tracking, and shows exactly where Umaku surfaces each problem in the workflow it would have hidden in.

The CFO sees the engineering line item and asks the question every CFO is asking now: we equipped the whole team with AI coding tools eighteen months ago, the engineers say they’re shipping ten times faster, and we have the higher commit counts to prove it — so where is the ten times more value?

The honest answer, if your VP of Engineering is being straight, is that the team is not ten times faster. The individuals are. The team, on a good week, is fifteen to twenty percent faster. On bad weeks it is slower than it was in 2022.

This is not a tooling failure. It is a tooling success creating a coordination failure that nobody warned you about — and it is solvable.

1. What got faster

Code completion got faster. Scaffolding got faster. First-draft logic got faster. Test stubbing got faster. Documentation generation got faster. Ticket-writing got faster. Spec-drafting got faster.

These are all individual-output gains. When you measure the time from “engineer decides to write a function” to “the function compiles,” that gap has collapsed. The keyboard is no longer the bottleneck. For a single engineer working on a self-contained task with a clear contract, the productivity gain is real and dramatic.

The problem is that real engineering work is not a single engineer working on a self-contained task with a clear contract. Real engineering work is six engineers working on partially-overlapping concerns with implicit contracts that exist mostly in heads and Slack threads.

2. What didn’t get faster

The cost of figuring out who is doing what right now. The cost of confirming the thing you are about to build does not already exist. The cost of integrating one engineer’s work with another’s without breaking either. The cost of carrying forward a decision the team made three months ago about how this part of the system is supposed to work. The cost of really reviewing three pull requests in the time it used to take to review one.

None of these costs got cheaper. Most got more expensive, because the volume on the other side of each question went up. More commits means more review surface. More AI-assisted PRs means more diffs that look plausible but do not fit the codebase. More tickets created means more tickets that overlap with tickets nobody remembers.

You bought ten times more typing. You didn’t buy any more coordination. The math doesn’t math.

3. The five places team productivity quietly evaporates

This is what shows up on the on-call rotation, the retro, and the 1:1 — but never on the velocity dashboard. For each one, Umaku surfaces a corresponding signal.

1. Duplicated work. Two engineers, working in parallel, build the same feature without knowing it. By the time the second PR opens, the first is partway through review. One goes in the trash. → Umaku catches this via the Sprint Inclusion agent’s overlap radar.
2. Half-aligned branches. Three engineers all need to touch the user model. None of them check what the others are doing. Two of the three end up reverting each other’s work over the course of a sprint. → Umaku catches this via the Code Quality agent flagging conflicting changes pre-merge.
3. Scope creep. AI made it cheap to “just also” add a thing. Without explicit coordination, the “just also” decisions stack up. The sprint was scoped for two features ships three half-features and one nobody asked for. → Umaku catches this via Code Quality reading the diff against the linked ticket.
4. Dropped handoffs. Engineer A finishes the back end Tuesday. Engineer B does not realise it is done. Engineer B starts the front end on Friday. Three days of clock time lost to the gap. → Umaku catches this via Sprint Inclusion surfacing in-flight work the moment a dependency lands.
5. Stale tickets. A ticket gets opened. AI-assisted development starts immediately on the work it described. The ticket itself never gets updated. Three weeks later, the PM looks at the board and has no idea what shipped. → Umaku catches this via Sprint Inclusion’s alignment score (closed tickets ↔ merged commits).

Notice what these have in common. None of them are caused by individual engineers being slow. All of them are caused by the team’s shared context being out of date by the time it would have been useful.

4. A concrete example: “Two PRs, One Feature”

The most common form of duplicated work — the one we hear about every customer call — is two engineers unknowingly building the same thing in parallel. It is worth walking through in detail because it makes the abstract argument painfully concrete.

The setup

Monday morning. Mei picks up UMK-512 (Refund status page) and opens a branch. She starts wiring up the page in the obvious place: a state module in `payments/`, a component in `web/`, a test next to it.

Tuesday morning. Tunde picks up UMK-518 (Refund status view) — a ticket that the PM wrote separately the previous week, ostensibly for a different surface but actually for the same feature. He opens a branch and starts wiring up the same three files.

Without Umaku

Both PRs grow in parallel for six days. Mei accumulates 9 commits, Tunde 7. By the end of the sprint, one of them opens for review and the other tries to merge — discovering, two hundred and forty file-changes deep, that they have built the same thing twice. The cost: eight engineer-days, two review cycles, one painful merge, and one feature shipped instead of two.

With Umaku

On Tuesday afternoon, the moment Tunde’s branch touches the second of the three shared files, Sprint Inclusion’s overlap radar fires. An agent card appears in both engineers’ inboxes: same module, same intent (78% file match, 100% intent match against the linked ticket descriptions). The choice surfaces immediately — merge tickets, or coordinate. Either way, the eight engineer-days are not spent.

THE THESIS IN ONE LINE Umaku does not make engineers faster. It makes the team’s coordination visible — so the speed the engineers already have actually arrives at the customer.

5. Why AI tools amplify the coordination problem

There is a temptation to say: well, will AI tools not eventually solve this too? The honest answer is that the current generation of AI coding tools is built around a single seat — your IDE, your repo, your local context. Their job is to make you faster. They have no idea what the engineer in the next pod is doing.

Worse, they accelerate the rate at which new context is created. Every AI-assisted PR adds new code that needs to be understood. Every AI-generated ticket adds new scope that needs to be reconciled. Every plausible-looking refactor needs to be checked against the contracts the original author had in mind. The cost of “what is the current state of this part of the system” goes up sprint by sprint, because the system itself is changing faster.

Umaku reads the corpus the team is already producing — the tickets, the commits, the PRs, the ADRs, the post-mortems — and exposes it as a continuously-updated picture of the work in flight. Where single-seat tools amplify production, Umaku amplifies coordination.

6. The actual bottleneck: shared context, not code production

Software delivery is a coordination problem. It has always been a coordination problem. AI tools accelerated the part of the problem that was not the bottleneck — production — and left the part that was the bottleneck — coordination — untouched.

Shared context is the answer to a set of questions every team asks every sprint:

• Who is working on this right now?
• Has this been built before?
• What did we decide last time this came up?
• Is this PR fitting the contract the module is supposed to honour?
• What is actually going to ship at the end of this sprint?
• What did we commit to that has not started yet?

The team that can answer these in seconds has a working coordination layer. The team that has to Slack-archaeology each one is paying the coordination tax on every interaction, every sprint, forever. Here is what “answer in seconds” looks like inside an engineer’s IDE:

ASK UMAKU Is anyone already building the refund status page?

CITED ANSWER  ·  8s Yes — Mei opened PR #1184 (feature/refund-status-page) on Monday against UMK-512. 9 commits so far, touching three files you would also need to modify. The ticket overlaps with your assignment UMK-518 at 100% intent. Consider merging the tickets or coordinating before opening a parallel branch.

Eight seconds. Cited. The other engineer named, the PR linked, the ticket overlap calculated. That is the queryable-corpus property in action — and it is the layer that closes the coordination tax.

7. Why dashboards are not enough

Velocity dashboards measure individual output. Commit counts going up. PRs merged. Tickets closed. They tell a confident story.

What they do not show:

• Two of those merged PRs implemented the same feature.
• A third of those closed tickets had no matching commits.
• Sprint scope was changed quietly mid-sprint and nobody quite recalls who agreed to what.
• Three of the senior engineers spent fifteen percent of last week answering “what is the status of X” questions that should have had a self-service answer.

The dashboard says the team shipped. The on-call rotation says something different. The retro says something different. Eventually the CFO notices that “ten times faster” is not showing up in the actual delivery cadence and starts asking pointed questions.

8. What engineering leaders should measure instead

Three numbers worth tracking, none of which appear on a standard velocity board. Each one is something Umaku surfaces every sprint.

Overlap rate. How often, in a given sprint, do two pieces of work in flight touch the same surface area without one engineer explicitly signed off on the other’s plan? A team operating well keeps this under 10%. A team in coordination debt runs 25–40%.

Alignment score. How tight is the match between what the sprint scope said the team would ship and what actually got merged? Closed tickets without commits, and commits without tickets — both count against alignment. Below 80% means you are not actually sure what you shipped.

Time-to-context. When a senior engineer asks “what is the current state of the refund flow?”, how many seconds does it take to get a cited answer? Under thirty seconds means you have a queryable system. Over five minutes means your context lives in heads and Slack threads.

9. Where Umaku fits

Umaku is built on a simple premise: in an era of cheap code, the binding constraint on team productivity is shared context. So make it queryable, and put four agents on top to score each dimension every sprint.

• Sprint Inclusion catches the alignment gap — closed tickets without commits, commits without tickets, overlap rate, descopes that nobody remembers agreeing to.
• Code Quality flags scope drift in the diff before merge by reading each change against the linked ticket and the module’s stated contract.
• DevOps Compliance holds infrastructure changes to their runbooks — flagging plausible-looking infra that ships without DLQs, alarms, or owners.
• Bugs Finder pattern-matches diffs against known logical-bug shapes.

Underneath the four agents is the queryable corpus from Figure 8 — the same corpus the IDE chatbot reads to answer questions like the one in §6. That layer is what makes the agents context-aware rather than rule-based: when Code Quality flags a scope drift, it can point at the ADR the diff violates. When Sprint Inclusion flags an overlap, it can name the other engineer’s PR.

The piece that matters most for the coordination problem in this essay is the overlap radar. When two engineers open branches that touch the same files within the same sprint window — or when two tickets describe overlapping scope — Umaku surfaces the overlap before both PRs are deep in review. Two PRs. One feature. Caught on day one, not at merge.

Takeaway

If you bought ten times more typing, congratulations — you got it. But typing was not the bottleneck. Coordination was.

The next year of engineering organisation design will be won by the teams that treat shared context as infrastructure: something you build, something you measure, something you hold to a standard. The teams that do not will keep paying the coordination tax in retros, on-call rotations, and CFO meetings where someone has to explain why ten-times-faster engineers produced one-and-a-half-times-faster delivery.

Code is cheap now. Coordination is the new currency. Umaku makes it visible — sprint by sprint, PR by PR, question by question — so the speed you already bought actually arrives where it was supposed to go.

NEXT STEP Pick one sprint. Measure overlap rate, alignment score, and median time-to-context against the targets in §8. If any of the three are out of range, you are paying a coordination tax that Umaku will surface in 30 days — and start closing in the same window.

Build with clarity, deliver with confidence.

Umaku is built by Omdena to help engineering teams close the gap between what they intend to build and what actually ships. We’re working on the judgment layer of modern engineering: context-aware code review, alignment between intent and artifact, and a queryable knowledge base that engineers — and the agents they work with — can ask questions of. Comments, critiques, and pushback are welcome.

Umaku is built by Omdena.