Field Guide to Agentic Engineering Transformation— Full Text

Introduction

What this is

Coding agents are here. Mandates are everywhere. Adoption metrics are climbing. Yet most organizations rolling out these tools aren’t actually transforming — they’re running a tools deployment and calling it a transformation.

Real change requires culture change in your people and deliberate investment in the technical foundation agents work on. That’s what this guide is about.

The main takeaway: the people in your organization are the unit of transformation. They learn this by doing it, not by being told. Until they’ve personally experienced agentic coding lowering the cost of starting something they’d been putting off, you don’t have a transformation. You have a tools rollout.

Two tracks of agentic work run in parallel. Developer-steered work keeps the engineer in the loop, steering an agent through real implementation. Unattended work lets agents handle well-defined tasks without an engineer in the session: security patches, dependency updates, routine maintenance. Both deserve investment. This guide puts most of its focus on the developer-steered track because the transformation is fundamentally a culture change in your engineers, and you can’t shortcut that with automation. The unattended track is real, important, and addressed in the measurement chapter, but it’s a second engine, not the primary one.

This guide describes what worked when one engineering organization went through the change. It is not a guide to using the tools — those practices change every few weeks. It is not about adoption metrics or AI-usage performance ratings. It is about the leadership work that produces sustained productivity and business outcomes.

About that organization: roughly 200 developers, plus designers and product managers. Large enough to need real coordination, small enough that a leader could still see most of the work. The patterns here are likely to translate to organizations in the 50–500 range. They may not translate cleanly to 2,000-developer organizations, where coordination problems become operationally different.

The transformation is harder than the hype suggests and slower than the demos imply. If you’re expecting a quick win, this guide will disappoint you. If you’ve started and want to do it well, you’re in the right place.

How to use this

The chapters can be read in order. They’re arranged roughly in the order the work unfolds. If you’re stalled, jump to the chapter that describes where you’re stuck and look for the Stalled callouts. There are four callout types throughout:

• Stalled → Specific guidance for transformations that have hit a wall.
• Culture → Notes on the human and leadership side of the change.
• Developer steering → Practical tips for working with agents hands-on.
• Watch out → Predictable traps to avoid.

The implementation in your organization will be your own. Take the patterns here as input, not prescription. Adapt them to your situation.

The Moment That Changes Things

The industry has built a hype cycle around agentic coding. Some of it is real. Most of it skips the broader parts that matter: quality, maintenance, what actually works on your codebase. Developers know this. Telling them the tools are better doesn’t move them. Showing them metrics doesn’t move them. Watching someone else succeed isn’t enough.

What moves them is doing it themselves, on their own work, and discovering that something they wouldn’t have attempted is suddenly within reach.

That’s the moment. The guide is about creating it at scale.

The shift in what feels possible

The cost of starting has dropped to minutes. The cost of trying has dropped to hours. The project you’ve been putting off because it would take a quarter — try it in an afternoon. The refactor nobody wants to touch — let an agent take a first pass. The cross-platform feature that needs three teams to coordinate — scaffold it in 45 minutes from a single prompt.

You’re not asking people to finish the impossible thing. You’re asking them to attempt it.

Two kinds of moment, both necessary

Two patterns produce real change:

The exploratory moment. Low stakes, no audience, no deadline. Someone tries something on their own time, expects it to take hours, watches it work in minutes. This produces curiosity. It gets people experimenting on their own.

The pressure moment. Real work, real stakes, no time for the old way. Someone reaches for an agent because they believe it will help. Results come back faster than they could have produced themselves. This produces conviction. It changes daily practice.

Curiosity gets people experimenting. Conviction changes how they work. Both together produce engineers who keep building on it.

Stalled → If your adoption metrics are climbing but the work hasn’t changed, you have curiosity without conviction. People are playing with the tools. They haven’t depended on them for something that mattered. The fix isn’t more communication or training — it’s creating situations where the tools become the path of least resistance for stakes-bearing work.

Why this is a culture change, not a tools rollout

The shift is in the engineer’s relationship to their work. What they consider possible. What’s worth attempting. How long things take. What it means to be the person who builds something.

That’s a culture change. Tools can be deployed. Cultures shift one person at a time, on their own timelines. Treating the transformation as a tools project will succeed at the tools and fail at the rest.

Culture → You can’t shortcut this. The pull will be to communicate harder, train more, set adoption targets. None of those produce the shift. The timeline is set by how fast people can have the experience, not by how fast you can describe it.

Identity Struggles

Before you can create the moment at scale, you need to understand who you’re creating it for. Some people will take to agentic coding fast. Others will resist, even when they’re objectively good with the tools. The pattern isn’t about skill or seniority. It’s about identity — how a developer thinks of themselves and what they value about their work.

Treat the people pushing back as obstacles and you’ll lose some of your best people. Treat them as people working through a meaningful change and most come out the other side, often becoming your strongest advocates.

Two ends of a spectrum

It’s an over-generalization based on patterns I’ve seen, but a useful one. Most developers fall between two poles:

