Beyond Code Generation: Deploying LLMs as Vertical Multi-Compilers in Systems Architecture
By utilizing LLMs as vertical "multi-compilers" spanning from high-level product strategy down to low-level concurrent cache structures, exe.dev successfully built and deployed a geographically distributed DNS engine. This approach bypassed traditional communication overhead and resolved complex distributed consistency anomalies, such as database rollback recovery, in under a week.
Transcending the Compiler Abstraction
The traditional software development lifecycle relies on distinct, segregated layers of specification. High-level strategic vision cascades into product plans, architecture designs, source code, and finally machine-executable binaries. In this stylized model, a compiler occupies the bottom rung, translating source code to binary while making closed-loop optimization decisions like register allocation and inlining.
While early integration of Large Language Models (LLMs) in 2025 focused on using them as high-level compilers to translate natural language into small blocks of code, this model fails to account for leaky abstractions. True systems engineering requires cross-layer coordination and mechanical sympathy. Modern LLMs are better understood not as traditional compilers, but as vertical multi-compilers. They possess the capability to reason and make consistent decisions across the entire stack—from product strategy and system architecture down to the underlying machine code.
Case Study: Geographically Distributed DNS at exe.dev
To support high-speed virtual machine provisioning under the `vm-name.exe.xyz` domain space, exe.dev initially developed a custom, single-region DNS server in Oregon that immediately mapped to their internal source of truth. However, as the platform scaled to support multiple regions, the centralized Oregon DNS server became a critical latency bottleneck and introduced transient outages during deployments.
The technical requirements demanded a geographically distributed, fully consistent DNS server. Rather than adopting standard AXFR/IXFR replication protocols, the team opted for a custom, lightweight topology: a hub-and-spoke model featuring an append-only replication strategy and persistence at the edge.
Instead of manually drafting the entire codebase, the engineering team used LLMs to research historical DNS vulnerabilities, explore alternative edge persistence strategies, map out adversarial failure modes, and coordinate testing strategies.
Differential Agent Analysis and the "Timeline" Rollback Guard
To implement the architecture, the team initiated multiple concurrent agent loops running Claude and Codex. This setup produced separate codebases, uncovering distinct structural approaches and implicit assumptions made by each agent model.
A primary engineering challenge emerged during replication. The replication architecture relies on edge servers catching up by requesting all records since their last known entry, then long-polling for updates. However, database rollbacks on the primary hub can violate the append-only contract, potentially leaving edge nodes out of sync.
The models resolved this rollback edge case differently. The selected design pattern associates a randomly generated "timeline" field with every database row. When an edge server requests entries starting from a specific row index, it transmits its cached timeline value for that row. If the hub detects a timeline mismatch, it indicates that a rollback or history alteration has occurred, triggering a full clean re-sync of the edge database.
Comparing the overall outputs of the models revealed distinct design profiles. Claude generated a more elegant architectural layout, while Codex proved more thorough in its edge-case coverage and implementation details.
Systems-Level Outcomes and "Scar-Tissue" Documentation
By analyzing the structural differences between the agent-generated codebases, the engineers iteratively refined their prompts. This process resulted in a "scar-tissue document"—a highly optimized, multi-layer specification that captured decisions ranging from high-level operational goals down to the exact data types required for load-bearing concurrent caches.
This specification was then used to guide a final agent run to produce the production-ready system. The completed system included unit tests, end-to-end integration tests, a shadow-mode execution path for safe production rollouts, and a terse documentation suite written by and for LLM agents.
The entire implementation required approximately one week of active human engineering attention, with minimal direct manual review of the underlying raw code. One month post-launch, the geographically distributed DNS engine operated with zero production incidents, proving that leveraging LLMs as vertical multi-compilers allows systems engineers to maintain rigorous intellectual control over system architecture without getting bogged down in line-by-line syntax generation.