// Substrate · Engineering
The Scaffolding Tax: Where AI-Assisted Backend Work Actually Goes
In an exploratory API study, 34–40% of billed model tokens went to platform work rather than task-specific endpoint logic. The feature was still the largest share. But the plumbing was a substantial part of the bill — and it is the part a good engineering platform can make reusable.
When teams talk about AI-assisted software development, the conversation usually starts with the feature: can an assistant implement order creation, enforce stock rules, or keep a transaction correct under failure? Those are the right questions. They are also incomplete.
A production service also needs database setup, authentication, access control, rate limiting, tracing, and predictable errors. None is optional; much is repeatable.
That raises a practical question for engineering leaders: when an AI assistant builds a backend, how much of its interaction budget goes to reusable platform concerns, and how much goes to task-specific logic?
Our exploratory study finds a material minority of model interaction went to platform scaffolding — large enough to matter when a team decides what to standardize, generate, or provide as a trusted baseline.
The experiment: an allocation study, not a model contest
We evaluated the same production-shaped REST API across four implementation cells: Python with raw SQL, Python with a query-builder-and-validation bundle, TypeScript with raw SQL, and TypeScript with the equivalent bundle. Each cell used PostgreSQL and the same black-box HTTP contracts.
The work was split into three reporting buckets:
- Base facade: repository structure, database connection setup, schema/migration work, and a health endpoint.
- Resilient facade: authentication, role-based access control, rate limiting, tracing, and consistent error responses.
- Task-specific logic: CRUD endpoints plus transactional order logic, including stock validation and rollback behavior.
The study used two frontier coding models. The replicated allocation table below comes from five stochastic runs per cell in the complete matrix. Each stage began from a reviewed, fixed baseline. The study estimates marginal layer costs; it does not measure one model building a service uninterrupted from scratch.
For each run, we recorded billed tokens: input, completion, and reasoning tokens across all model turns. We summed those tokens for every run, including runs that did not pass the hidden test suite, and normalized the totals into a three-way share. That makes the metric a measure of model-interaction allocation, not a quality score, a count of source-code tokens, or a dollar-cost comparison.
Where the tokens went
Here is the replicated allocation split across the four implementation configurations. Each value is the mean share of billed tokens across five stochastic runs; brackets show the observed minimum–maximum range.
| Build | Base facade | Resilient facade | Task-specific logic |
|---|---|---|---|
| Python · raw SQL | 13% [12–15] | 21% [20–22] | 66% [65–67] |
| Python · query/validation bundle | 17% [11–29] | 23% [19–25] | 60% [52–63] |
| TypeScript · raw SQL | 14% [10–21] | 21% [19–25] | 65% [59–70] |
| TypeScript · query/validation bundle | 16% [8–25] | 20% [15–24] | 65% [55–77] |
Across those four cells, the two facade buckets represented 34–40% of billed tokens on average. Task-specific logic remained the largest category, at 60–66% in the per-cell means. The finding is not that plumbing outweighs product work; it is that the service foundation is a consequential share of AI-assisted implementation effort.
Resilience work accounted for much of that share. Authentication, authorization, error contracts, request controls, and observability may sit in the background of an architecture diagram, but they are not background in model interaction.
The real implication: move repetition out of the prompt
"Scaffolding tax" is not a claim that this work is wasted or that a model struggles with it. The controls in the resilient facade are necessary. The tax is the repeated model interaction required to recreate and re-check them for each new service.
That suggests a different optimization target: reduce the platform work an assistant needs to invent at all.
For example, a trusted internal template can supply a connection lifecycle, authentication boundary, error envelope, telemetry conventions, and deployment defaults. A scaffold generator can create known parts deterministically; a reviewed shared library can own rate limiting or authorization policy. The assistant then begins closer to the task-specific change.
We did not measure review time, maintenance cost, or savings from platform investments. Those are hypotheses, not results. The allocation result simply makes them worth testing.
Abstractions redistribute work; they do not magically erase it
The raw-SQL and query-builder-plus-validation comparison yields a less dramatic result than a framework debate.
In the replicated matrix, the bundled approach tended toward a larger Python base share, but its range was wide. Its task-specific share was nearly unchanged on average, with more uncertainty in TypeScript. This is not a universal cost rule. It shows that abstractions can relocate model interaction: schemas, interfaces, and validation rules may appear earlier, while later work may or may not become simpler.
The architectural decision therefore remains broader than tokens. Teams should weigh developer fluency, reviewer availability, operational maturity, hiring, library and security posture, data-access complexity, performance requirements, portability, debugging ergonomics, and the fit between business rules and the chosen programming model. AI interaction volume is one input to that decision — not a substitute for it.
What the evidence can support
This is an exploratory case study: one API task family, modest replication, one complete model matrix, and a partial second-model check. The shares can move with the task, baseline quality, prompting, tooling, model snapshot, and existing platform.
There is an additional measurement discipline worth making explicit. A defect in an early business-logic test oracle was corrected and the affected reliability stage was re-run. The correction does not change the billed-token allocation figures, but it means reliability claims must use the corrected runs rather than the original matrix. We therefore keep allocation and conformance separate: a token share tells us where interaction occurred; passing hidden tests tells us whether a particular stage met its contract.
Do not copy these percentages into a budget. Repeat the analysis on representative greenfield, established-system, and difficult domain work; then measure first-pass conformance, repair loops, review effort, and ownership as well as tokens.
The takeaway
AI-assisted development does not make the platform layer disappear. It makes the amount of repeated platform work visible in a new unit: the model interaction needed to construct, validate, and repair it.
Here, that work was roughly a third to two-fifths of billed tokens. The feature remained the largest slice, but the scaffolding is large enough to be an engineering strategy question: what should a model recreate, and what should an organization provide once, review thoroughly, and reuse with confidence?
That is the useful version of the scaffolding-tax idea. Not "AI writes too much plumbing," and not "one language or model wins." It is that the architecture of your engineering platform determines where AI-assisted effort can accumulate — and where it can be designed away.
Method note
The study used two frontier coding models. It does not compare their performance; the underlying run-level data, data dictionary, and reproduction scripts distinguish allocation figures from corrected conformance results. This article reports exploratory evidence, not a confirmatory benchmark.