Craft-focused developers enjoy the practice of writing code. High bar for quality. Value elegant, idiomatic solutions. Code is the work; there’s an optimal version worth aiming for.

Product-focused developers enjoy what gets built. Code is a means to an end. “Good enough” is good enough. Iteration speed and reduced non-value time are what matter.

Both can be excellent at agentic coding. They struggle with it for different reasons.

What craft-focused developers feel

The craft-focused developer’s work is partly about it being theirs. They wrote it. They chose the patterns. The code reflects their judgment, and that judgment is part of how they know they’re good.

Agentic coding scrambles this. The agent makes the small decisions. The code is workable rather than optimal. The work gets done, often faster, but it doesn’t feel like theirs.

This isn’t irrational. It’s a real loss, and ignoring that makes it worse.

What helps is acknowledging the loss and showing where their craft matters more, not less. The high bar didn’t become useless when agents started writing code. It moved. The agent will produce something workable; the craft-focused developer notices when “workable” isn’t actually right, pushes back on subtle architectural mistakes, and maintains the standard for what good looks like across many people doing the writing. That’s a more leveraged role than they had before.

Culture → Craft is something craft-focused developers have always expanded. New languages, new paradigms, better tools — each one initially looked like a shortcut and ended up part of the work. Agentic coding is no different. Help them see it as the next chapter of their craft, not the end of it.

What product-focused developers feel

Product-focused developers usually take to agentic tools fast. The speed gains are immediately appealing. The tools amplify what they were already trying to do.

The risk isn’t resistance. It’s the opposite. They race ahead in ways that compound problems for everyone else. Quality drops when nobody’s watching. Architecture drifts. Code review gets cursory because reviewers can’t keep up with the volume. They experience this as productivity. The codebase experiences it as accumulating technical debt.

What helps is making sure the quality bar travels with the speed. Pair them with craft-focused developers. Make code review a real activity. Watch what’s happening in the codebase, not just what’s shipping.

Watch out → A team where everyone is product-focused will ship faster for a while and pay for it later. If you’ve shifted toward all-product-focused thinking because it’s been working, that’s the signal to slow down and check the foundation.

People who care deeply

Cutting across the craft/product spectrum is a third pattern: people who care deeply — about their work, their team, doing things right. High purpose, high empathy, high conscientiousness. Often among your best contributors.

They can also take longest to embrace the change.

Because they care, they ask hard questions. They worry about consequences others don’t. They notice losses others miss. They don’t switch positions casually. This can look like resistance. It usually isn’t; it’s processing.

What helps is time, honesty, and some control. Give them time to work through it. Be honest about what’s uncertain. They’ll spot dishonesty and trust will be hard to recover. Give them some control over how the change happens for them or their team. The thing they care about most might be the place to let them lead.

When this is done well, the people who took longest often become the most invested advocates. When they finally commit, they commit fully. They become the people who carry the change forward when you’re not in the room.

Stalled → If your transformation has lost the people who care deeply, you have a serious problem upstream of the tools. Something about how the change was led signaled that what they care about doesn’t matter. Address it directly.

Signals to watch for

A few patterns that say someone is struggling with the identity dimension, regardless of which group they’re in:

• Polite under-engagement. Doing what’s asked, not pushing back, not really showing up. The most common signal and the easiest to miss.
• Quality loss without acknowledgment. Code quality dropping but nobody saying so. Often craft-focused people checking out rather than fighting.
• Volume without meaning. Lots of pull requests, lots of agent activity, no real change in what’s getting shipped.
• Quiet conversations you’re not part of. When the most invested people are talking to each other instead of to you, the leadership relationship is breaking down.

None of these are problems you fix with a process. They’re problems you fix with attention and individual conversation.

Creating the Moment

You can’t tell people to experience the moment. You cultivate the conditions for it.

That sounds passive. It isn’t. The work is real and demanding, and it has a structure: each layer of people who’ve had the moment becomes the engine for creating it for the next layer. You start with yourself. You build a small group. The small group enables team-level coaching. Team coaching enables organization-level events.

Stalled → This people-centric work runs in parallel with the technical work in the next chapter — not in sequence. Coaching sessions on a codebase the agent can’t reason about produce frustration. Hackathons that depend on agent productivity in unprepared repos produce demos that don’t ship. If you’re stalled, check whether you’ve been treating these as sequential phases.

Layer one: yourself

Before any of this can spread, it has to be real for you.

If you’re leading the transformation, you need to be using the tools yourself, on real work, with the same constraints you’re going to ask others to accept. Engineers can tell when someone is selling them on something they haven’t used.

This is harder if you’re not currently writing code. Pair with a developer who’s open to the transformation. Work through a real ticket together. Build something small for your own team’s tooling. The point isn’t to become a working developer again. It’s to have first-hand experience with what you’re asking everyone else to do.

The credibility this earns is significant. I tried this last week with our code, and here’s what happened is a different conversation from one where you cite metrics or quote vendors.

