The CTO's Guide to Post-AI Engineering Economics

Where the AI gains go

Between adoption and the income statement, the AI investment loses value at every step: adoption is nearly universal, individual gains are real but modest, and organizational impact remains rare.

Figure 01 — where the value leaksAdoption → Org impact

Almost every organization adopts the tools, a smaller share changes the process around them, and less again shows up as organizational impact. Illustrative, not to scale.

The shortfall sits downstream of the tools. Writing and testing code is only 25 to 35% of the time from idea to launch, so even a large gain on that slice moves the whole pipeline modestly.¹ BCG's verdict on engineering organizations is blunt: widespread adoption, shallow impact, with value "spotty and limited to pockets", and half of CIOs unable to quantify GenAI's impact at all.³

Where the gains go

• Review queues. AI-generated pull requests wait 4.6x longer for first review; acceptance runs 32.7% versus 84.4% for manual PRs.⁴
• Organizational drag. 68% of developers save 10+ hours a week with AI; 50% lose 10+ hours a week to inefficiencies like waiting on environments and hunting for information.⁵
• Instability. AI adoption continues to correlate with degraded delivery stability, and incident response consumes the saved time faster than the tools created it.⁶
• Unmeasured impact. 90% of engineering teams use AI tools; only 20% measure the impact with engineering metrics, so most teams have no way to see where the saved time goes.⁷

How AI changes the engineering budget

AI has rearranged what engineering money buys rather than making engineering cheaper. Four line items are moving at once:

The measurement gap

90% of engineering teams use AI tools. 20% measure the impact with engineering metrics.⁷ For a budget owner, that means most organizations are increasing AI spend without being able to say which part of it returns anything, and without seeing that the constraint has moved downstream of the tools. The first economic decision is instrumentation: attribute AI usage, track the delivery metrics, and put a number on the delivery overhead line.

What the bottleneck costs

Three numbers put a price on the delivery bottleneck, and all three belong in any board conversation about engineering velocity:

Downtime is the most visible of these costs, and AI is currently adding to it: adoption keeps correlating with degraded delivery stability, and 72% of organizations have had at least one production incident caused by AI-generated code.^6,11 Every point of stability given up converts saved developer hours into incident hours, the most expensive category of engineering time.

Maintenance and queue costs

The older, larger number is maintenance drag. Stripe's canonical study put developer time on maintenance and bad code at 17.3 hours of a 41.1-hour week, roughly 42%, and valued the resulting inefficiency at about $300B a year in global GDP loss. The study is from 2018, before AI raised code volume; nothing suggests the share has fallen since.¹² Add the modern queue costs from section 01: payroll spent waiting for review, environments, and redeploy cycles.

The decisions in the next two sections, whether to add headcount and whether to build or buy the platform layer, are both about the cheapest way to shrink this bottleneck.

Headcount or automation?

The traditional response to a delivery bottleneck was to hire platform and DevOps engineers until the queue cleared. Three things have changed that maths.

Platform hires cost more and take longer to find

In the Kubernetes job market, platform engineers command nearly 20% more than DevOps roles, and platform and IaC roles rank among the hardest to fill.¹³ Meanwhile the function's own economics are under scrutiny: 47.4% of platform initiatives run on budgets under $1M, 29.6% of platform teams do not measure their own success at all, and average platform salaries fell in North America and Europe against 2024 as the title went mainstream.¹⁴ Senior platform skills stay scarce while the routine work commoditizes, which is usually the point at which the routine part gets automated.

The work is changing

AI has made application code abundant and cheap without doing the same for the infrastructure work around it, which is why the bottleneck sits there. Hiring more people to shepherd a growing volume of AI-generated change means scaling up the expensive input to keep pace with the cheap one. The alternative is to automate the work away: let provisioning, environments, and deployment derive from the application code, so more code stops meaning proportionally more infrastructure work.

What to calculate before you sign the requisition

• Fully loaded cost of the platform hire, times the team you will eventually need. Platform teams rarely stay at one.
• How much of that capacity goes to undifferentiated plumbing: IaC upkeep, environment drift, CI pipelines.
• What the same money buys if you spend it removing the work instead: a platform that derives infrastructure from code, or automation of whatever consumes the most time today.
• How fast each option shows results: a hire lands in months and takes longer to ramp, while a platform change on one service shows a difference in weeks.

Build or buy: platform engineering in the AI era

Gartner predicted that by 2026, 80% of large software engineering organizations would run platform engineering teams, up from 45% in 2022.¹⁵ The prediction is arriving on schedule, but it says nothing about whether those platforms should be built internally or bought, and the AI era has moved that answer.

Whether to build comes down to differentiation: if your platform layer is a competitive asset, build it. For most companies it is undifferentiated plumbing that has to work well and wins nothing competitively, and DORA's finding sets the stakes for getting it right by either path: a high-quality platform amplifies the effect of AI adoption on organizational performance, and a mediocre one caps it.⁶

The economics of code-derived infrastructure

The buy option worth pricing is infrastructure derived from application code: developers declare what a service needs as typed code, and the platform provisions, deploys, and observes it. On the P&L, the model changes five lines:

