Platform Engineering Leadership for AI Adoption

A fictional online retailer has 1,100 engineers in 90 product teams and a platform organization of 40. Within a year, three directors bought three different AI coding assistants. Seven teams building AI features wrote their own code for calling model providers. One team gave a coding agent the deployment token of the engineer who set it up. The chief technology officer now asks the vice president of platform engineering for a plan in 90 days, with two approved positions and nothing else added. Her intake queue holds requests that range from a shared model gateway to self-hosted inference, while the 40 engineers are already committed to the pipelines, clusters, and observability that every team depends on today. This invented case follows five decisions she has to make: what the platform takes on, where it standardizes, what it does about developer AI tooling, which runtime services it shares, and how it pays for reliability and cost. All figures are hypothetical planning estimates.

What the platform takes on

Scope comes first because every later decision draws on the same fixed capacity. The Load Has to Land Somewhere argues that a platform should state, capability by capability, what it operates and what it refuses. AI adds a long list of new candidates to that statement, and the pressure to accept all of them is high because AI is the company’s current priority. A thinnest viable platform is the discipline that answers the pressure: provide the smallest arrangement that removes the work from users, and reuse a managed service where one already does the job.

Four questions sort the candidates. How many teams need the capability, and how soon? What does inconsistency cost, and who pays when it fails: a data exposure, an uncontrolled bill, an unsafe action? Does a managed service or an existing component already supply it? Can the platform operate it, meaning staff it, put it on call, and promise a service level? The questions work because they separate demand from risk. A capability needed by two teams can still belong in the platform if the risk of inconsistency is severe. A capability wanted by many may not, if the market already sells it.

The platform is also not the only owner of AI readiness. DORA’s 2025 research reports that a high-quality internal platform correlates with an organization’s ability to get value from AI, and describes AI as an amplifier of existing strengths and weaknesses. Its AI Capabilities Model lists quality internal platforms as one of seven capabilities, alongside a clear and communicated AI stance, healthy data ecosystems, AI-accessible internal data, strong version control practices, working in small batches, and a user-centric focus. Most of those are not platform products. Version control discipline and batch size belong to engineering managers, and the data capabilities belong to the data platform. The vice president’s job is to fund the platform’s share without absorbing the rest.

The retailer’s platform leadership estimates each candidate in engineer-months for the first year: the build effort, plus the run effort for the months after launch. Seven engineers can be assigned to AI work, five freed by retiring two seldom-used legacy offerings and two from the approved positions. That is 7 × 12 = 84 engineer-months. She holds back 15% for unplanned work, so the plan uses 71.4.

Candidate	Teams that need it	Year-one effort (engineer-months)	Decision
Model gateway	14 teams building AI features	18 build + 1.5 × 6 run = 27	Fund
Coding-assistant enablement: single sign-on, policy, repository settings, usage telemetry	All 90 teams	6 + 1.0 × 9 = 15	Fund
Agent sandbox and credential broker	6 teams already running agents	14 + 1.0 × 6 = 20	Fund
AI cost allocation and showback	14 teams and finance	4 + 0.5 × 10 = 9	Fund
Shared evaluation harness	14 teams	8 + 0.5 × 8 = 12	Defer
Shared retrieval service	9 teams	20 + 1.5 × 5 = 27.5	Do not build
Self-hosted model inference	2 teams	30 + 3 × 4 = 42	Do not build

The seven candidates total 152.5 engineer-months, about 1.8 times the capacity. The four funded items total 27 + 15 + 20 + 9 = 71, which fits under 71.4. Adding the evaluation harness would bring the total to 83 and consume the reserve. The first four share a property: each either enforces a control that only works with full coverage (the gateway, the credential broker) or produces the data that later decisions need (telemetry, showback). The evaluation harness is a sequencing choice. Evaluation sets and pass criteria belong to the application teams, as Every Team Had Its Own Key explains, so teams keep running their own while the platform publishes a reference approach and waits for the gateway’s call records to feed a harness.

The two items marked “Do not build” need a stated reason and a reopening condition, or they come back as complaints. Retrieval indexes and embedding stores are data products with owners, freshness targets, and access rules, so the data platform’s ownership model decides who runs them; the platform contributes a documented pattern on managed services. Self-hosted inference serves two teams and would be the most expensive item by a wide margin. It reopens if spend through managed endpoints, as recorded by the gateway, exceeds the fully loaded monthly cost of operating the alternative at forecast utilization, or if a residency requirement appears that no managed offering meets.

