What AI-Powered Development Requires from Leadership

Three agents are implementing features in parallel. One is building a new customer notification system. Another is extending the payment flow. A third is adding audit logging across services.

The engineer directing them has a question about the notification system's data model, specifically, whether to create a new events table or extend the existing one. It's a fifteen-minute decision for someone with context. But the person with context is in meetings until Thursday. The architect who can make the call is awaiting input from the platform team. The platform team is blocked on a strategy discussion that's been "almost scheduled" for two weeks.

The agent finishes the notification system in four hours. It uses a new events table. Meanwhile, the audit logging agent, working from different assumptions, extends the existing table. The payment agent creates a third approach entirely.

By the time the strategy discussion happens, there are three incompatible implementations in production, two of which will need to be unwound, and the engineer has moved on to six other tasks.

This is what decision latency looks like at agent velocity.

The Bottleneck Migrates Again

In the pre-LLM era, we were constrained by how fast we could write code. LLMs shifted that constraint to how fast we could review and direct code. Now, as we move deeper into the agentic era, the constraint is migrating once more: to how fast we can make good decisions.

The math is unforgiving. If an agent completes a task in four hours but waits three days for a decision, you've destroyed 95% of your potential velocity. Multiply that across every engineer directing multiple agents.

Agent capabilities are improving rapidly. The organizations that build strategic frameworks now, before they're forced to, will have a significant advantage as those capabilities mature.

The Coordination Trap

The obvious response is to distribute decision-making authority. Push decisions down. Empower engineers. Let each person make calls independently.

This is the right instinct, but incomplete. Empowerment without frameworks just distributes the chaos. Without strategic guidance, you get creative engineers building solutions that don't compose. You get the opening scenario: parallel efforts solving the same problem incompatibly, architectural drift compounding faster than anyone can track.

The traditional response would be more coordination. More meetings, more approval chains, more consensus building. But coordination at agent velocity is death. By the time you schedule the meeting, the implementation is done.

In the agentic era, duplication is cheaper than coordination.

Two engineers independently building similar tools in parallel, then synthesizing the best parts afterward, beats upfront coordination meetings and design committees. When execution approaches zero cost, the expensive thing isn't building it twice. It's the meeting to prevent building it twice.

The obvious objection: code is a liability, not an asset. Don't you eventually pay the cost of maintaining duplicates or merging them?

But synthesis is also agent work. "Compare these two implementations, take the best parts of each, produce a unified solution" is a prompt, not a project. So is "delete the deprecated version and update all call sites." This holds as long as the implementations are comparable, which is why architectural strategy matters: it creates the constraints that make synthesis possible.

The synthesis tax only exists if synthesis requires human effort. It doesn't. The only expensive thing is human decision latency, and duplication eliminates the upfront coordination that creates that latency.

The Arbiter and the Luthier

The agentic era changes engineering roles.

The Engineer becomes the Arbiter. They make decisions, direct agents, evaluate implementations, and choose between competing solutions. They operate at execution velocity: dozens of strategic decisions per day across multiple parallel streams.

The Engineering Leader becomes the Luthier. They don't make those decisions. They build and maintain the strategic frameworks that keep all those parallel decisions in tune. They craft an instrument that stays in tune even when played at breakneck tempo by many hands at once.

The distinction clarifies what "strategy" actually means now. The leader's job isn't to make decisions or even approve decisions. It's to build decision frameworks precise enough that engineers can make good decisions independently, at velocity, without coordination.

A bad luthier thinks their job is to prevent the instrument from being played aggressively, through process gates, approval chains, and review committees. A good luthier builds instruments that thrive under aggressive play.

The critical constraint: you can't build the instrument while people are playing it. Strategic frameworks must be established before you unleash agent-enabled velocity, or you're tuning a violin during the performance.

If strategy isn't in the agent's context window, it doesn't exist.

Most leaders miss this. The luthier's job includes encoding architectural strategy into the artifacts agents actually read: the prompts, the templates, the CONTRIBUTING.md that shapes every implementation. Strategy that lives only in slide decks or quarterly planning documents is strategy that agents will ignore.

Product Strategy Isn't Enough

Most organizations, when they think about strategy, think about product strategy. What gets built, for whom, and why. Which customer segments do we serve? How do we differentiate? What's in scope versus out? If they think about strategy at all.

This matters. Product strategy gives engineers the decision razor for value creation, whether an idea moves the organization forward.

But product strategy doesn't prevent the opening scenario. All three of those agents were building the right things. The notification system, the payment extension, and the audit logging: all aligned with product strategy. All valuable. All approved.

The failure mode isn't building the wrong thing. It's building the right things in ways that can't compose.

This is the harder domain, and the one most organizations neglect: architectural strategy. Not architecture as a technical discipline, but architecture as a strategic one. How systems get built, not just what systems get built.

Architectural Strategy as Strategic Discipline

In the agentic era, engineers aren't implementing predefined architectures. They're making architectural decisions in real-time across multiple parallel development streams. Each decision either compounds coherence or creates debt.

Without clear architectural strategy, parallel development produces exactly what the opening scenario illustrates:

• Incompatible data models across features built simultaneously
• Conflicting integration patterns that can't compose
• Systems that solve similar problems with incompatible approaches
• Technical debt that accrues faster than anyone can pay it down

