The Illegible Advantage

An LLM can write a formal specification that compiles, passes syntax checks, and tests exactly the wrong properties.

Hillel Wayne recently demonstrated this: hand Claude or GPT an Alloy specification task, and they'll produce assertions that are tautologically true — verifying how a function was defined, not whether the system actually prevents unsafe behavior.[^1] The specs look rigorous. They catch nothing that matters. Concurrency bugs, liveness failures, nondeterministic edge cases — the properties a human specifier knows to look for because they've watched those categories of failure happen — go untested.

What's missing isn't technical skill. It's the knowledge of what to check.

Two Kinds of Work

James C. Scott, studying why ambitious state plans collapse, drew a distinction between legible and illegible knowledge.[^2] Legible knowledge is the kind institutions love: documented, standardized, transferable. Org charts. Style guides. Test suites. Legible work can be written down completely enough that someone else can execute it without loss.

Illegible knowledge resists that transfer — not because it's poorly documented, but because it lives in the relationship between a person and their domain. Peter Naur, in his 1985 paper "Programming as Theory Building," argued that the essential activity of programming isn't producing code.[^3] It's building a theory of the system — an internalized model of what the system does, why it's shaped this way, and how modifications should proceed. The theory lives in the programmer. The code is an artifact the theory produced.

You can hand someone the code, the documentation, the commit history, and every test. They still won't have the theory. They'll modify the system by pattern-matching against artifacts rather than reasoning from the model. They'll make changes that work locally and corrupt the design.

This is why Wayne's LLMs write specs that compile and test nothing real. They have the artifacts of specification — syntax, assertion patterns, structural templates. They don't have the theory: these are the properties that actually fail in production. That knowledge comes from watching systems break in specific ways, over time, with attention. It's illegible.

The Structural Shift

AI is collapsing the cost of legible work toward zero.

Code generation, boilerplate, documentation scaffolding, test templates, data transformation — anything that can be fully described in a prompt is legible by definition. If you can externalize it completely enough for an AI to execute, it was legible work. And legible work is getting cheaper by the month.

This doesn't make illegible work "the thing humans are still good at." That framing is defensive, and it misses the structural point. What's happening is simpler: when the cost of one category of work approaches zero, the other category becomes the entire source of scarcity.

Illegible knowledge doesn't get cheaper. Theory-building can't be parallelized. The judgment of which properties to test, which architectural decisions will compound, which abstraction will hold under pressure — these require presence with a system over time. Not processing power. Not token throughput. Attention.

The legible-illegible split isn't a hierarchy. It's a market. And the supply side just changed.

Delegate the Legible, Invest in the Illegible

The professional instinct is to systematize. Make your work legible — documented, reproducible, handoff-ready. That instinct was forged when legible work was valuable because it was reliable. It still is reliable. It's just no longer scarce.

The counterintuitive move: aggressively delegate every legible task, and reinvest the recovered time into illegible work. Not because illegible work is noble. Because it's structural advantage.

Run the audit on your own week:

• Legible tasks: code that follows documented patterns, reports that compile known data, tests that verify described behavior, communications that follow templates. Delegate these. AI handles them well. Let it.
• Illegible tasks — invest here. This is where your theory lives:
  • Knowing that this test suite misses the concurrency edge cases
  • Deciding which architecture will compound and which will collapse under pressure
  • Recognizing which user complaint signals a systemic problem, not a surface bug

The audit takes fifteen minutes. The reallocation compounds indefinitely.

The Theory Underneath

The developer who understands the system's shape uses AI to implement five times faster. The developer who doesn't understand the shape generates implementations that compile five times faster — and corrupt the design at the same rate.

The difference isn't talent. It's accumulated attention. One developer has spent time inside the system — watching it break, learning why it's shaped this way, building the internal model that no documentation contains. The other has the artifacts but not the relationship.

This is the part that doesn't scale. Attention compounds into theory. Theory compounds into judgment. Judgment is what tells you which properties to test, which architecture to bet on, which spec will catch the bugs that matter. Every layer depends on the one before it. None of them can be skipped, and none of them can be prompted.

The legible gets done either way. The question is who's still building the theory.

---

Sources

• Ashwin Sundar, "Do the Illegible" — Synthesizes James C. Scott's legibility theory with Peter Naur's theory-building view of programming
• Hillel Wayne, "LLMs are bad at vibing specifications" — Demonstrates that LLMs produce syntactically perfect formal specs that test obvious properties and miss what matters
• Peter Naur, "Programming as Theory Building" (1985) — The original argument that programming's essential activity is building an internalized theory of the system, not producing code
• James C. Scott, Seeing Like a State (1998) — The legibility framework: how institutions simplify complex knowledge into standardized, transferable forms, and what gets lost in the process

[^1]: Hillel Wayne, "LLMs are bad at vibing specifications" — Claude and GPT generate Alloy specs with correct syntax and tautologically true assertions that verify function definitions rather than system behavior.

[^2]: Ashwin Sundar, "Do the Illegible" — Synthesizes James C. Scott's legibility theory (from Seeing Like a State) with Peter Naur's "Programming as Theory Building" to argue that vibe-coding outsources theory-building to AI.

[^3]: Peter Naur, "Programming as Theory Building" (1985) — Argues that the programmer's essential contribution is an internalized theory of how the system maps to the real-world domain; code, documentation, and tests are artifacts of that theory, not substitutes for it.