Where standardization stops

Teams that built their own model access layers did so because nothing else existed, and some of their choices are good. The question is which decisions the platform takes away from them and which it leaves. A Standard Nobody Could Deviate From sorts technology decisions into common requirements, supported defaults with alternatives, and local choice. Applied to AI, the three tiers look like this.

Required. Every model call from a production application passes through the gateway, and no application holds a provider key. Every agent that acts on a repository or a system receives credentials from the broker rather than from a person. These rules are mandatory for a reason that cost does not supply. In the fictional estimate, each of the seven teams that wrote its own access layer spent about 4 engineer-months building it and runs it at 0.3 of an engineer, which is 4 + 0.3 × 12 = 7.6 engineer-months in the first year. Fourteen teams doing the same would spend 14 × 7.6 = 106.4. The gateway costs 27, plus an estimated 0.5 engineer-month of integration per team, so 27 + 14 × 0.5 = 34. The difference is 72.4 engineer-months. The cost case is also easy to satisfy: with n teams adopting and the rest building their own, the gateway breaks even at about 3.8 adopters (27 + 0.5n = 7.6n). Cost alone would justify a voluntary offering.

The control case is different. A quota that covers only some callers does not prevent one team from consuming the shared provider limit. A data-classification rule that applies to ten of fourteen applications leaves four free to send customer records to any model. Usage records with gaps cannot support cost allocation. These controls have value only when coverage is complete, so the requirement attaches to the control, not to the cost saving, and the platform owes teams a gateway that is easy to use in return. A gateway that is slower or harder than calling a provider directly will be routed around, which is the pattern Golden Paths and the Platform Contract describes for any supported path.

Supported default. For coding assistants, the platform standardizes the integration contract and not the product. The contract covers single sign-on, data-handling terms, repository configuration managed by the organization, and usage telemetry. The platform integrates and supports two products in depth. A third can be used if it meets the contract and the requesting team accepts that its problems go to the vendor. That support bargain keeps procurement from being the platform’s bottleneck while limiting the number of combinations the platform has to test.

Local choice. Prompt design, orchestration libraries, evaluation sets, and editor settings stay with teams, within the data rules the gateway enforces. DORA’s platform research warns against a “golden cage,” a platform so rigid that teams stop benefiting from it, and recommends constraints that enable work. The retailer’s constraints are narrow and tied to named risks.

An exception route completes the arrangement. A team that cannot meet a required rule submits the need, the proposed alternative, and the controls it will operate. The decision names an owner and either an expiry or a review date. The vice president reads the exception log by reason each quarter. Three teams asking for streaming responses that the gateway does not support point to a missing gateway feature, not to three disobedient teams.

Developer AI tooling: the constraint is verification

The strongest pressure on the platform comes from the assistants, because every executive has seen a demonstration. The evidence about their effect is not uniform. DORA’s 2025 report finds that 90% of respondents use AI at work and that, unlike the year before, AI adoption has a positive relationship with software delivery throughput. It also finds that adoption continues to have a negative relationship with delivery stability, and it attributes that to change volume rising faster than the controls that absorb it: automated testing, version control practice, and fast feedback. METR’s 2025 randomized study looked at a narrower setting. Sixteen experienced open-source developers completed 246 issues from their own repositories, with AI use randomly allowed or disallowed per issue, and tasks took 19% longer with AI allowed. The developers had expected a 24% speedup and, afterward, still believed AI had sped them up by 20%. METR is explicit that the result may not apply to most developers and reflects early-2025 tools.

The two sources do not contradict each other. They measure different things in different populations, and both show that how fast work feels is not a measurement of how fast it ships. For the retailer that means the decision to expand cannot rest on a survey of satisfied users. Measuring an AI Development Tool Rollout covers how to build a comparison that can support it: cohorts chosen by the platform and not by volunteers, a stated outcome, and limits agreed before the data arrives.

Licensing is the first place a measurement discipline changes money. The three contracts cover 1,100 seats. At month three, 682 engineers use an assistant in a typical week, which is 62%. Each active seat therefore costs 1 / 0.62 = 1.61 times its list price. The tempting responses are to mandate use to improve that ratio or to buy more seats to end the argument. The better one is to license in stages: teams receive seats when their pipeline can verify changes and they have agreed to the measurement, and unused seats are reassigned at renewal.

