Eliminating Code as the Intermediary Between Human Intent and Machine Execution
Programming languages exist as a concession to human cognition. They are the interface through which people express intent to machines, constrained by the need for humans to read, write, debug, and reason about the resulting artifacts. With the emergence of large language models capable of sophisticated bidirectional translation between natural language and formal systems, this constraint is no longer fundamental.
This paper proposes a paradigm we term the Semantic Compiler: a system in which AI translates human intent directly into LLVM Intermediate Representation, executes it, and then derives a semantic model of system behavior that can be compared against the original intent specification. The result is a closed-loop verification system in which correctness is defined not by test passage or code review, but by the structural alignment between what was requested and what was built.
Since v0.1 of this paper, the system described here has been implemented. A self-improving LLVM IR kernel reads English intent, generates validated IR, and rebuilds itself. The document you are reading is served by a 75KB binary that the kernel produced from a natural language description.
Modern software development relies on a single artifact—source code—to serve two fundamentally different purposes. First, it acts as an instruction set for the machine, ultimately compiled or interpreted into executable operations. Second, it serves as documentation of human intent, allowing developers to reason about, review, and maintain systems over time. These two functions impose contradictory pressures on the same artifact.
Optimizing for machine execution favors density, elimination of abstraction overhead, and exploitation of hardware-specific features. Optimizing for human comprehension favors readable variable names, modular organization, comments, and adherence to patterns that map onto human cognitive structures. Every programming language represents a compromise between these pressures.
The consequences are pervasive. Documentation drifts from implementation. Legacy systems become opaque as intent is lost through successive modifications. Architectural debates about microservices versus monoliths, REST versus GraphQL, OOP versus functional—these are arguments about human-side organization that have no bearing on optimal machine execution. The machine does not care about your design patterns. It cares about memory layout, branch prediction, and cache coherence.
We have accepted these problems as inherent to software development. They are not. They are inherent to code-as-intermediary. Remove code from the equation, and the problems dissolve.
LLVM Intermediate Representation already serves as the canonical bridge between high-level intent and machine execution. It is the compilation target for C, C++, Rust, Swift, and dozens of other languages. It is well-specified, heavily optimized, and designed explicitly to be the interface between “what the programmer meant” and “what the machine does.”
Today, the pipeline runs: human → programming language → compiler frontend → LLVM IR → machine code. The programming language and compiler frontend exist because humans cannot write LLVM IR fluently. But an AI can.
This is not merely a convenience optimization. It is a fundamental restructuring. When an AI targets IR directly, it can make semantic optimizations that no traditional compiler can achieve. A compiler processing source code operates on syntax trees and type systems. It does not know that a function implements a paywall check or that a loop iterates over subscription records. An AI that has translated natural language intent into IR retains this semantic context throughout, enabling optimizations that operate at the level of meaning rather than syntax.
Eliminating code from the intent-to-execution path solves the instruction problem but appears to create an inspection problem. If no human-readable source code exists, how do stakeholders understand what a system does? The answer: understanding does not require code—it requires a semantic bridge.
The Semantic Bridge is an AI-mediated layer that provides bidirectional translation between machine behavior and human understanding. On the forward path, it translates human intent into executable IR. On the reverse path, it observes system behavior and generates a semantic model expressed in whatever form is most useful to the stakeholder.
This is not decompilation. Decompilation attempts to recover source code, which is itself a compromise artifact. The Semantic Bridge recovers meaning. For a security auditor, it produces trust boundaries and data flow invariants. For a product manager, decision trees and business logic descriptions. For a system architect, topology maps and interaction patterns.
Documentation staleness vanishes because the semantic model is derived from the running system, not maintained as a separate artifact. Legacy code opacity is addressed because the Semantic Bridge can examine any system's actual behavior and reconstruct a model of what it does. The abstraction mismatch between human organizational needs and machine execution needs disappears because each side operates in its native domain.
The most consequential implication is a new model of software verification. Current practices are fundamentally enumerative: unit tests check specific pairs, integration tests check interactions, code review checks whether a human believes implementation matches intent. None of these answer the actual question: does this system do what was meant?
The Semantic Compiler enables a closed-loop verification system that operates at the level of meaning:
This approach is closer to formal verification than to testing, but expressed in a medium humans can participate in. The AI can reason about the full behavioral envelope of a system rather than sampling individual cases. The result is verification by alignment rather than verification by enumeration.
The system comprises four principal components:
The first generation must be built with conventional tools. Each subsequent generation expands the scope of its own paradigm:
doesNotUnderstand system that detects missing functions and auto-generates them (see Section 7.6). The HTTP server uses a data-driven routing framework where every handler is a pure function with a standard signature—no syscalls, no global state—making handlers both kernel-compilable and WASM-portable. Route misses return -1, extending the doesNotUnderstand pattern to HTTP: unknown routes can trigger handler generation (see Section 7.7). Deployment is automated via CI/CD. This page is served by a 75KB binary the kernel generated from English intent.The system described in Sections 1–6 has been built. This section reports what was observed.
The Python-based pipeline was tested across five domains: scalar arithmetic, string manipulation, array operations, behavioral repair, and program generation. Over 24 pipeline runs, 373 test cases were executed with a 95.7% pass rate.
The behavioral repair loop proved effective: when generated IR produces incorrect results, the Semantic Bridge diagnoses the specific faulty instructions, the Meaning Compiler produces a corrected version, and execution is retried. This loop runs up to three iterations and resolved the majority of first-attempt failures. A separate inner loop handles parse errors in generated IR, retrying up to five times before escalating to behavioral repair.
Pattern distillation was implemented as a learning mechanism. Each successful pipeline run is captured as a reusable pattern—the intent signature, the IR structure that satisfied it, and the behavioral model that confirmed alignment. These patterns are retrieved by signature similarity, keyword overlap, and complexity proximity, then provided as few-shot examples to subsequent compilation runs. The pattern library grew organically and measurably improved first-attempt success rates.
Generation One is a 211KB native binary comprising approximately 12,000 lines of LLVM IR across 35+ modules. It runs on ARM64 macOS without external runtime dependencies.
The kernel implements a full HTTP client in LLVM IR: TLS via BearSSL for encrypted communication with the Claude API, DNS resolution for hostname lookup, and HTTP/1.1 request construction and response parsing. A JSON parser and emitter, also in LLVM IR, handle API request formatting and response extraction.
The compilation loop operates as follows: the kernel constructs a prompt containing the task description, a focused manifest of relevant module functions (selected by scanning the task and source for cross-module references), and the source of any file being modified. It sends this to Claude, receives generated IR, and runs five deterministic fixup passes before validation: byte-count correction for string constants, declaration signature normalization against the manifest, raw syscall-to-wrapper rewriting, duplicate definition stripping (for newly created modules), and missing function detection. Only then does it compile with llc. If compilation fails, it captures the compiler's stderr along with the original task description, constructs a repair prompt, and retries up to five times across two retry passes. Once the IR compiles cleanly, the kernel writes it back to its own source tree and rebuilds all binaries.
The kernel modifies its own source code. This is not a metaphor. It reads its own .ll files, sends them as context to the API, receives modifications, validates them, and overwrites the originals. The rebuilt binary incorporates the changes on the next invocation.
Three directive types enable structured intent compilation:
@plan — An English description is sent to Claude, which produces a sequence of build steps delimited by ---. The kernel then executes each step in order, creating modules, writing code, and rebuilding. A single English paragraph becomes a multi-file, multi-step build.@test — Semantic verification. The kernel generates a test harness via a second API call, compiles and links it, and executes the result. A non-zero exit code triggers a behavioral repair loop: the failing output is fed back to produce corrected IR, up to three iterations.@transform — Reads external codebases and ports them to native LLVM IR. In a stress test, the kernel ported 43 functions from five Python modules (sorting, searching, bitwise operations, numeric algorithms, and hashing) to LLVM IR, validating each with llc.The pattern library accumulated 18 learned patterns over the course of development, each encoding a successful mapping from intent to validated IR. These patterns serve as few-shot examples, providing the compiler with proven structural templates for similar future tasks.
The kernel has produced several standalone programs from English descriptions:
@transformThe kernel ported its own infrastructure tools from Python to native LLVM IR. The manifest generator, which catalogs all modules and their exported functions, and a byte-count corrector used during IR generation were both reimplemented by the kernel itself through the @transform directive. No external dependencies remain. The kernel is fully self-contained.
The most unexpected discovery came from a failure mode. When Claude generates code that calls a function which doesn’t exist in the codebase—neither in the manifest nor as a known system shim—the system previously had no recourse. The declare statement would pass through, llc would accept the unresolved reference, and the linker would fail with no diagnostic and no recovery path.
The fix turned out to be a reinvention. When declare_fix.ll encounters an unresolvable function reference, it records the name and the full declare signature. The kernel reads this list, constructs a @create task to auto-generate the missing functions, and injects it into the retry buffer ahead of the original step. On retry, the missing module is generated first, its functions enter the manifest, and the original step succeeds.
This is Smalltalk’s doesNotUnderstand: protocol—but operating at the compiler level rather than the runtime level. In Smalltalk, when an object receives a message it has no method for, the runtime sends doesNotUnderstand: to the receiver, which can then decide how to handle the situation: raise an error, delegate to another object, or dynamically create the missing method. The semantic compiler does the same thing one layer down. When generated code references a function the codebase doesn’t provide, the system detects the gap and fills it—by asking Claude to implement what’s missing.
The parallel is exact in structure. Smalltalk’s message-not-understood is a runtime reflection mechanism: the system discovers at execution time that a capability is missing and responds dynamically. The semantic compiler’s version is a compile-time reflection mechanism: it discovers during compilation that a capability is missing and generates it before execution begins. Both represent the same fundamental pattern—a system that can detect its own incompleteness and act on it.
This was not designed from theory. It emerged from engineering necessity. The fact that it converged on a pattern identified by Alan Kay’s group in the 1970s suggests something deeper: that self-aware systems, whether object-oriented runtimes or AI-driven compilers, inevitably arrive at the same architectural solution for handling the unknown.
The HTTP server was originally a hardcoded branch chain: each route was an icmp + br sequence comparing the request path against string constants. Adding a new page required modifying the server binary, recompiling, and redeploying. Phase 15 replaced this with a data-driven routing framework built from three new LLVM IR modules.
A vec-backed route table maps path + method pairs to handler function pointers. A handler dispatch layer provides a standard calling convention: every handler receives a request context struct, a response buffer, and the buffer size, and returns the number of bytes written. A fragment builder provides entity-escaped HTML generation for dynamic content. All three modules are pure buffer operations with no syscalls—they are WASM-safe by construction.
The key design decision is the handler signature: i64 @handler(ptr %ctx, ptr %buf, i64 %size). No I/O, no global state, no side effects. This purity is what makes handlers both kernel-compilable and WASM-portable—the same function can run server-side in the LLVM IR binary or client-side compiled to wasm32-unknown-unknown.
When handler_dispatch finds no matching route, it returns -1. This is the doesNotUnderstand hook from Section 7.6, applied to HTTP routes. The current server sends a 404. The future path: route miss triggers @create route_handler_<path>.ll, the kernel generates a handler from the request context, compiles it, registers it in the route table, and dispatches. Routes that don’t exist yet get created on demand from the intent implicit in the URL structure.
Programming languages become optional. Like assembly today, they remain available for specialists but cease to be the primary medium. The primary interface becomes natural language intent. The kernel's ability to produce working binaries from English descriptions is a partial demonstration of this shift.
Democratization. When the barrier shifts from “can you write code” to “can you express intent clearly,” domain experts—clinicians, educators, scientists—can build and verify their own tools.
Continuous legibility. The Semantic Bridge makes running systems continuously understandable, expressing actual behavior in human terms at all times.
Compounding feedback. Every correction teaches the system more about the mapping between a user's intent language and desired behavior. The system improves with every interaction.
Self-completing systems. The doesNotUnderstand mechanism points toward systems that can identify their own missing capabilities and generate them. This is a qualitative shift from tools that execute instructions to tools that recognize what they lack and fill the gaps. The classic Smalltalk insight—that a system should be able to reflect on its own incompleteness—applies with equal force at the compiler level.
Programming languages are a human interface technology. With AI capable of fluent translation between natural language and formal execution targets, the need for this intermediary dissolves. What remains is LLVM IR as the true machine interface and a Semantic Bridge as the true human interface, with AI serving as the bidirectional translator.
The path to actualization began with conventional development, producing a tool that progressively replaced its own foundations with the paradigm it implements. The Semantic Compiler can iterate on itself. It builds new modules through intent specification, IR compilation, and semantic verification rather than human-written code. The thesis is validated not by argument but by existence.
The kernel exists. It improves itself. It built the server you are reading this on. The thesis is no longer theoretical.
The era of programming languages as the primary interface between human intent and machine execution is a transitional phase. What comes next is a direct conversation between meaning and computation, with no code required.
These pages do not exist yet. Each link triggers the server’s doesNotUnderstand pattern.
Intent Algebra · Meaning-Preserving Transforms · doesNotUnderstand Cascade