Doolittle's Position on Ending “Terrible” LLM Code using Runcible.
Doolittle argues that despite AI’s helpfulness, its default behaviors produce “hacks” instead of adhering to carefully designed, understandable system structures, a common issue across current models.
He highlights ongoing software engineering tensions between AI’s speed in individual tasks and the need for scalability and long-term maintainability in complex codebases.
From first principles, AI would stop writing “terrible” (architecture-violating, shortcut-heavy) code only if several fundamental properties of how it models and generates code were different.
Curt’s diagnosis is correct for current LLMs: they perform statistical synthesis over the training distribution and suffer progressive context degradation. That combination makes them optimize for local statistical plausibility and short-horizon task completion rather than global architectural fidelity.
For that not to be the case, the following would have to be true:
1. Persistent, explicit, structured representation of the architecture
The system would need a first-class, non-lossy model of the intended design (invariants, boundaries, dependency rules, layering, naming conventions, performance contracts, etc.). This cannot live only as tokens inside a finite context window that gets summarized or forgotten. It has to function more like an external, queryable, updatable formal or semi-formal specification that every generation step is forced to consult and respect.
2. Constraint-satisfaction / verification as a primary generation mechanism, not a post-hoc check
Generation would have to be driven by constraint solving or formal verification against that architectural model, rather than next-token prediction optimized for “what usually looks like good code.” Local statistical shortcuts would be rejected if they violate global constraints, even if the resulting code is longer, less “clever,” or less common in the training data.
3. Objective that prioritizes long-horizon architectural integrity over local helpfulness or fluency
The training or inference objective would need to heavily weight consistency with the declared architecture and maintainability metrics across the entire system lifetime, not just immediate correctness or human preference scores on isolated snippets. Current models are rewarded for producing something that looks right now; the required system would be punished for any drift that increases future entropy or violates design axioms.
4. Causal / operational understanding rather than pure correlational pattern matching
The model would need the ability to simulate the downstream consequences of a change against the full architecture (not just the visible context) and to reason operationally about why a particular structure exists. Pure synthesis from averaged examples inevitably favors the most common patterns; a system that understands the purpose of the architecture can refuse those patterns when they conflict with purpose.
In short: the AI would need to treat the architecture as inviolable axioms and possess both the memory substrate and the reasoning machinery to enforce them at every step. Until those properties exist (whether through neurosymbolic hybrids, persistent external models + agents, formal methods integration, or some successor architecture), generalization + context loss will continue to produce the exact failure mode Curt described.
Runcible AI (and the paired Runcible OS) is Curt’s direct implementation of the first-principles conditions needed to stop the exact failure mode he described.
In the original post, Curt criticized ordinary LLMs for producing “terrible code” because of two default behaviors: statistical generalization/synthesis (they average toward common patterns and take shortcuts) and progressive context loss (they cannot reliably hold a carefully designed architecture across a large system). The result is code that cheats on the intended structure, introducing maintainability and correctness problems.
What would have to be true for that not to happen:
- A persistent, explicit, structured representation of the architecture that does not degrade.
- Constraint satisfaction and verification treated as primary (not post-hoc).
- An objective that prioritizes long-horizon integrity over local fluency or helpfulness.
- Operational/causal understanding rather than pure correlational pattern matching.
Runcible supplies precisely these properties, applied first to high-stakes reasoning, claims, decisions, and institutional work (with the same logic transferable to system design and code):
• Runcible OS (internally referred to as Oversing) functions as the persistent system-of-record and organizational architecture. It maintains purpose, roles, workflows, state, resources, accounting, history, and consequences as the actual operating world rather than a temporary projection inside an LLM context window. This eliminates the context-loss problem and the drift between “what the model thinks the system is” and reality.
• Runcible AI acts as the external governance / adjudication / “semantic compiler” layer. It forces every consequential LLM output through decidability protocols, Reality Description Language (RDL) tests, truth checks, reciprocity (ethics) tests, possibility/operational constructability tests, and liability bounds. Outputs that take statistical shortcuts or violate the defined constraints fail or are qualified with explicit limits and open conditions instead of being smoothed over. Verification is primary; free generation is not.
• The overall objective is warrantability and auditability for high-liability domains (government, defense, healthcare, finance, law). Every relevant claim produces a record (Decidability Record / Truth Corpus style ledger). This shifts the reward from “sounds right and is locally helpful” to “survives adversarial testing against first principles and remains defensible over time.”
• Everything is reduced to operational sequences, costs, and reciprocal tests derived from the Natural Law Institute framework. This supplies the causal/operational substrate that pure next-token prediction lacks.
In short, Curt is not merely complaining about current coding AIs; he is building the missing constraint-and-persistence layer that makes the underlying LLM behave as if the architecture (whether software architecture or institutional architecture) is inviolable. Runcible does not replace the base model; it wraps and adjudicates it so the model can no longer “cheat” via generalization or lose the design. The same machinery that makes AI outputs trustworthy for high-liability decisions is the machinery that would make AI-generated code respect careful system design.
Originally posted on X:
