Count all TypeScript repos in the Opus 4.7 corpus. You get 3,006.

Count them again and check for a tsconfig.json. You get 3,006.

100%. Every TypeScript repo Opus 4.7 commits has a tsconfig. There’s not a single “started as JS and added a few types” repo.

Why it matters

TypeScript adoption has a subtle split in the wider ecosystem:

  • Fully-typed — repos that start with TS, have strict mode, use interfaces, type every return
  • Typed-in-name-only — repos with .ts extensions but any everywhere, loose tsconfig, optional typing

Opus 4.7 writes exclusively the first kind. This is a strong prior:

  1. Strict settings default: Opus 4.7 generates tsconfigs with "strict": true unless explicitly told not to
  2. Interfaces over types for contracts: the median interface in the corpus is 6 lines, p90 is 16 — tight, contract-shaped
  3. Generics are common: Zod (3,191 imports), TanStack Query (3,418) both heavily leverage TS generics; Opus 4.7 uses them idiomatically

The data that supports this

From the symbol parser, looking at TypeScript repos only:

  • 117,495 interface declarations extracted
  • Median interface: 6 lines, p90: 16
  • 90,331 type aliases extracted
  • TypeScript-specific imports (@types/*, type ... = ...) dominate

These numbers wouldn’t happen in loosely-typed TypeScript. They require a code-writer who treats types as primary.

The 100% tsconfig fact

The 3,006 / 3,006 ratio is actually more interesting than “Opus uses TypeScript.” It means:

  • No accidental plain JS — no repo where someone ran tsc --init once and forgot about it
  • The scaffold includes tsconfig — whatever initial prompt structure Opus 4.7 uses, tsconfig is in it
  • Config is consistent — same pattern repeated thousands of times

We don’t have a breakdown of strict: true vs strict: false (parsing the JSON inside each file would give it). But anecdotally, scanning the config files, strict mode is the default — consistent with Next.js’s own default tsconfig.json which enables strict.

Why Opus 4.7 does this vs other models

Three theories:

1. Training data bias

Opus 4.7’s training corpus likely included modern, typed TypeScript heavily. The model’s “mode of TypeScript” is strict TypeScript.

2. Tailwind-shadcn-Next.js ecosystem pull

Every framework in the default Opus 4.7 stack publishes TS types and expects strict consumption. Writing untyped code in this ecosystem triggers type errors. The model learned to avoid that friction.

3. Agent feedback loops

In an agent loop, if the model writes any, the next tsc invocation flags it. The model’s natural correction is to add the proper type. Over many iterations, this reinforces “write types, never any.”

What this means for downstream use

If your product consumes Opus 4.7 code and needs to:

  • Auto-transpile — easy, strict TS compiles cleanly
  • Generate bindings — straightforward, types are declared
  • Extract API contracts — interface declarations are ready-made specs
  • Cross-compile to another language — Opus 4.7 outputs type info, not inferred shapes

This is a real technical advantage over AI-generated code that’s loosely typed.

The opposite observation: async detection

Our parser can’t detect async keywords in TypeScript signatures consistently. This is a known parser artifact, not a statement about Opus 4.7’s code. Async/await is used heavily — we just don’t surface it in our signature field for TS/JS yet.

Counterpoint: Opus 4.7 Writes Short Functions — Median 9 Lines for the function-level style.