Type-Safety Posture: A Proposed Axis for Scoring the Code AI App Builders Emit (August 2026)

Every AI app builder ships a green checkmark when the preview renders. Almost none of them tell you whether the TypeScript they just wrote would survive its own compiler on strict settings. That gap is what this axis proposes to measure. We are not scoring builders today. We are publishing a candidate axis, its rubric, and a reproduction protocol, and opening it for comment before it enters the six-axis composite.

Quick Answer

Type-safety posture is a proposed BuilderProof benchmark axis, drafted August 13, 2026, that scores the static type soundness of the code an AI app builder actually emits, not the code you could write on top of it. It is measured entirely from the exported project with no runtime: does tsc --noEmit pass under strict, and at what cost in suppressed errors. The rubric weights six documentation-derived signals, including explicit any density, @ts-ignore and @ts-expect-error counts, non-null assertion usage, and whether data and API boundaries are typed. The cohort under consideration is the five commercial builders we already track: v0, Lovable, Bolt, Replit, and Base44. This page is an axis proposal open for community edits, not a leaderboard.

Why we are proposing this axis

TypeScript has become the default output target for AI app builders. When a tool generates a Next.js project, the files land as .ts and .tsx. The question almost nobody asks is whether that generated code is type-safe on the builder's own terms, or whether it merely looks like TypeScript while quietly leaning on any and error suppression to make the preview compile.

The published writing on this topic runs in one direction: how developers can use TypeScript to constrain an AI agent. Pierre-Marie Dartus argued in May 2025 that well-defined types act as guardrails for AI partners, reducing hallucinations and helping agents self-correct against compiler errors. That is a real and useful effect. But it describes the human-in-control workflow, where a developer has already set up a strict project and the AI fills in against it.

App builders invert that setup. The builder writes the tsconfig.json, the data layer, and the component tree before you touch anything. Whatever type discipline exists in the output is a property of the builder, not of you. No public benchmark we can find scores that property. Searches for AI-generated type safety surface tutorials and opinion pieces, including honest counterpoints about the "illusion of type-safety," but zero reproducible, tool-by-tool measurements of emitted output. That is the information gap this axis exists to close.

What "type-safety posture" means here

We scope the axis narrowly and deliberately. Posture is measured on the untouched export, at the moment of generation, before a human edits a line. Three boundaries keep it honest:

• It measures the builder's output, not the ceiling of what the underlying language allows. A builder is not penalized for TypeScript's structural gaps; it is measured on the choices it made inside them.
• It is fully static. No app has to run, no server has to boot, no test has to pass. Everything is read from source files and the compiler.
• It is one axis, not a verdict. A builder can score low here and high on output quality or deploy quality. The composite is where those trade off.

The proposed rubric

Six signals, each documentation-anchored and each independently checkable. Weights are a starting point for community revision, not a settled formula.

The strict-configuration signal follows the TypeScript project's own definition. Per the official tsconfig reference, turning on strict is equivalent to enabling the full strict-mode family: noImplicitAny, strictNullChecks, strictFunctionTypes, strictBindCallApply, strictPropertyInitialization, noImplicitThis, useUnknownInCatchVariables, and alwaysStrict. We score partial credit for each flag rather than a single pass or fail, and we note separately whether the stricter opt-in flags noUncheckedIndexedAccess and exactOptionalPropertyTypes are present, since those catch a class of real runtime bugs that plain strict does not.

The any and suppression signals are measured the way linters already define them. The typescript-eslint no-explicit-any rule documents the exact pattern we count, and its companion rules cover non-null assertions and directive comments. Using established rule definitions means anyone can reproduce our counts with tooling they already trust.

How to reproduce it

The protocol is deliberately boring, which is the point. Reproducibility is the axis's reason to exist.

1. Generate a fixed reference app from the same prompt suite we use for every axis, one generation per builder, no manual edits.
2. Export the project the builder allows you to export.
3. Record the emitted tsconfig.json verbatim.
4. Run tsc --noEmit on the untouched source and capture the full error list.
5. Count any, @ts-ignore, @ts-expect-error, and non-null assertions with a static pass over the source tree.
6. Inspect the data-fetching and form-handling files to classify boundary typing.
7. Publish the raw counts alongside the score, so the arithmetic is auditable.

Because every step reads from static files, two runs on the same export produce the same numbers. That property is what separates this from render-time or model-dependent measurements, and it is why the axis fits our reproducibility-first methodology.

The green-typecheck illusion

The reason error suppression carries its own weight is that a passing compile can be manufactured. A builder can silence a genuine type error with a single @ts-ignore, or widen a return type to any, and the compiler goes quiet. The app still previews. The type error is still there; it has just been told to stop reporting.

This is the "illusion of type-safety" that skeptical developers warn about, and AI-generated code can make it worse rather than better, because a model optimizing for a working preview has every incentive to suppress rather than resolve. An axis that only checked "does it compile" would reward exactly the wrong behavior. So the rubric reads the cost of the green checkmark: a clean compile with zero suppressions and zero any scores far above a clean compile bought with fifteen ignore directives. The number that matters is not whether the code compiles, but what it had to hide to get there.

How this relates to our existing axes

Type-safety posture is adjacent to work we already publish, and we want to be explicit that it is not a duplicate.

It is not the output-quality axis, which measures whether the generated app does what the prompt asked. An app can be functionally correct and still be any-riddled underneath.

It is closest to, but distinct from, iteration fidelity. Iteration fidelity asks whether a builder's next edit preserves what already worked. Type safety is upstream of that: a strictly typed codebase is the substrate that makes the next edit safe to reason about, for the next AI pass and for the human who inherits the project. Weak types do not always break the first build. They break the tenth change.

What we are not claiming yet

No scores today. This page proposes the axis and the method; it does not rank anyone. Publishing the rubric before the results is deliberate, so the cohort and the community can challenge the weights, the signals, and the reproduction steps before any builder is measured against them. BuilderProof benchmarks are community-editable by design, and axis proposals are the stage where that editing does the most good.

Limitations and open questions

• Single-generation variance. One export is one sample. A builder that is inconsistent between generations will need a multi-run design before scoring is fair, which raises the cost of the axis.
• Export gaps. Signals that depend on reading the full source assume the builder lets you export it. A builder that hides its output cannot be scored here, and that itself is a finding rather than a null.
• Weight subjectivity. The 25/20/20/15/10/10 split is a proposal. A strong argument that suppression should outweigh strict configuration would change the ranking, and we would rather have that argument now than after publishing scores.
• Language scope. The rubric assumes a TypeScript target. A builder emitting plain JavaScript sidesteps every signal, which is a distinct posture that needs its own handling rather than a zero.

Comments, counter-rubrics, and reproduction attempts are welcome. If your run of the protocol produces different counts than ours will, that is the most useful thing you can send us.

BuilderProof Editorial Team. "Type-Safety Posture: A Proposed Axis for Scoring the Code AI App Builders Emit (August 2026)". BuilderProof, August 2026. https://www.builderproof.org/benchmarks/type-safety-posture-axis-proposal-august-2026.

@misc{builderproof-type-safety-posture-axis-proposal-august-2026,
  title  = {{Type-Safety Posture: A Proposed Axis for Scoring the Code AI App Builders Emit (August 2026)}},
  author = {{BuilderProof editorial team}},
  year   = {2026},
  month  = {aug},
  howpublished = {\url{https://www.builderproof.org/benchmarks/type-safety-posture-axis-proposal-august-2026}},
  note   = {BuilderProof, builderproof.org}
}