# The playbook behind teams that 2x'd productivity in Q1

_Published August 24, 2026_

**By [João de Paula](https://mesmer.co/resources/author/joao)**

**Section:** Playbook

> **TL;DR.** Hundreds of teams have connected their code and project data to Mesmer, and the ones that moved 2x+ faster in Q1 share a playbook. Humans stopped writing code directly, agents get triggered by alerts rather than by people, review moved off the human critical path in four stages, codebases were reshaped for retrieval, and pods shrank to two or three engineers per bet.

---

Mesmer helps engineering teams figure out how to actually make
agentic engineering work. Hundreds of teams have connected their code
and project data to us, which lets us see patterns across the work
that thousands of engineers do day to day. We supported several
companies as they started moving 2x+ faster in Q1.

![Line chart titled 'Random sample of 5 customers' showing productivity per engineer per month, normalized to November 2025, for five Mesmer customers from November 2025 through April 2026. All five customers gained: Customer A +145%, Customer B +122%, Customer C +115%, Customer D +66%, Customer E +50%. Customers D and E dipped below zero through January 2026 before climbing in February and accelerating through April.](/blog/cohort-productivity-lift.png)

*A random sample of five customers, productivity per engineer per month, normalized to November 2025. The lift shows up at the top, the median and the bottom of the curve — including the two customers who spent the first three months in negative territory.*

Two things in that chart are worth more than the headline number.
The first is that the gains are not a tail effect: the bottom of the
sample moved along with the top. The second is that the two customers
who ended up at +66% and +50% were both *below* their November
baseline as late as January. Adopting this playbook costs you a
quarter before it pays, which is roughly how long it takes to
dismantle a review process built for human-speed volume.

Looking closely at the teams above 100% gains, it is clear they are
running a different playbook — not a different tool. The tooling is
broadly the same tooling everyone has. What follows is what they do
with it.

That distinction matters because the honest research on individual
AI-assisted productivity is not flattering. METR's randomized trial
found experienced open-source developers were
[19% slower with AI tools while believing they were 20% faster](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/).
Handing agents to an org that still runs on human-speed rituals
produces exactly that. The teams below changed the rituals.

## Humans no longer write code directly

Agent-first is a policy in these teams, not a preference. Even a typo
goes through an agent. It sounds performative until you watch what
happens without it: senior engineers revert to muscle memory on
anything urgent, because typing the fix themselves feels faster in
the moment, and the team plateaus at last year's ceiling. The
forcing function is the point.

The tell we see in the data is variance. In orgs without a policy,
agentic attribution is bimodal — a few engineers at 90%, a long tail
near zero, and the tail is usually the most senior half of the team.

## Trigger agents automatically

Automated triggers are the practice of letting systems, not people,
start the work. The pattern that shows up repeatedly:

1. A Datadog alert fires at 3am. An agent investigates, patches, runs
   the tests, opens a PR.
2. Another agent reviews it. Comments get auto-resolved until it is
   ready for human eyes.
3. A human looks at it during working hours and throws away half of
   what arrived overnight.

That last step is the one people resist, and it is the cheapest step
in the chain. Throwing away half of the PRs is fine when they were
cranked out overnight for the price of a cup of coffee. Judging
agent output by the hit rate you would demand of an engineer is a
category error — you are paying for attempts, not for hours. It also
means you need to be able to see the discarded half, which is why we
[measure work that never sees the light of day](/resources/discarded-work)
separately from work that ships.

## Move the review bottleneck off humans

Review gating is a four-stage chain that keeps humans off the
critical path for everything except genuinely risky changes. When
agents multiply the volume of work produced, the bottleneck moves to
whatever still runs at human speed — usually code review. These
teams gate in stages:

1. An AI reviewer catches style, lint, missing tests, obvious bugs.
2. The writing agent resolves those comments.
3. A risk-judgement agent evaluates what is left — blast radius, data
   sensitivity, auth surface — and routes high-risk PRs to a senior
   engineer with most of the noise already stripped out.
4. Ephemeral environments per PR let less-senior engineers
   green-light low-risk work themselves.

Median cycle time drops by an order of magnitude. The failure mode to
watch for is a review layer that produces findings nobody acts on,
which is why we
[grade every merged PR](/resources/pr-quality) rather than trusting
that review happened because a reviewer was assigned.

## Optimize the codebase for agents

An agent-legible codebase is a codebase where retrieval is cheap.
Three changes do most of the work:

- **Monorepos.** Cross-repo work is where agents lose context first.
  Google's argument for
  [storing billions of lines in a single repository](https://cacm.acm.org/research/why-google-stores-billions-of-lines-of-code-in-a-single-repository/)
  was about atomic changes and visibility for humans; the same
  properties are what let an agent see the whole change it needs to
  make.
- **Domain-driven design is back.** Agents work best when codebase
  terminology matches the language the support team and customers
  actually use. Renaming internal jargon to the business's own words
  is exactly Evans's
  [ubiquitous language](https://martinfowler.com/bliki/UbiquitousLanguage.html),
  and it is now worth real money.
- **File consolidation.** Kill the file jumps. Agents fail at one of
  them every time. Co-locate business logic with the data it cares
  about.

Bonus, and the highest-ROI thing on this whole list: set up a
self-improving `CLAUDE.md` / `AGENTS.md`. An agent runs weekly,
reading PR comments and agent failures, and updates the instructions
file. Reset it every month so it does not accumulate cruft.
Anthropic's own
[guidance on agentic coding](https://www.anthropic.com/engineering/claude-code-best-practices)
points the same direction — the instruction file is the single
highest-leverage file in the repository. Ours is maintained the same way,
through [workflows that run on a schedule](/resources/workflows).

## The org chart changed

The pod is the unit that changed shape. Four patterns, consistently:

1. Pods got smaller and project-oriented. Five to eight engineers
   owning a domain became two or three engineers assigned to a
   two-to-six-week bet.
2. Domain ownership rewards protecting your piece of the product.
   Mission-oriented pods reward getting stuff done and moving on.
3. PMs and designers shifted from gating engineering to acting as
   internal consultants. Nobody approves roadmaps anymore.
4. Engineering managers split into one of two roles: a pure people
   manager with 20+ direct reports, or a mixed IC/manager/consultant
   working across pods.

## Hiring is different

The engineer who shines in this context is a generalist, not the
specialist who can focus on a single task for hours. What these teams
select for:

- **Range** — generalists who move across the stack, now including
  product and design.
- **Judgment** — knowing when to ask for help, and how to navigate
  a decision with incomplete information.
- **Fluency** orchestrating many agents in parallel.
- **End-to-end ownership** without handoffs.

The take-home test that actually works is one that is impossible to
ship in two days without agents, with the session log submitted
alongside the code. The log is the artifact you are grading. If you
are rebuilding a hiring process around this, the mechanics of running
it — one owner per decision, written criteria, structured interviews —
are in
[what I learned about hiring and firing](/resources/hiring-and-firing-scaling-to-150).

## Structured days

A structured day is the practice of capping how many agent threads
you run at once. Working on five priorities at once feels great at
the start of the day. By 2pm you cannot process anymore: wrong
context, wrong PR, an afternoon spent recovering from a five-minute
mistake. The teams that sustain high concurrency cap parallel threads
at two or three, bracket the day with short agent-probing windows for
small fixes and triage, and protect focus in between.

## Methodology

Our measurement approach is the reason these numbers are not just
commit counts. We built a model that analyses the effort behind
commits based on complexity, attributes agentic code, and excludes
discarded work — because traditional productivity metrics do not
translate to AI-native engineering. Lucas wrote up which of the
classic frameworks survive that shift and which do not in
[life after DORA](/resources/life-after-dora-agentic-eng-metrics).

If you are curious about any of this, or have a different angle on
what is working, reach out at
[joao@mesmer.co](mailto:joao@mesmer.co). Always happy to compare
notes, especially if there is another bottleneck appearing in your
operation, or you have thoughts on the patterns above. If you would
rather see where your own org sits first,
[book a diagnostic call](/book-demo?source=playbook) and we will walk
your data.

If this was useful, see also
[life after DORA](/resources/life-after-dora-agentic-eng-metrics) for
the measurement side of the same shift, and the rest of the
[Playbook column](/resources/playbook) for the individual
plays.

---

Canonical: https://mesmer.co/resources/agentic-engineering-playbook-q1