What We Learned Scanning React

Clear Code Intelligence scanned the public React repository: react/react.

This is not a dunk on React.

React is one of the most important open-source frontend projects in the world. It is also exactly the kind of repository that shows why technical debt reporting has to be more than pattern matching.

Mature framework repositories contain runtime internals, compiler code, server rendering code, DevTools implementation, fixtures, generated expectations, changelog history, compatibility logic, build tooling, and long-lived public API decisions.

If a report treats all of that as the same kind of debt, the report is not useful.

What We Scanned

The Clear Code scan reviewed the public react/react repository and produced a technical diligence PDF report.

The scan measured:

• 7,228 repository files
• 7,070 analyzed files
• 1,033,022 lines of code
• 250 findings surfaced in the PDF
• 4,742 raw findings generated before report curation
• high AI token debt risk

The raw scorecard was intentionally severe:

Area	Score
Overall raw diligence	1/100
Projected after remediation	19/100
Architecture	6/100
Maintainability	0/100
Security	0/100
Delivery	0/100
AI governance	0/100

That raw score should not be read as "React is bad."

It should be read as "large framework repositories need scope-aware analysis before findings become decisions."

The Real Lesson: Scope Classification

React is a framework/runtime/compiler repository.

That matters.

A generic scanner can flag large files, dense lines, deferred-work markers, duplicated-looking logic, or complex control flow. Those signals are often useful, but they are not automatically equal.

A useful report has to classify evidence into buckets such as:

• production runtime implementation
• compiler implementation
• server rendering implementation
• DevTools implementation
• generated expectation fixture
• changelog or release history
• compatibility debt
• accepted framework complexity
• active remediation candidate
• false positive

Without that classification, a report becomes noisy.

With that classification, it becomes decision support.

Where AI Token Debt Shows Up

AI token debt is the extra context, search, inference, retry, and review work created when a codebase is hard to reason about.

React is a strong example because an AI agent working in this repository has to understand multiple layers of context:

• public API compatibility
• reconciler behavior
• server rendering and streaming behavior
• React Server Components and Flight surfaces
• compiler lowering and generated expectations
• DevTools behavior
• build/release modes
• test fixture intent

That is not a criticism. It is the nature of a mature public framework.

But it does mean an AI agent cannot safely modify many areas by reading one file. It must gather context, inspect related packages, understand fixture semantics, and avoid breaking compatibility assumptions.

That is the token tax.

The more the agent has to infer, the more it burns.

Interesting Hotspots

The scan surfaced deferred-work clusters in areas that are naturally expensive for AI agents to modify:

• packages/react-server/src/ReactFizzServer.js
• packages/react-server/src/ReactFlightServer.js
• packages/react-reconciler/src/ReactFiberCommitWork.js
• packages/react-reconciler/src/ReactFiberWorkLoop.js
• packages/react-client/src/ReactFlightClient.js
• compiler/packages/babel-plugin-react-compiler/src/HIR/BuildHIR.ts
• compiler/crates/react_compiler_lowering/src/build_hir.rs

Those are not automatically defects.

They are areas where context matters. A future human or AI agent touching these files needs to understand the surrounding protocol, runtime, compiler, compatibility, and test expectations before changing behavior.

That is exactly what a modern technical debt report should show.

Findings That Need Downgrades

The scan also exposed places where tooling needs to be smarter.

For example:

• CHANGELOG.md should not be scored like runtime code.
• generated compiler expectation files should not be scored like production implementation files.
• fixture names containing todo are often test taxonomy, not unmanaged delivery debt.
• long lines in release notes are not the same as long lines in business logic.
• framework compatibility comments can represent deliberate tradeoffs, not careless debt.

This is useful product feedback.

Clear Code needs to keep improving file-scope classification for framework repositories:

• changelog
• docs
• test fixture
• generated output
• snapshot
• benchmark
• compiler expectation
• runtime implementation
• public API surface
• accepted compatibility cost

That classification layer is what turns raw findings into executive-grade analysis.

Why This Matters for AI-Assisted Engineering

The next generation of technical debt is not only about human readability.

It is also about AI cost.

When code ownership is unclear, tests do not explain failure behavior, fixtures are indistinguishable from production code, and generated artifacts are mixed with implementation files, AI agents spend more tokens reconstructing context.

That cost appears as:

• larger prompts
• more file searches
• more tool calls
• more retries
• longer review cycles
• higher risk of hallucinated changes
• more human supervision

In other words, technical debt now charges interest in both engineering time and AI-agent operating cost.

What We Would Improve Next

The React scan was useful because it showed both the power and the limits of automated reporting.

The next version of the report should:

• classify framework repo paths before scoring severity
• separate raw score from interpreted score
• identify generated and fixture-heavy paths automatically
• distinguish accepted compatibility complexity from cleanup candidates
• show AI-token-debt drivers by domain area
• explain which findings deserve action and which deserve acknowledgement

That is the standard technical leaders need.

Not scanner dumps.

Decision support.

Invitation

Public repositories are useful because the evidence can be inspected and the methodology can be challenged.

If anyone from the React maintainer community wants the full PDF report, we would be glad to share it and hear where the scan should be corrected, tuned, or scoped differently.

Public code deserves public, fair, evidence-backed analysis.