The verification constraint can be put in numbers. Suppose a typical team of twelve can complete 24 code reviews a week, and 18 changes arrive for review, a utilization of 18 / 24 = 75%. In a simple single-queue model with random arrivals, the average wait in the queue, measured in review durations, is utilization divided by one minus utilization: 0.75 / 0.25 = 3. Assistants raise the volume of changes by 25%, to 22.5 a week. Utilization becomes 22.5 / 24 = 93.75%, and the same formula gives 0.9375 / 0.0625 = 15, five times the wait with only 25% more work. Now suppose generated changes are larger and less familiar, so each review takes 20% longer. Capacity falls to 24 / 1.2 = 20 reviews a week against 22.5 arriving. Utilization is 112.5%, the queue has no steady state, and the backlog grows by 2.5 changes a week, or 30 over a quarter. The model is a simplification, since real arrivals and review times vary, but it shows why more code written per hour does not mean more code shipped. The bottleneck moves to the step where someone has to be convinced the change is right, and the DORA stability finding is what the overflow looks like in production.

Three platform investments follow. The first is automated verification in the pipeline, so that review attention goes to design and risk instead of syntax and missing tests; Testing and Reviewing AI-Generated Code in CI describes the layers. The second is guidance that keeps changes small, which DORA’s capabilities model names directly and which keeps the review queue near the 75% case. The third is measuring what the queue exposes: review wait and change failure rate, not the count of suggestions accepted or changes opened. Integrating AI Coding Tools with Enterprise Repositories covers the data-flow side of the integration contract: what the tool can read, what leaves the machine, and who controls its configuration.

Agents raise a separate question, because they act. The OWASP Top 10 for LLM Applications traces damaging agent behavior to excessive functionality, excessive permissions, and excessive autonomy, and recommends minimal tool sets, least-privilege permissions executed in the user’s context, and human approval for high-impact actions. The team that gave an agent a personal deployment token committed all three at once: the agent could deploy, with the permissions of a senior engineer, without anyone approving. The interim rule while the broker is built is explicit. Agents may read repositories and write to a working branch. They hold no deployment credentials, and a person merges. When the broker ships in the second half of the year, agents receive short-lived credentials scoped to a task, as Operating Coding Agents with Restricted Permissions describes. The interim rule is a leadership decision because it costs the six teams some speed immediately, in exchange for a failure that cannot be reversed by a rollback.

Shared runtime services and the dependency they create

A gateway turns many independent provider connections into one internal dependency. Its function, its controls, and the mechanics of quotas, version retirement, and fallback are covered in Every Team Had Its Own Key. The leader’s questions are different. Who is on call for it? What availability does it promise? What do applications do when it is down? Who decides how a limited provider allowance is divided?

The last question looks technical but is a business priority call. When a batch summarization job and the customer-facing assistant draw on one provider limit, someone has to decide which one yields first, and an engineer should not be left to guess. The vice president takes the question to the product owners, records the answer as a priority class for each application, and has the gateway enforce it. This also turns the platform’s role into something stable: it enforces priorities that other executives set.

Availability arithmetic shows where the next investment belongs. Take a 30-day month of 43,200 minutes. Assume the gateway meets a 99.9% objective and a single model provider is available 99.5% of the time. An application needs both, so the path is available 0.999 × 0.995 = 99.4005% of the time, and the expected unavailability is 258.98 minutes. A second provider that is tested, approved for the data involved, and has enough capacity changes the result. If its failures were independent of the first provider’s, the pair would be unavailable only when both are, which happens 0.005 × 0.005 = 0.0025% of the time, so the pair is 99.9975% available. With the gateway in front, the path is 0.999 × 0.999975 = 99.8975% available, about 44.28 minutes of expected unavailability. Of that, 43.2 minutes come from the gateway itself.

The lesson is where the weakest link sits once the provider is redundant. After a second provider is added, the platform’s own service is the largest remaining contributor, and further provider redundancy buys almost nothing. The independence assumption is optimistic, since providers can share regions, networks, or capacity, and a fallback model may not give acceptable answers for every application. Model fallback covers why a second path must be independent of the failure it handles. The conclusion stands anyway: reliability work for AI features is largely work on the gateway, its deployment process, and its redundancy.

That brings up the decision the gateway forces on every consuming team: when it is unavailable, does the application stop or call the provider directly? Failing open preserves the feature but runs it without the quota, data, and logging controls. Failing closed preserves the controls and interrupts the feature. The retailer decides by data class. Any request that carries customer records fails closed. Internal summarization may queue its work and retry later. The classification, not the platform team, decides which path applies, and the gateway reads it.