Culture → If you haven’t written code in years, the discomfort of getting back into the tools is part of the work. Don’t skip it. Your team is watching whether you’re willing to do what you’re asking them to do.

Layer two: a small group of agentic leaders

Before team-level coaching, you need a small group who’ve had the moment and can help create it for others. These are early adopters, but treating them as evangelists misses what they actually do.

Their real job is to test the hype against reality. They try things, find what works and what doesn’t, and report back. They become the people other engineers ask when they’re stuck or skeptical. They share what they’re learning in informal venues, and the sharing builds the social proof that pulls more people in.

Grow this group deliberately:

• Look for curiosity, not seniority. The first adopters aren’t always your strongest engineers. They’re the ones willing to play with new tools on their own time. Some will be junior. That’s fine.
• Create a recurring venue. Weekly or biweekly. Whoever has been doing something interesting comes and shows. Low-stakes, no agenda, no requirement to attend. Early sessions will be sparse. Attendance grows.
• Encourage boundary-pushing. Don’t constrain them with how work was done before. Let them surprise you.
• Watch the stories that come out. When someone demos that an agent scaffolded a cross-platform feature in 45 minutes, the response from their team isn’t skepticism, it’s how do I do that? That’s the social proof loop starting.

Stalled → If you’ve rolled out the tools and adoption is climbing but no internal practitioner group has emerged, the gap is usually a venue. People are using the tools privately. Without a place to share, experiments don’t compound. Create the venue, even if only two people show up.

Layer three: team-level coaching

Once you have a small group, you can create the moment for whole teams at a time.

The format that works: bring a team together for a fixed block, three or four hours, and work through real backlog items together with agents, hands-on. Not a demo or a workshop. Real work, in their codebase, with their constraints. Pick something the team thought was impossible.

Coaching session run-of-show (~4 hours):

A few things make this work:

• Pick real work, not exercises. Hypothetical problems produce hypothetical learning. Real backlog items produce real outcomes the team has to integrate.
• Cross-repo context matters. Most real work doesn’t live in one repo. The patterns the team learns about cross-repo context become the patterns they use for the rest of their work.
• No manual coding during the session. Harder than it sounds. The instinct, when an agent gets stuck, is to take over and type the fix. The point is to keep the developers in the steering role.
• Prompting and context are the skills being taught. Make them explicit as they come up.

The output of a good session is two things: real work moved closer to done, and a team that has had the moment together. They’ll talk about it for weeks. Some will become your next layer of agentic leaders.

Developer steering → The most common failure mode is teams skipping the planning step and jumping to “build me this feature.” The agent needs context and intent before it can produce anything useful. Make planning conversations part of the session itself.

Layer four: hackathons

Hackathons come when enough people have already had the moment. Run them too early and they produce demos that lack scale. Run them at the right time and they’re when the transformation becomes visible to the entire organization.

A few things matter:

• Set rules that match the practice. No manual coding, real work that affects the product or business, agent-led implementation.
• Include non-developers. Product managers, designers, program managers. The work they produce with agents is often the most interesting output. It also signals the transformation isn’t an engineering thing.
• Use it as a momentum gauge. The number of people who show up, the energy in the room, what they attempt — all of it tells you where the organization actually is.
• Watch for innovation, not just execution. The interesting outputs are rarely the planned roadmap items finished faster. They’re the unplanned bets people made because the cost of trying was suddenly low.

Watch out → A hackathon run before the layers underneath are ready will produce a memory people use against you. We tried this and it didn’t work is hard to recover from. If you’re not confident the layers are there, run more team-level coaching first.

What this looks like over time

These layers don’t run hard forever. After enough cycles, the flywheel sustains itself. The early adopter group keeps growing. Team coaching keeps happening, often led by people you’ve coached. Hackathons become an occasional rhythm rather than a regular event. You stay involved, but it’s lighter.

The point at which the transformation runs without you is the point at which it’s actually working.

Culture → Many leaders find this disorienting. The temptation is to keep being central. Resist that. Your job at this stage is to make sure the layers stay healthy, not to keep being the engine.

Teaching Agents Your Platform

This is the technical track that runs in parallel with the people work. The two depend on each other. A coaching session on a codebase the agent can’t reason about produces frustration. A well-prepared codebase with no engineers willing to use it produces nothing.

The work goes by several names: agent enablement, platform readiness, context engineering. The shape is consistent. You’re teaching agents your platform so they can be effective on the code your business actually runs on.

The greenfield trap

Most demos of agentic coding happen on fresh repositories. Someone types a one-shot prompt. An app appears. The video gets shared. Everyone is impressed.

Your codebase is not that codebase. Yours has years of accumulated convention, multiple frameworks layered on each other, half-deprecated patterns nobody’s removed, and tribal knowledge that lives in people’s heads and old chat threads. An agent looking cold at your codebase will produce code that compiles, that solves the problem in a vacuum, and that violates a half-dozen unwritten patterns the team has been carrying for years.

The team will conclude, reasonably, that the tools don’t work on real code. The work of building the bridge between agent and codebase is what this chapter is about.

