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

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.

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. 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 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 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 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, 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 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.

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.

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.

If you are curious about any of this, or have a different angle on what is working, reach out at 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 and we will walk your data.

If this was useful, see also life after DORA for the measurement side of the same shift, and the rest of the Playbook column for the individual plays.