Paying for reliability and for spend

Reliability is a purchase with diminishing returns. Google’s SRE book observes that an incremental improvement in reliability may cost 100 times as much as the previous increment, which is why the target should follow what consumers need. The retailer sets two. The gateway’s customer-facing path has a 99.9% objective, which allows 43.2 minutes of unavailability in a 30-day month, or 10,000 failed requests out of 10 million. The integration that serves developer assistants (single sign-on, policy distribution, telemetry) has a 99.5% objective, 216 minutes, because an outage there leaves developers working the old way and does not stop a customer purchase. Spending effort to make the second as reliable as the first would take capacity from items that matter more. SLIs, SLOs, and Error Budgets covers how indicators and budgets are defined.

The error budget needs a policy that someone with authority can enforce. The retailer’s says that when the gateway has used its monthly budget, changes to the gateway pause except for security fixes, and the next sprint’s capacity goes to reliability work. The vice president agrees with the CTO in advance that she can apply that policy even when a product team asks for a new routing feature, because the budget has no meaning if it can be waived at the moment it matters.

Spend needs the same treatment: visible first, and acted on by the people who can change it. Model API charges are driven by tokens and calls, and the FinOps Foundation notes that allocating them is hard because consumers of the same model can be different features inside one application, and that forecasting AI spend is less predictable, especially in the early stages of a practice. The gateway helps by recording each logical request and each provider attempt separately, because retries and fallbacks cost money without producing a second result.

A fictional month for one team shows the effect. The team made 1,000,000 logical requests, which produced 1,180,000 provider attempts, because retries and fallbacks add 18%. Each attempt costs 0.012 currency units, so the month costs 1,180,000 × 0.012 = 14,160. A report that counts only logical requests gives 0.012 per request, which would be right if every call succeeded once. Of the 1,000,000 requests, 82% produced a result the application accepted, which is 820,000 results. The cost per accepted result is 14,160 / 820,000 = 0.0173, about 44% above the naive figure. The retry rate and the acceptance rate are both visible and both actionable, which a per-request price is not. Cost per successful task defines the measure and why it differs from cost per request. A feature whose per-request price falls after a model change but whose acceptance rate falls more has become more expensive to operate.

The retailer starts with showback: each team sees its spend and its cost per accepted result, and no budgets move. Charging teams comes later, once allocation rules for shared costs such as gateway operation and unused reserved capacity are agreed and the first disputes are resolved. Commitments wait for the same reason. A reservation like provisioned throughput pays for capacity whether it is used or not, so buying it before two or three months of attributed usage amounts to a bet on a forecast that the FinOps Foundation describes as less predictable. The Bill Doubled works through commitment risk and the coverage and utilization measures that apply.

What the plan commits, and what reopens it

The plan the vice president takes to the CTO commits 71 of 84 engineer-months, leaving 13, about 15% of the AI capacity, as reserve. It funds the gateway, assistant enablement, the agent sandbox with its credential broker, and cost showback. It defers the shared evaluation harness and declines to build retrieval and inference services, each with a reopening condition. It requires gateway use and brokered credentials, supports two assistants through an integration contract, and leaves the remaining choices with teams. It sets a stricter objective for the customer path than for developer tooling. It licenses assistant seats in stages, with the measured comparison attached, and it runs agents under the interim restrictions until the broker exists.

Each decision has a signal that reopens it. Calls that bypass the gateway, found by comparing provider billing with gateway records, mean the easy path is not easy enough. Exceptions that cluster on one reason mean a missing feature. A rising review wait or change failure rate in teams with assistants means verification investment is behind the tooling. An exhausted error budget changes the next quarter’s allocation. Spend through managed endpoints crossing the self-hosting threshold reopens inference. The vice president reviews these signals with the CTO each quarter and changes the plan when they say the plan is wrong, because the point of writing the conditions down was to make that conversation possible without a new argument about what the platform is for.

References

• Google Cloud, Announcing the 2025 DORA Report (State of AI-assisted Software Development).
• Google Cloud, Introducing DORA’s inaugural AI Capabilities Model.
• DORA, Capabilities: Platform engineering.
• METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, July 2025.
• OWASP Gen AI Security Project, LLM06:2025 Excessive Agency.
• Google, Site Reliability Engineering, Chapter 3: Embracing Risk.
• FinOps Foundation, FinOps for AI Overview.