Fast at What?

Kent Beck’s 3X when implementation stops being the default bottleneck

I keep coming back to Kent Beck’s Explore/Expand/Extract framework.

I like it because it refuses to treat speed as one thing. Beck’s answer to “Are we slowing down?” is better: depends where you are on the curve. In Explore, speed is measured feedback. In Expand, speed is resource movement. In Extract, speed is profitable work without unnecessary delay.

That distinction matters more now.

The agent-era version of the question is not “are we slowing down?” It is “why aren’t we faster?” We have coding agents, long context windows, background workers, parallel sessions, and tools that produce working changes in minutes. The visible output went up. Many teams still feel stuck.

The answer is the same: fast at what?

Output is not speed

Agents changed the pacing item. Candidate work is abundant. A prototype, a migration, a test, a refactor, a first draft of an implementation - all arrive faster than they used to.

That does not make the organization fast. It removes one delay and exposes the next one.

Not everywhere. Tangled legacy systems, weak tests, and regulated surfaces can still make implementation dominate the work. The point is narrower: once the agent and the environment produce plausible changes quickly, implementation becomes the wrong default place to measure speed.

This is where AI productivity talk gets sloppy. More code is not speed. More pull requests are not speed. More tasks assigned to agents are not speed. They are activity. Sometimes activity is useful. Sometimes it is a faster way to fill the queue.

Stack Overflow’s [2025 Developer Survey](https://survey.stackoverflow.co/2025) captures the tension well: 84% of respondents use or plan to use AI tools, but the biggest frustration is output that is almost right. That is not an argument against agents. It is a warning about the new constraint. Producing an answer got easier. Deciding whether it is right did not get easier at the same rate.

So the useful question is not whether agents made you faster. The useful question is which delay now governs the work.

Explore: time to evidence

In Explore, fast means time from uncertainty to evidence.

Agents help here first. When the problem is ambiguous, you can try more shapes. Build two versions of the onboarding flow. Spike three storage models. Ask for a working demo instead of a design debate. The unit of exploration shrinks from a sprint to an afternoon.

But the scarce resource is still evidence. A prototype that nobody evaluates is not exploration. It is inventory. Three versions of a feature help only if someone looks at them, compares them, and learns which direction deserves commitment.

That is the trap. Teams see agents produce more options and assume exploration accelerated. Sometimes it did, when the evaluation loop closed. Sometimes the bottleneck moved from building options to interpreting them. Product judgment, user feedback, taste, and measurement still run at human speed unless the team builds better loops around them.

Exploration speed is not prompts per hour. It is not prototypes per week. It is how quickly a vague belief becomes a grounded decision.

Expand: time to move

In Expand, fast means how quickly resources move toward the bottleneck.

In Beck’s original framing, those resources were often people and money. Sometimes the answer is still hiring, budget, or infrastructure spend. But in agent-heavy teams, the scarce resources are often stranger: review attention, CI capacity, production data access, permissions, architectural ownership, staging environments, deployment confidence, and someone with enough context to say yes.

Adding agents does not fix those constraints. It can make them worse.

If every agent-produced change waits behind the same reviewer, review becomes the rate-limiting resource. If agents can write tests but the suite takes forty minutes and flakes twice a day, CI becomes the constraint. If a background agent can implement a feature but cannot access the fixture, secret, environment, or product decision it needs, the organization has not expanded. It has created a faster worker at the entrance to the same locked room.

This is why “we have more agents” is not the same as “we expanded capacity.” Capacity expands only when the bottleneck receives what it needs.

DORA’s [2025 AI-assisted software development report](https://dora.dev/research/2025/dora-report/) describes AI as an amplifier of the organization underneath it. Agents amplify clear systems. They also amplify queues, vague ownership, weak tests, and slow approvals.

Expand speed is the speed of resource movement. In 2026, that often means moving trust and verification, not just headcount.

Extract: time through the system

In Extract, fast means profitable work moves through the system without unnecessary delay.

Mature work should not need heroic attention every time. A dependency update, a copy fix, a narrow bug, a small migration, a missing test, a routine refactor: these should flow through known paths with known checks.

The mistake is keeping exploratory ceremony after the work has become routine. A team learns how to do a class of change, automates the verification, then still drags every instance through the same human review ritual. The process survives after its purpose has expired.

The opposite mistake is worse: treating everything as routine before the system deserves that trust. Auto-merge without good tests, canaries, rollback, ownership boundaries, and critical-path tagging is not extraction. It is moving risk faster.

Extraction speed comes from sorting. Low-risk, well-specified work should move through automated controls. High-risk work should pull in humans early: authentication, payments, migrations, external contracts, shared abstractions, anything where reversal is hard or the blast radius is large.

The goal is not fewer safeguards. The goal is safeguards placed where they matter.

Compliance does not change this principle. Some teams need explicit approvals and audit trails. Fine. Approval should attach to real risk, not every diff by habit.

The curve did not go away

The tempting story is that agents made software fast. That is too broad to be useful.

Agents changed the pacing item in many workflows. They did not repeal the curve. Explore still needs evidence. Expand still needs bottlenecks to receive resources. Extract still needs delay removed without removing control.

This matters because teams often act from the wrong phase.

They are exploring but demand one perfect plan before trying anything. They are expanding but keep scarce decision-makers fixed in old queues. They are extracting but require human ceremony for every low-risk change. Or they pretend to extract while the verification system is too weak to deserve trust.

The question is not “are agents making us faster?”

The question is: fast at what?

Find the curve. Find the delay. Then remove that one.