Agentic Engineering: Where's the Playbook?

Agentic engineering is happening at a breakneck pace, and many are wondering if they are making the “right” decisions and using the “right” approaches. I’ve been a proponent of not chasing the newest fad, but to instead learn about what’s being used across the industry and keeping your options open.

I was listening to a recent Pragmatic Engineer podcast, where Gergely was interviewing Kent Beck. Kent has spent decades helping to shape software development through a variety of methodologies. Toward the end of the podcast, Kent describes our current situation with agentic development: We don’t have a playbook yet.

We don’t have a playbook. But we do have a framework for what it feels like to not have one, and Beck wrote that too.

The 3X Framework

One of the frameworks Kent created while working at Facebook is called 3X: Explore, Expand, Extract:

• Explore: The search for product-market fit. Success requires cheap, rapid experimentation to generate many ideas, tolerating failures, and putting on a “hacker” hat to minimize the time from question to answer.
• Expand: The hypergrowth stage. When a successful growth loop is found, focus on scaling up and overcoming bottlenecks. Fast, temporary fixes are valued here to survive the rapid scale.
• Extract: Maximizing value and ROI. The product matures, and focus shifts to rigorous engineering, optimization, increasing margins, and efficiency.

The industry has been running an Extract playbook for software development for the last 20+ years, and running it fairly well. Agentic coding wipes some that playbook away. People who were very good at running that playbook are having an identity crisis.

Beck says we’re back in Explore, and we’re beginning to write a new playbook. He also makes this great point:

The skill of writing a playbook is completely different than the skill of applying a playbook.

Beck starts applying 3X to agentic engineering in the podcast, but he doesn’t go deep. I wanted to think more about it, because I think it explains why this moment feels so disorienting, and why we’re churning through new tools without making any actual forward progress.

Reframing 3X for a Methodology

In product 3X, the thing you’re searching for is a growth loop: something that compounds with customers. In methodology 3X, the thing you’re searching for is a transferable practice: something that still works when someone other than its inventor does it, on a codebase they didn’t write.

Explore is practice discovery. Lots of small bets, high tolerance for failure, and observations are legitimate evidence. “It worked for me” is a real signal. The cost of a failed experiment is small, and we’re running a lot of experiments.

Expand is diffusion. Taking the discovered practice and scaling it to the rest of the engineering organization. The bottleneck is tribal knowledge — and the deeper problem is that some of it can’t be written down at all. The people who invented a practice are exercising judgment they can’t fully articulate. So what gets copied is the artifact, not the judgment behind it.

Extract is codification. Standards, metrics, compliance, efficiency. The sign of Extract is boring — Extract’s own playbook tells you to choose boring technology. The debates over git, CI, or code review are over. People still write about them, but it’s optimization at the margins, not a rethink of the core practice. When agentic engineering reaches Extract, we’ll stop having conferences about it. Maybe.

Nobody Agrees What Phase We’re In

What makes our current moment more confusing is the fact that people are not aligned about the phase state. The point of view changes by how far you sit from the actual work.

DX ran a panel at their annual conference, and they were direct about where the questions came from: assumptions circulating in executive teams and boardrooms that are shaping strategy right now. The panelists — engineering and research leaders from Etsy, Twilio, GitHub, Google, and Microsoft — were read a series of statements and asked to react.

Here are the statements:

• An AI-first SDLC means fewer engineers.
• In five years, more than 50% of code will be written by AI.
• Leaders need to mandate AI usage to make sure adoption is moving along.
• The future of software engineering is managing agents rather than writing code.

Headcount. Volume metrics. Mandates. Role redefinition. Every one of those is an Extract-phase question. Not one of them asks what works, or how to spread it. They all assume that’s settled and ask how to squeeze value out of it.

You can read what the practitioners said back:

Eirini Kalliamvakou couldn’t answer the “managing agents” statement without rewriting it first. The real work, she said, is defining intent, setting constraints and guardrails, providing context, and verifying output: engineering at a different level of abstraction. That is a list of Expand-phase work.

Rafe Colburn on mandates: the push usually comes from outside engineering, from people afraid of falling behind, and it produces shallow adoption. Brian Houck, who is running a study of around 600 engineers and managers, found their single biggest disagreement is that most engineering managers think AI usage is a reasonable individual performance metric — and engineers don’t.

The practice itself is still wide open. We don’t have settled answers on context management, spec-first versus code-first prompting, subagent decomposition, when to let an agent run versus when to interrupt it, or which model to use for which task. We don’t even have a settled answer on how to write a prompt: one study found that semantically equivalent rewrites produced different code 46% of the time, and changed correctness in 28%.

We don’t have best practices yet.

• Executives are in Extract. Mandates, metrics, headcount, margin.
• Practitioners are doing Expand. Context and knowledge management, guardrails, agent-assisted review & approval, unattended agentic workflows.
• Much of the practice is still Explore. Nothing is settled, including how to talk to the thing. We know there is something valuable here, but can’t quite realize the full potential.

The further you are from the code, the later in 3X you think we are.

This is a structural problem. Phase perception is a function of distance from the work — an executive genuinely cannot see the Explore-phase mess, because all they ever see is the output. Some gap between the C-level and the work streams is normal in any transformation. What’s abnormal right now is how wide the gap has become, because the ground moves every week and the layers are drifting apart faster than they can talk to each other.

Executives Rush to Extract

Sooner or later someone asks the question: Is this working?

It’s a fair question, but because most organizations haven’t set up an evaluation loop or a baseline, it’s difficult to answer. When you can’t prove a practice is working, you reach for the only instruments you’ve been trained to use: Metrics. Mandates. Capital-letter Frameworks.