Architectural strategy provides the decision framework for questions that product strategy can't answer:

• Should this be a new service or part of an existing one?
• What data formats do we standardize on?
• How do we handle cross-cutting concerns?
• When do we introduce new technology versus use existing patterns?

These aren't one-time decisions made by an architecture review board. They're continuous choices made by engineers directing agents. The architectural strategy ensures those choices remain coherent even when made independently and in parallel.

This requires one non-negotiable commitment: implementations must be comparable. Standardized interfaces. Feature flags for switching between approaches. Automated testing that validates against the same contracts. The luthier's job includes building an instrument where parallel implementations can be evaluated and merged without archaeology.

If your architecture doesn't support rapid comparison and synthesis, you've got bigger problems than duplication.

Three caveats, because the blanket prescription invites misreading:

First, strategy requires periodic revision. The key is direction of flow: strategy informs decisions, not the reverse. Use the framework to make calls, then reflect on outcomes and revise between cycles—quarterly, after major releases, when patterns emerge. Strategy that bends to accommodate individual decisions isn't strategy.

Second, not all coordination is waste. Some decisions genuinely benefit from upfront synthesis of multiple perspectives, particularly those with high reversibility costs or cross-team dependencies that can't be easily unwound. The question isn't whether to coordinate, but which decisions are worth the latency.

Third, architectural standards need escape valves. "All new services expose REST interfaces" is a good strategy, but real systems have exceptions. Build the escape clauses into the standards themselves. Engineers can use them. We trust them to make good calls. But they justify those choices in review. The exception becomes a data point for strategy revision, not a request for permission.

Strategy as Logic Density

Roger Martin's work on strategy clarifies the failure mode.

Strategy, in Martin's framework, isn't a planning document or a vision statement. It's a decision-making tool, a razor that helps you choose between options. Good strategy eliminates possibilities upfront. It makes hard choices about what you won't do. It provides clear criteria for evaluation.

Most organizations misread this.

They treat strategy as aspiration rather than logic. "We want to be the most customer-centric data provider" feels like strategy. It's not. It's marketing copy. An engineer can't evaluate a decision against it. It eliminates nothing.

Compare the logic density:

• Zero logic density: "We want to be the most customer-centric data provider."
• High logic density: "We prioritize latency over feature-completeness for all Tier 1 APIs."

The second statement is computable. An engineer, or an agent, can evaluate any decision against it. The first just makes everyone feel good.

When execution was slow, this laziness was merely inefficient. You'd waste time, build wrong things, course correct, eventually get there. The cost was delayed quarters and frustrated teams.

The agentic era exposes this misreading brutally. Ambiguous strategy becomes a denial-of-service attack on your own organization. By the time you realize someone built the wrong thing, they've moved on to three other projects. Wrong implementations multiply faster than you can identify them.

This applies to architectural strategy too, not just product strategy. "We believe in clean architecture" is aspiration. "All new services expose REST interfaces and publish events to the central bus" is logic. The first sounds wise. The second actually prevents the opening scenario.

Strategy must function as pre-collaboration. All the hard conversations about tradeoffs, priorities, what matters: they happen once, when you set strategy. Then individual decisions become mechanical applications of that framework. The collaboration already happened. No meeting required.

The Discipline This Demands

The default in most organizations is strategic ambiguity, vague enough to preserve optionality, consensual enough to avoid conflict. That default becomes increasingly expensive as execution velocity increases.

You won't get the frameworks right on the first iteration. That's not the failure mode. The failure mode is having no frameworks and expecting engineers to invent coherent ones independently and in parallel. Start with your current architectural patterns, encode them explicitly, and build in revision cycles. The goal is organizational learning velocity: can you update frameworks faster than inconsistencies compound?

This doesn't mean dictatorial decision-making. The practical middle ground is strong defaults with narrow gates: be opinionated about architecture and standards, but build explicit mechanisms for exceptions and evolution. The goal isn't eliminating judgment. It's eliminating the latency of re-litigating settled questions.

Organizations that maintain strategic ambiguity while claiming to enable velocity create the worst outcome: engineers making autonomous decisions based on what they think the strategy is, only to be overruled because the "strategy" was just aspiration dressed up in executive language.

The work required is harder than writing vision statements. You have to make real choices. Explicitly cut off possibilities. Commit to specific tradeoffs. Accept that some valid concerns won't be addressed. Provide architectural strategy with the same rigor you provide product strategy, maybe more, because architectural incoherence is harder to see and harder to fix.

You have to build the instrument before the performance begins.

Organizations that do this work get the full velocity of agent-enabled development. Their engineers make fast, independent decisions that remain aligned. Their systems compose because the architectural strategy ensured compatibility. Their products cohere because the product strategy provided boundaries.

Where This Leaves Most Organizations

Very few organizations can operate this way today. If you have engineers who function as effective arbiters, architectural strategy encoded in artifacts agents actually read, and leadership that builds frameworks instead of approval chains, you have a champagne problem. Most don't.

The path is incremental. The gap between organizations with strategic discipline and those without will widen as agent capabilities improve. The time to build the frameworks is now, while the performance is still warming up.

This piece is part of the Arbiters Series, exploring how engineers must evolve into decision-makers at velocity. For the leadership discipline of building these frameworks, see The Dao of Delivery.