Watch out → When external companies ask about our transformation, our focus on existing codebases is what resonates the most. Greenfield agentic coding is the easy case. Real value lives in making agents productive on the code your business already runs on.

What teaching the agent your platform means

You’re giving the agent the kind of context a new senior engineer would need to be effective. Not a syntax reference. The patterns, conventions, and decisions an experienced person on your team would explain in their first week:

• Frameworks and component patterns. What UI library, what conventions, what backend service patterns are standard, what’s the routing model, the state management, the auth flow.
• Integration patterns. How services talk to each other. Where API boundaries live. The contract between frontend and backend.
• Tooling and testing expectations. What runs in CI. What test patterns are required. What “ready to merge” actually means.
• What’s deprecated. This matters more than people realize. Codebases accumulate old patterns alongside new ones. An agent that sees both will sometimes choose the wrong one. Tell it which is which.

The agent uses this context to produce code that fits your codebase rather than fighting it.

In practice, this context starts as something developers create on the fly during agent sessions. They explain a pattern, the agent uses it. Nothing is captured anywhere yet; it’s all in the moment of the session. The work over time is to migrate that context into shared resources everyone can leverage, so the next developer doesn’t have to discover the same thing the next time. The transition from “developer in the room with the agent” to “knowledge available to all agents in all sessions” is what scales the investment.

Developer steering → The inventory will feel infinite. Don’t try to document everything at once. Start with the patterns coming up most often in agent sessions where the agent is producing wrong-shaped code. Each fix becomes a new piece of context. Over time the document set covers what matters.

The bidirectional model

Treat the knowledge base as a living system, not a static resource.

Agents read your patterns when they work on your code. That’s the baseline. But sessions also surface gaps. Patterns that aren’t documented, edge cases that produced unexpected behavior, conventions that matter but aren’t written down. The developer notices it during the session, corrects the agent, explains the missing context, and asks the agent to capture it as a documentation update.

The proposed update goes through review like any other contribution. Some get merged. Some get rejected. Some get edited. The knowledge base grows from real working sessions rather than from a documentation project.

Two things this gives you. The documentation stays close to reality, because it comes out of real work. And the agents you have now help build the context that makes the agents you’ll have next year more effective.

Local-first workflows

When an agent can write code and run it locally — execute the test, see the output, react to the failure — the feedback loop tightens dramatically. The agent verifies what works in seconds. It can catch its own mistakes. It produces better code with less back-and-forth.

When the workflow requires pushing code to a remote environment to validate every change, the loop stretches to minutes or hours. Iteration slows. The cumulative effect over a long session is large.

Investing in local executability — branches that can be tested without long deploy chains, local test runners that match CI, environments that come up fast — pays back twice. Agents work better in tight feedback loops; developers do too. Sell it as a developer experience investment that happens to also unlock agent productivity.

Stalled → If your developers were already frustrated with slow feedback loops before agents arrived, agentic transformation will amplify that frustration. Agents can’t recover wins that developer experience is bleeding away. DX investment is one of the highest-leverage things you can do.

Watch out → Coaching sessions and hackathons can get hijacked by environment friction. One team came into a session planning to build a feature and spent most of the time fighting deployment infrastructure. The agent had working code in under an hour; the environment couldn’t accept it at that speed. The session turned into an infrastructure debugging exercise.

The technology will keep changing — the work won’t

Right now, the ways to give agents context are evolving fast. We’ve used several approaches:

• Direct context injection. Files and folders pasted into prompts.
• Repository-resident files. Markdown documents at the root of each repo that get included automatically in agent context.
• Knowledge bases as MCP tools. Structured collections of documents the agent can search, read, and contribute back to.
• Skills. Combinations of markdown, scripts, and CLI tools that bundle a capability the agent can invoke.

Six months from now there will be more options than there are today. Trying to pick the right one is mostly a distraction.

What’s important is the content of the context. Inventorying your frameworks. Writing down your conventions. Documenting decisions and why. Capturing what experienced engineers know but isn’t written anywhere. None of that becomes obsolete when the delivery mechanism changes.

What you’re building, across all of this, is a system where agents are first-class participants in your platform, with access to the same knowledge experienced engineers have, the same tooling, and increasingly the same ability to contribute to both. Some teams call this the agent-legible environment. Investment in legibility is what turns the cultural moment into sustained momentum.

It's Not the Plan; It's the Planning

Once developers are using agents on real work, the next failure mode appears. Teams jump to execution. The agent produces something. It’s not quite right. They prompt again. Still not right. They prompt a third time, get something workable, ship it, and conclude the agent did its job.

That workflow looks productive. It misses what the planning step would have caught.

We saw this play out concretely in one of our early team sessions. The team had picked a real backlog item — a new service to build out — and went straight from describing the feature to asking the agent to implement it. The agent produced something plausible. Halfway through, someone noticed it was missing a key architectural constraint. The agent rewrote the service. Then the next constraint surfaced. The agent rewrote it again. By the third rewrite, the team realized they’d skipped the part where they aligned on how the service should be built before letting the agent build it. The thirty minutes of planning they didn’t do cost them most of the session.

