Answer.AI invokes Naur's "Programming as Theory Building" to dissect LLM coding limits

On August 19, Answer.AI published a long-form essay by Pol Alvarez Vecino using Peter Naur's classic paper "Programming as Theory Building" to analyze the core limits of LLM coding; Rachel Thomas threaded the key points on X. The upshot: however much code LLMs generate, they cannot replace the engineer's mental theory of the program.

Confirmed

Core thesis: a program's essence is the "theory" held by those who built and maintain it — the constraints, trade-offs, and what modifications fit its design. Code is a downstream residue; the complexity that matters is "theory complexity."
On external abstractions: vendor SDKs greatly simplify your theory while the contract holds, but once you must debug, modify, or reason outside the contract, the hidden complexity becomes yours.
On vendor trends: both the author and Rachel Thomas observe OpenAI and Anthropic increasingly hiding data server-side (e.g., encrypted context compression, reasoning tokens), leaving abstraction-layer vendors with three bad options: expose vendor-specific details, reimplement fragile compatibility logic, or admit they cannot faithfully represent underlying capabilities.
On trade-offs: letting LLMs run free yields code fast, but pursuing understanding and theoretical simplification is slower and harder with higher long-term payoff, surfacing hidden details.

Why it matters

The essay offers a theoretical frame for the debate over whether LLMs can truly do software engineering: if maintenance is fundamentally about transmitting a theory, code generation alone won't cut long-term maintenance costs. For teams building LLM abstraction layers and agent tooling, server-side data hiding directly threatens compatibility and credibility.

2026-08-19 ~ 2026-08-19 · 5 related posts

Primary sources

Why LLMs can't make your code simpler, per Naur's "Programming as Theory Building" — math_rachel · 2026-08-19 15:23 (UTC+08:00)
OpenAI and Anthropic hide more data server-side, making abstraction layers brittle — math_rachel · 2026-08-19 15:23 (UTC+08:00)
A program is the Theory in its builders' minds, not the code — math_rachel · 2026-08-19 15:23 (UTC+08:00)

[source] Why LLMs can't make your code simpler, per Naur's "Programming as Theory Building" — math_rachel · 2026-08-19
[source] A program is the Theory in its builders' minds, not the code — math_rachel · 2026-08-19
Abstractions simplify your Theory — until you debug beyond their contract — math_rachel · 2026-08-19
[source] OpenAI and Anthropic hide more data server-side, making abstraction layers brittle — math_rachel · 2026-08-19
Simplifying theory pays off more than quick LLM code generation long-term — math_rachel · 2026-08-19