People start using “percentage of code written by AI” as a KPI — a very game-able metric. Bill Gates supposedly said: measuring software productivity by lines of code is like measuring progress on an airplane by how much it weighs. Volume metrics simply inflate the exact code review burden that is already our biggest bottleneck. I don’t value solutions implemented with large amounts of code, so why would I be happy with agents that do?

Premature Extract isn’t a separate mistake, it’s a symptom. Twenty years of Extract muscle memory, firing at a problem it can’t see clearly from where it’s standing.

Practitioners Are Stuck in Explore

While executives might be quick to assume agentic engineering is in the Extract phase, we have another problem: Practitioners frequently focus on implementation details, like MCP, Skills, and Harnesses — rather than doing the work to stick with a fundamental concept and move it through Expand.

We have strong evidence that agentic code generation, code reviews, and even code approvals can create tangible benefits. We have seen evidence that contextual knowledge is a huge benefit to agents. Instead of leaning into those concepts, we tend to churn through a variety of implementation experiments that try new technical approaches, but don’t move the core concept forward.

I’ve written about my own experiences with agentic code generation, and how those outcomes yielded 2× to 7× delivery compression, PR cycle time dropping, and experimentation rates increasing. The next steps have to be pushing those outcomes to create business value, not just engineering value. Sometimes it’s more fun to play with the implementation details and new tools.

Here’s what we see teams doing today:

• Wiring agents into CI/CD pipelines, IDEs, and ticketing systems. Connecting agent harnesses into your existing SDLC workflow.
• Rapid scaffolding, loose security boundaries, and a high tolerance for flaky agent behavior. Velocity is the priority: get the agent opening PRs and writing tests autonomously.
• Aggressive adoption of codebase-wide editing agents, automated PR reviewers, and autonomous bug-fixers, to see how much work can be offloaded.

That list shows a desire to move core foundational aspects of agentic engineering into the Expand-phase. We should be looking for bottlenecks as we scale more of the practices into production-level work. The way we’re going about it feels very loose and experimental.

We adopted Expand-phase goals while keeping Explore-phase discipline.

The tools outran the practice. I have to remember that people like myself fueled some of the disconnect: we handed executives the numbers that made them think the work was done.

A recent NBER paper traced AI’s gains through the entire delivery pipeline — lines of code, to commits, to pull requests, to repos, to releases — across more than 100,000 GitHub developers. The gains at the top are enormous, and they grow with each generation of tooling: roughly +40% more commits from autocomplete, +140% from interactive agents, +180% from autonomous agents.

Then they follow those gains downstream through the SDLC. The effect on software actually released tops out around +30%.

180% going in. 30% coming out.

This is true with my own numbers too. Delivery compression, PR cycle time, experimentation rate — all measured at the front of the pipeline. Everything downstream of the merge is barely agentic or automated. The gains pile up at the front of the pipeline and then hit a wall.

Explore Is Not Permission to Be Sloppy

You might think that “just try stuff” means “rigor is optional”, but it’s not.

Explore has its own discipline, but it’s specific to the phase: Cheap to try. Easy to reverse. Comprehended and actually evaluated.

The evidence standard shifts by phase, and this is what people are getting wrong. “It worked for me” is sufficient in Explore. It’s dangerous in Expand. It’s useless in Extract. Most of the arguing happening right now is people applying one phase’s evidence standard to another phase’s claim.

Explore gives you permission to fail. It does not give you permission to not know whether you failed.

Autonomy Is Earned, Not Granted

An agent can only run unattended over work whose correctness can be proven without a human looking. So the path to autonomy isn’t “trust agents more.” It’s “make more of our work machine-verifiable.” Every gap you close turns a class of work into something an agent can safely own.

A phase isn’t a decision you make, it’s a state you demonstrate: Can this practice be verified without you standing over it? Can someone who didn’t invent it run it on a codebase they didn’t write?

So what does earning it look like? It means taking the core pillars of agentic engineering that we know work — management of context, specifying intent, agent code generation, agent code review/approval — and building the actual infrastructure to scale them safely.

Here is what we’re doing to move those pillars from loose exploration into disciplined expansion:

• Context: Improve and evolve the context we provide to agents to allow them to perform better. Generated code should be simple, concise, and matching the coding patterns we expect from developers. Code reviews should look for the same issues and checks we expect from our expert developers.
• Intent: Provide clear and concise intention of the outcome we want from the agent. The sharper the intent, the faster we get the desired outcome. Capture the gist of what’s been created to deal with cognitive debt as agents write and review more of the code.
• Code Generation: Move beyond developer-steered sessions and allow the agent to run a subset of tasks unattended. This requires agent-verification of the work. If an agent can’t verify the outcome, you can’t trust the outcome. You’re not scaling code generation effectively.
• Code Review/Approval: We’re already using agentic code reviews. Start scoring each change by blast radius, confidence, and risk. High confidence & low-risk merges itself; everything else goes to a human reviewer.

None of this is a playbook. It’s a set of bets, some of which will look naive in a year. Every one of them is an attempt to earn the next phase rather than trying to skip ahead.

We are being asked to pay out a maturity dividend on a practice that hasn’t matured yet. The cure isn’t a better executive metric; it’s closing the distance. Leaders who actually use these tools on real work stop misreading the phase, because they can finally see the mess.

If we want to write the new playbook instead of just blindly applying an old one, we have to stop treating understanding as a side effect.

Autonomy is earned, not granted.

Next up: Taking those four pillars through Expand; What breaks first in each one, and why understanding turns out to be underneath all of them.