The lesson stuck. The team’s retrospective named it directly: collaborating on the plan was essential.

Code is the easy part now. Deciding what to write is the hard part. The leverage isn’t in how fast the agent produces code — it’s in how much thinking happens before the agent starts. Skip the thinking and you’ll get fast output that doesn’t fit the problem. Do the thinking and you’ll get less iteration, better fit, and code that integrates cleanly with what already exists.

Why planning matters more now

Pre-agent, planning happened in your head while you were typing. You’d start a function, realize you needed to refactor first, abandon the function, do the refactor, come back. The plan emerged through the act of writing. Thinking was bound to typing.

Agents break that binding. The agent writes code very fast, and it commits to an approach as soon as you ask. If your thinking hasn’t caught up to your typing speed, the agent runs ahead of you. By the time you realize the approach was wrong, you have hundreds of lines that need to be undone or rewritten.

The fix is short, focused thinking before code generation. Five or ten minutes that saves an hour. This isn’t a return to waterfall design — engineers have always benefited from “go slow to go fast.” What’s new is the cost of skipping it. The agent runs ahead of you faster than you can correct it.

Developer steering → The single highest-leverage habit is asking the agent to study the problem and propose a plan before writing any code. Three things to ask for: what’s the problem actually asking for, what are two or three possible approaches, and what are the trade-offs between them. You’ll catch most architectural mistakes here, when fixing them is free.

What developer-steered agents means

A particular workflow:

• The developer brings the intent: what’s being built, why, what constraints exist.
• The agent brings the implementation: code, tests, documentation, refactors.
• The developer steers: reviewing the plan, redirecting when off, catching mistakes early, asking for alternatives.
• The developer commits: the work is the developer’s, even though the typing wasn’t.

The developer is in the loop, but not for typing. They’re in the loop for judgment. Where to start, what trade-offs matter, when an approach is wrong, when to stop and rethink. Those are decisions the agent shouldn’t make alone.

This is different from “let the agent figure it out.” That’s fine for low-stakes throwaway work. It’s not how to operate on real production code.

What good planning looks like with an agent

A few patterns that make the planning conversation productive:

Start with context, not the task. Before you ask the agent to plan anything, give it what it needs to plan well. The relevant repos and documentation, the relevant existing patterns, the constraints that aren’t obvious from the code. We use this auth pattern, not that one. This service handles X, that one handles Y. The team’s convention for error handling is here. The agent’s plan is only as good as the context it has.

Ask for options. Two or three possible approaches with their trade-offs. The first plan an agent produces is rarely the best one — it’s the most obvious one. Asking for alternatives forces the agent to reason about the space, and forces you to make a choice you can defend.

Choose the pragmatic path explicitly. Once you have options, pick one and say why. We’re going with approach two because it reuses existing infrastructure and we don’t want to introduce a new dependency right now. Stating the choice explicitly anchors the agent for the rest of the session.

Adjust the plan before any code generation starts. This is where developer judgment directs the agent. Read the plan. Mark what you’d change. Push back on assumptions. The plan is cheap to revise. The code that gets generated from a bad plan is not.

Developer steering → A common mistake is treating the plan as a deliverable instead of a tool. The plan is for you. Use it to think clearly, then use it to communicate the change in source control, but don’t optimize the plan for someone else’s reading. Optimize it for clarifying your own intent.

Cognitive debt

Technical debt accumulates in code when you take shortcuts. Cognitive debt accumulates in your head when you stop fully understanding the codebase. It happens slowly. The agent writes code. You skim it. You approve it. Repeat for a couple weeks and your mental model of how the system works gets hazy. You can no longer reason about the system from first principles.

Planning is one of the main ways to fight it. When you make the agent walk through the problem before writing code, you’re forcing yourself to engage with the design at a level surface-skimming doesn’t reach. You’re rebuilding the mental model that typing the code used to build for you.

Watch out → If you find yourself approving PRs you couldn’t explain, you’re already in cognitive debt. Slow down. Spend more time in the planning conversation. Ask the agent to walk you through the trade-offs even on changes you’d normally skim.

Multiple sessions, one developer

Once a developer is good at planning, steering, and review, they can run more than one agent session at a time. That’s one of the larger productivity unlocks in the model.

The number you can sustain isn’t the number you can start. It’s the number you can steer well. Two is comfortable for most. Three is challenging. Four is probably too many. Routine work scales further than novel work. A developer running four agents poorly is not better than one who runs one well.

The Shape That Emerges

The new operating model isn’t something you design. It’s something you let emerge.

Teams that have made the shift will start proposing how they want to operate: which ceremonies still serve them, which don’t, how work flows, what the cadence should be. Your job is to recognize what they’re proposing, support what works, and resist standardizing what doesn’t need standardizing yet.

The shape that tends to appear

A few patterns show up across teams:

• Smaller, more fluid working groups. Pairs or trios can do work that used to require a full team. Single developers can credibly handle features that took small groups. Teams stay as the unit of accountability; working groups inside them become more fluid.
• Cross-platform work by default. “Android developer” or “Backend developer” begins to blur. A developer with agent help can work productively across stacks they don’t natively know. Specialists still maintain patterns and standards, but more people can pick up more kinds of work. Teams that used to stall waiting for a specialist keep moving.
• Developers participating in shaping the work. Developers, who now have time and tools to explore quickly, become natural contributors to “what do we build” conversation. The role boundary between “who decides what to build” and “who builds it” softens. This shift is uncomfortable for organizations with rigid functional silos.
• Faster, lighter ceremonies. Long planning meetings get replaced by shorter, more frequent ones. Retros look different — less about velocity, more about which experiments worked. Standups change shape because what I’m working on is no longer a one-day question.
• A new bottleneck upstream. Workflows that ran smoothly when execution took weeks don’t run smoothly when execution takes days. Planning, design, and decision-making become the rate-limiting steps.

Stalled → If your engineering teams have shifted but the rest of the organization hasn’t, the bottleneck moves to wherever the slowest decision-maker sits. Engineering capacity goes underused, not because engineers stopped working, but because they’re waiting on inputs that used to arrive faster than they could be consumed. Fixing this is a leadership conversation upstream of engineering.

Pace, parallelism, and the limits of intensity

Agentic work changes the relationship between a developer and the code they ship. Parallel sessions are mentally taxing in ways solo coding wasn’t. The developer is steering multiple tracks, holding multiple contexts, switching between them faster than they would have switched tasks before. Sustainable for a while. Not indefinitely.

The same dynamic applies at team scale. A team running flat out for weeks at a time will produce a lot of work and a lot of fatigue. The fatigue won’t show up immediately. It’ll show up as quality drift, missed details in code review, irritability, attrition risk. The pace that feels sustainable in the first sprint may not survive the eighth.

This is where leadership has to actively intervene. The pressure usually flows in one direction: from above, asking for more, capitalizing on the gains. The discipline is to push back against that pressure — sometimes against your own instinct, sometimes against your peers. Slow weeks aren’t a failure of the operating model. They’re part of how it survives.

Culture → Watch what comes out, not what’s active. A team that’s running many sessions but producing thin work has hit the ceiling without realizing it. Encourage your developers to find their own ceiling and stay below it.

Two rhythms we’ve seen work

Two rhythms come up often enough to be worth describing. Not the only options. Other shapes work for other teams. The point is to give you a starting reference, not box you in.

Weekly sprint cadence. Compressed traditional sprint shape. Monday morning chooses what’s going to ship that week — work already scoped, planned, and made agent-ready. Most execution happens Monday through Wednesday. Midweek triage discards what’s slipping. Thursday is heads-down on the committed list. Friday is demos and brief retro. Suits feature-driven, predictable work.

Continuous flow. Less ceremony, more responsiveness. Prioritized backlog; team pulls as capacity opens. Daily standups walk work right-to-left: what’s stuck in review, what can finish today. WIP limits prevent starting more than the team can finish. Weekly replenishment keeps the top of the backlog clear. Biweekly retros focus on flow. Suits reactive or unpredictable work: platform, infrastructure, support-heavy domains.

The choice depends on the actual shape of the work and the makeup of the team. A team forced into the wrong rhythm will struggle against it.

What both rhythms share, and what any rhythm worth adopting will share, is the discipline of finishing before starting. The most consistent failure mode in agentic work is teams who start more than they finish, which is easy to do when starting is cheap. Whichever rhythm you adopt, complete what’s in flight before you begin new work.

Culture → The rhythm is for the team, not the agent. Don’t try to design ceremonies around how agents should work. Design ceremonies around how the team needs to coordinate. The agents will fit into whatever rhythm the team adopts.

What needs to change upstream

Engineering teams can adjust their internal operating model on their own. They can’t fix what’s slowing them down upstream. The teams getting the most out of agentic work tend to have made changes that extend beyond engineering:

• Requirements written for agents to consume. Specific, testable, structured around intent rather than solutions. Vague specs used to be a tax on the developer; now they’re a tax on every agent the developer runs.
• Designs that match implementation speed. Designers reviewing built artifacts is faster and more accurate than designers producing pixel-perfect mockups in advance. The shift requires designers to be available throughout the build, not just at handoff.
• Decisions made faster, at lower confidence. Product decisions that took two weeks pre-agent now bottleneck a team that can build in two days. The fix isn’t reckless, risky decisions. It’s making smaller, faster, more reversible ones and course-correcting based on real output.

None of these are engineering problems. All of them affect engineering’s ability to deliver.

Stalled → If your engineering teams have made the shift but requirements, designs, and decisions are still arriving on the old timeline, you’ll see the same throughput you had before. The teams will be capable of more; the inputs won’t let them deliver it.

Watching for what teams propose

