Strategy: AI-native engineering for business leaders

The Strategy and business section covers the five decisions leadership owns when coding agents write most of the code: what an accepted change costs, whether to fund it at scale, how teams change shape, how fast to move, and what the board sees. Every number carries a publisher and a date.

Your CTO wants budget for agents, or you are the CTO asking for it. A vendor promises a multiple, a board member forwards a study where developers got slower, and finance asks about headcount. This section gives you the unit, templates and gates to decide without reading code or taking a number on trust.

Who this section is for, and where each reader starts

You are	Start with	Then
CEO, CFO or COO	The executive track: a ten-minute brief and the five questions for your CTO	Economics, then the business case
CTO or VP Engineering	The CTO track, which pairs these pages with the operating model in Engineering organization	The transformation roadmap, then board reporting
Owner of a software house or agency	AI-native delivery for software houses and agencies	Economics for your own margin

Never measured where you stand? Take the free C-Level Scorecard first; it places you on the autonomy ladder these pages use.

Which five decisions does this section settle?

Each decision has one page and one artifact to adopt.

Decision	The question	What you adopt	Page
Economics	What does an accepted change cost us?	The cost-per-accepted-change definition and a spreadsheet template	Economics
Business case	Is it worth funding at scale?	A decision memo with four options, stop gates and a risk register	Business case
Org design	How do teams, roles and headcount change?	Team sizing by review capacity and a headcount plan without multipliers	Org design
Pace	How fast do we move, and what stops us?	A 12-month roadmap with stop/go gates per delivery loop	Transformation roadmap
Board reporting	What does the board see each quarter?	A one-page report with a five-row risk register	Board reporting

Supporting pages: leading people through the change, product management when build time collapses, software built outside engineering, and success stories and case studies.

The decisions are tool-agnostic; the economics and board-reporting pages show where Claude Code, Codex and Cursor keep cost data. Plan prices: the pricing analysis; model prices: the models hub.

What evidence standard do these pages follow?

The third-party evidence points both ways. DORA’s 2025 report (Google Cloud, 23 September 2025) found “a positive relationship between AI adoption on both software delivery throughput and product performance” and “a negative relationship with software delivery stability”. METR’s randomized trial of 16 experienced open-source developers on early-2025 tools (10 July 2025) found they took 19% longer with AI, yet afterwards believed it had sped them up by 20%. Its follow-up (METR, 24 February 2026) favours AI on point estimates, but the intervals cross zero and METR calls the data an unreliable signal. The details are in the state of agentic engineering. So every page here follows the rule below; adopt it for your own decks.

EVIDENCE RULE FOR ANY AI ENGINEERING PROPOSAL OR REPORT
1. Every number names its publisher, its date and what was measured.
2. No productivity multiplier without a named third-party source and its population.
3. Vendor-internal figures are labelled "vendor-internal" and never used as a forecast.
4. Output (changes merged) is never shown without stability (change failure
   rate, incidents per change) and review load (hours in review).
5. Savings are counted in cost per accepted change: merged, not reverted
   within 30 days. Hours "saved" in a survey are not savings.
6. Every expected gain has a stop gate: the number that pauses the program,
   and the person who makes that call.

How leadership knows it works without reading the code

No executive reviews a diff, and at scale neither can a CTO. Proof comes from machine-run checks and auditable numbers:

The unit counts only changes that stayed merged. Reverted work adds cost but leaves the denominator, so rework shows in the number.
Autonomy is earned per loop, not granted by memo. A team climbs only when its tests, checks and evidence attached to each change meet the gate in autonomy governance.
Sign-off is split. The CTO owns metric definitions and finance signs the cost line. Every increase in agent autonomy is signed by the approver in the roadmap’s gate table. The board sees the result on one page each quarter.

Autonomy step	Who signs
Up to L3	Platform lead or loop owner
L3 to L4	CTO or a delegate, with the service owner
L4 to L5	CTO, with security sign-off

What goes wrong when leaders set AI engineering strategy?

A seat rollout is reported as a transformation. Seats measure spend. Report cost per accepted change and each critical loop’s level instead.
A multiplier reaches the board deck. One question about its source loses the room. Use the break-even figure from the business case.
Headcount is cut before review capacity is known. Review becomes the constraint and incidents rise. Size teams by review capacity from your own pilot, as org design shows.
The roadmap follows the calendar, not the gates. A quarter passes, so autonomy goes up. Tie each step to a stop/go gate and roll a loop back one rung when its stop signal fires (the transformation roadmap).

Where to go next with strategy

The economics of agent-built software Start here: the unit every page in this section uses

The state of agentic engineering The dated third-party evidence, both ways

Designing a pilot that proves something The baseline and decision rule a business case needs

Engineering organization The operating model, governance and security the CTO builds