Customer-reported numbers are outcomes from specific contexts rather than guarantees.¹⁷ Use them as hypotheses for your own pilot, measured on your own baseline; section 08 covers the setup.

Making the case to the board

A board judges engineering investment by revenue timing, cost exposure, and risk, so DORA metrics need translating before they reach the deck. Once you have the measurements from section 02, the translation is direct:

The one-page memo

• Situation: AI tooling is deployed; individual gains are real. Delivery metrics are flat, and here are ours.
• Diagnosis: the constraint has moved downstream of the code, into review, environments, provisioning, and deployment. Industry data and our own numbers agree.
• Options, with costs: hire (salary, ramp time, share of the role spent on plumbing), build a platform (team size, timeline, risk), buy a platform (subscription, and what the pilot measured).
• Ask: one new service on a pilot, measured on lead time, deploy frequency, and change failure rate against today's baseline, with a decision in one quarter.

Questions to ask any platform vendor, including us

• What happens to our code and infrastructure if we leave? (Open-source framework, standard cloud resources in our own account, no proprietary runtime.)
• What does the pilot cost, and what do we measure to judge it? (Near-zero, and the four DORA metrics.)
• Where does it not fit? (Credible vendors name their exceptions: unusual runtimes, highly specialized infrastructure.)

Getting started

Most engineering organizations cannot answer the questions in this guide today. Only 20% measure AI's impact with engineering metrics at all, so waiting until the full cost picture exists means waiting indefinitely.⁷ You do not need it. A decision needs a baseline on three or four metrics you can already pull, and one service to compare against.

The questions the decision eventually turns on

Answer what you can. The gaps are not a prerequisite; several of them close on their own once the pilot is running, and the rest tell you where your reporting is thin.

• What share of engineering time goes to non-feature work: infrastructure, environments, pipelines, waiting?
• What is your lead time from merge to production, and how has it moved since AI adoption?
• How long does an AI-assisted PR wait for review, compared with a human one?
• What does an hour of downtime cost the business?
• What did AI tooling cost last quarter, and what measured outcome did it buy?
• What does the platform and DevOps function cost annually, fully loaded, and how much of that goes to undifferentiated plumbing?
• If delivery lead time halved, what would that be worth in revenue timing?

Where Encore fits

In a traditional Terraform-based workflow, much of the infrastructure code cannot be meaningfully validated until it is applied to a real cloud environment, so mistakes surface late, in staging or production, where they are slower and more expensive to fix. AI does not solve this by producing Terraform at roughly human quality: if the error rate stays the same while change volume grows 10-100x, the issues reaching the deployment loop grow 10-100x with it.

Encore changes the model instead. Developers and AI agents declare infrastructure requirements, such as databases, queues, and scheduled jobs, directly in ordinary TypeScript or Go, and Encore derives the configuration, permissions, environments, and deployment setup from those declarations. The same application model runs locally, in isolated preview environments, and in production, so changes are validated with real infrastructure before they reach the production loop. The framework is open source, and the cloud resources are standard services in your own AWS or GCP account.

How to run the pilot

• Pick one upcoming service. Build it on Encore alongside your existing stack. No migration required.
• Measure the DORA four plus review-queue time against your baseline for one quarter.
• Bring the deltas to the section 07 memo, and expand only if the numbers argue for it. In our experience they do.

About Encore

Encore is a development platform for the AI era, built for a world where AI multiplies software delivery 10–100x rather than making each developer slightly faster. Developers and AI agents declare the infrastructure they need — databases, queues, buckets, cron jobs — directly in ordinary TypeScript or Go, and Encore provisions it in your own AWS or GCP account.

The same application model runs locally, in preview environments, and in production, so changes are validated against real infrastructure before they reach the production loop. There is no separate Terraform layer for anyone, human or agent, to write and keep in sync.

01import { api, SQLDatabase, Topic, Bucket } from "encore.dev";
02 
03// declare what you need, Encore provisions it
04const db = new SQLDatabase("orders");
05const events = new Topic<OrderEvent>("orders");
06const receipts = new Bucket("receipts");
07 
08export const create = api({ method: "POST" }, async (o) => { ... });

$ git push encore
✔ Building application graph
✔ Provisioning Postgres (RDS) · Pub/Sub (SNS+SQS) · Object Storage (S3)
✔ Deploying 6 services to your AWS account (ECS Fargate)
✔ Wiring distributed tracing + metrics
 
→ Live at https://staging-orders-r2qa.encr.app· 42s
→ Dashboard at https://app.encore.dev/orders

Why this matters for this guide

• Where the gains go (section 01): the delivery automation that converts individual AI speed into organizational throughput is the default, not a program to fund.
• What the bottleneck costs (section 03): identical local, preview and production environments remove the works-in-staging failures that eat the saved time.
• Headcount or automation (section 04): the platform absorbs the DevOps and infrastructure work that would otherwise justify the next hire.
• The economics of code-derived infrastructure (section 06): there is no separate IaC codebase to write, review or maintain, which is where much of the cost sits.