The most useful signal that the new operating model is working is teams proposing changes you didn’t ask for. They want to try a different cadence. They want to restructure how they take in work. They want to drop a ceremony that no longer serves them. The proposals are often small and specific.

When teams start doing this, your job is not to standardize. Let them try. Watch what works. Some proposals will become patterns other teams adopt voluntarily. A small number will become organization-wide practices, but only after they’ve proven themselves in real use.

The temptation, especially for leaders coming from a more controlled tradition, is to take what works for one team and roll it out to all of them. Resist this. The teams that proposed their own way of working own the way of working. Teams that have it imposed on them don’t.

What should be consistent across teams isn’t the model. It’s the principles underneath: finish before you start, steer agents deliberately, watch the cognitive cost, let teams shape their own work.

Delivery and Experimentation

The first wins are about doing the same things faster. The next wins are about doing things you couldn’t do before.

Three figures worth tracking, in the order we saw them typically show up: delivery compression, productivity, and experimentation rate. Each tells you something different. The third distinguishes organizations that have transformed from organizations that have just gotten faster. A fourth signal, the unattended track delivering its first real work, shows up later and is treated separately at the end of the chapter.

Delivery compression

The most visible result of agentic work is that things ship faster. Migrations that used to take three sprints take two days. Bug fixes that took a week take an afternoon. Cross-platform features that required multiple teams ship from one team in a day.

This is real. It’s also easy to over-claim. The temptation is to compare against the slowest example you can find or count the win without acknowledging upfront cost. An honest framing has two numbers: a floor — what you can defend against committed milestones with recorded outcomes — and a central tendency — what teams report across many tasks, including dramatic outliers. Both are useful. They tell different audiences different things.

Compression isn’t uniform. Pattern-based work — migrations, refactors, boilerplate-heavy implementation — compresses dramatically. Features that need real product judgment compresses more modestly. A single number across all work types will mislead you. Track by category.

What we saw: Sustained delivery compression of about 2× across committed milestones — projects with formal start dates, target dates, and recorded outcomes. For high-pattern tasks (refactors, migrations, boilerplate), compression moved into the 5×–10× range. A few tasks with very strong pattern fit went higher. Those numbers describe the best cases, not the typical ones.

The pattern that mattered more than any single number: compression extended over time into work categories that initially didn’t seem to benefit. Implementation compressed first. Then validation. Then planning. Then operational work. The tools weren’t getting fundamentally more capable across that period. The organization was getting better at applying them.

Compression has a shelf life. It measures the gap between planning assumptions formed before agents and outcomes produced with them. Once your organization’s planning catches up, compression ratios collapse toward 1×. That’s not a regression, it’s the metric doing what it should. When that happens, the question shifts to throughput, the next section.

Stalled → If compression numbers look strong but the throughput of finished work isn’t moving, the gap is downstream. Code is being produced faster; the work isn’t reaching customers faster.

Productivity

Compression measures how fast individual tasks move. Productivity measures how fast the system as a whole ships. They’re related, not the same — and the gap is where most agentic transformations leak value.

Software productivity has been hard to measure for decades. There’s no clean number, which is why the industry has converged on frameworks like DORA and DX metrics that correlate with productivity even if they don’t directly capture it. The pragmatic move is to use the same proxies pre- and post-agent and look at how the trends move. That’s what we did.

The metric worth tracking is throughput-with-cycle-time. How many pull requests are merged per developer per week, and how long does each take from open to merge. Together they tell you whether the work coming out of compression is reaching production. If throughput climbs while cycle time also climbs, code is piling up in review. If both improve, the system is genuinely getting faster.

What we saw: One product team’s median PR cycle time dropped from ~5.7 hours to ~1.4 hours over 90 days — roughly 76% — while throughput grew 32%. Another team adopting structured agentic workflows mid-quarter showed cycle time drop from ~14 hours to ~5 hours over three weeks (60%) while throughput grew 47%. Both teams were leading adopters with structured operating models. These are achievable in well-run pockets, not org-wide averages.

A few caveats:

• Leading-team metrics aren’t org averages. Be careful about presenting them as if they were.
• Self-reported time-savings are softer than they look. People aren’t great at estimating time savings. Use these numbers as directional, not defensible.
• Cycle time matters more than raw throughput. A team producing twice as many PRs with three times the cycle time has moved the bottleneck, not removed it.
• PR cycle time measures code reaching the main branch, not customers. A team can be fast at merging and slow at deploying. Track both if you want the full picture.

Watch out → Productivity metrics are easier to game than compression metrics. When adoption itself becomes the target, engineers respond by producing usage that looks productive but isn’t producing matching value. If your productivity numbers are climbing without matching outcomes for the business, look at how the metrics are being incentivized.

Experimentation rate

The first two figures measure how fast you do what you were already going to do. The third measures the work you can now attempt. Work that didn’t have a path before because the cost of trying was too high.

The signal worth watching is the rate at which experiments turn into roadmap commitments. POCs from a hackathon. Prototypes from micro-sprints. Side bets engineers made because the cost of trying dropped. Some produce nothing. Some produce something interesting. A few reshape what the organization thought its roadmap should be.

What we saw: A two-day org-wide event focused on agentic delivery produced over 35 distinct projects, of which roughly a third (12) became formal roadmap commitments the following quarter. None of those 12 work items existed in any plan before the event. A few months later, eight had reached production, and eight new experiments had been initiated — these new ones not from a hackathon, but emerging from the production work itself. The experimentation pattern had shifted from event-driven to continuous. One generation of experiments produced the infrastructure and learnings that fed the next.

The conversion rate (about a third of attempts becoming formal work) isn’t a universal number. What matters more than any specific value is the existence of the conversion rate — a pipeline from attempt to roadmap that didn’t exist before.

If your organization has suffered from “we have to keep going because we’ve already invested” sunk-cost thinking, the experimentation lens gives you a way to address it. The dysfunction was always there. What’s changed is that the cost of trying something else has dropped enough that “we committed, we have to finish” is now visibly the expensive choice, not the cautious one. This isn’t a new principle. It’s the right time to put a long-standing principle into practice.

Culture → Experimentation rate goes up when the organization stops requiring a business case for every attempt. If teams need to justify a small experiment before they can run it, the cost of trying hasn’t actually dropped — you’ve just moved it from execution to approval. Make small experiments cheap to start, not just cheap to execute.

The second track: unattended work

The dual track was deliberate from the start. While the developer-steered track was the primary goal, unattended agent loops were planned as a parallel engine for work that doesn’t need a developer in the session. The unattended track came online later because it depends on the developer-steered track maturing first: the conventions, the agent-legible environment, and the reviewing capacity all have to be in place before unattended work can run safely.

The first concrete example: ten security tickets resolved in 45 minutes, no engineer in the session. The agent ran on a schedule, picked up the tickets, made the fixes, opened the pull requests. A human reviewed and merged. The same work had previously taken multiple engineer-hours per ticket of triage and remediation.

This isn’t faster execution. It’s engineer-hours eliminated entirely from a class of work. It changes what’s possible for security backlogs, dependency updates, observability tasks, infrastructure maintenance, and other domains where work is well-defined but tedious. The metric stops being how fast did the engineer do this with help and becomes did this require an engineer at all.

You still need code reviews to make sure unattended agent work doesn’t cause downstream problems. The most progressive teams in our organization are now spending real cycles on what work looks like when most of the routine work runs without them.

Trends over time

The initial stages of transformation saw wider ranges of delivery compression. This settled as the transformation became more normal four months into the process.

Cycle time data from team-level DX tooling; early time-savings figures from self-report surveys.

The most important shift: early metrics were mostly about implementation speed. By four months in, the metrics that mattered were about review speed (cycle time compression) and operational autonomy (unattended agents). These are the next two constraints in the agentic engineering system, and both are now showing measurable movement.

What to ask your teams

Two questions to put to engineering leadership at the end of a quarter:

1. How much faster did we deliver what we’d already planned to deliver?
2. What did we attempt this quarter that we couldn’t have attempted six months ago?

The first question is the one you’ll always remember to ask. The second is the one that matters. If the answer is empty, you’re getting a productivity dividend but missing the larger half of what agentic work is for. If the answer is a substantial list, you’re seeing the strategic return.

Using the numbers

Most organizations measure only the first figure. The reason isn’t that the others are hidden. It’s that compression numbers come naturally from the work, while productivity needs real instrumentation and experimentation rate needs the discipline of tracking what’s attempted, not just what ships. The figures only tell you something when read together: compression alone means individual tasks are getting faster; all three moving means the roadmap itself is being reshaped by what you’re learning.

Use the figures above as orientation, not targets. Aim for the pattern, not the specific numbers.

Stalled → If executive expectations are running ahead of what the organization can sustain, the fix usually isn’t more data. It’s reframing what the data means. Compression numbers age out as the org’s planning catches up. Productivity metrics need careful nuance. Experimentation rate is a real signal. Bringing executives along on what each metric is actually saying, and isn’t, is part of the leadership work.

The 2× compression floor describes a successful committed-milestone improvement sustained over time. If you’re seeing 1.5× across many such projects, you’re probably on track. If you’re seeing 8× on every project you can name, you’re probably comparing against your worst examples and your numbers won’t survive scrutiny.

The 60–76% cycle time reductions are what leading teams achieved with structured operating models and active investment in their review pipelines. If your leading teams are showing similar trajectories, you’re seeing the same pattern. If not, the gap is likely in the operating model adoption or the review-pipeline investment, not the tools.

The roughly one-third hackathon-to-roadmap conversion gives a reference point for whether your experimentation pipeline is real. Not all of them, not most of them, but enough to be a noticeable share of your next quarter’s plan.

The unattended track is harder to benchmark because it’s still new in most organizations. The right question is whether you’re investing in it at all yet. If you have engineers spending time on well-defined, repetitive work an unattended agent could do, the question is when you’ll start, not whether.