Claude Is Not a Compiler: The Rise of Vibe-Engineering

LLMs as Vertical Resources, Not Code Translators

Large Language Models (LLMs) like Claude are not compilers; they are vertically integrated resources capable of operating across the entire software stack. While a traditional compiler translates source code to binary—a single, deterministic layer of specification—LLMs can navigate between high-level strategy, product requirements, system architecture, and low-level implementation details simultaneously.

This capability allows a developer to move beyond "vibe-coding" (simply generating chunks of code) toward "vibe-engineering," where the LLM is used to accelerate the decision-making process across all layers of a system's design.

The Failure of Rigid Layering in Software Development

Software is traditionally built in layers: vision becomes strategy, strategy becomes architecture, and architecture becomes code. In a strict model, each layer is handled by a different role (e.g., Executive $\rightarrow$ PM $\rightarrow$ Architect $\rightarrow$ Engineer $\rightarrow$ Compiler). However, this rigid separation often leads to failures because information is hidden and communication overhead increases.

Effective construction—exemplified by the building of the Empire State Building—succeeds when stakeholders from all layers (architects, builders, and subcontractors) collaborate synchronously. LLMs mimic this vertical integration by providing a single interface that can discuss the strategic "why" and the machine-code "how" without the organizational friction of scheduling meetings or seeking permissions.

Case Study: Building a Distributed DNS Server

To illustrate the power of vertical integration, Mikaelian describes the development of a geographically distributed, consistent DNS server for exe.dev to solve latency and propagation issues. The process moved through several phases:

1. Research and Design

LLMs were used to research standard distributed DNS designs, identify historical security failings, and explore alternative implementation strategies (such as AXFR/IXFR), while gaming out potential failure modes.

2. Iterative Prototyping and Differential Analysis

Multiple concurrent agent loops were prompted to build the entire system, including tests and adversarial code reviews. By comparing the implementations of different agents, the developer identified critical decisions the agents made implicitly.

For example, when handling database rollbacks in an append-only replication strategy, different agents solved the problem in wildly different ways. The final solution—using a "timeline" field to detect history alterations and trigger a full re-sync—was reached by analyzing these divergences.

3. Codifying the "Scar-Tissue" Document

Through repeated cycles of differential spec analysis, the developer created a "scar-tissue" document. This artifact encapsulates the central, intentional aspects of the design across all layers—from high-level goals to the specific data types for concurrent caches—ensuring the design survives future code churn.

The Shift Toward Vibe-Engineering

Vibe-engineering is the process of using LLMs to augment the human's ability to make critical decisions at every level of the stack. In this workflow, the human does not hand off the task entirely to the AI; instead, they use the AI to explore the decision space and refine the specification.

This approach changes the definition of "understanding" code. The developer may not have read every line of the generated implementation, but they can reason about the system's architecture, share perspectives with colleagues, and guide future agents based on the codified design decisions.

Community Perspectives and Counterpoints

Discussion among technical peers highlights several risks and philosophical disagreements regarding this approach:

• The Risk of Implicit Decisions: Some argue that outsourcing decisions to an LLM—even if they are later reviewed—can lead to "implicit outsourcing" where critical architectural flaws are missed because the developer didn't know what to ask.
• The Determinism Gap: Critics point out that compilers are deterministic, whereas LLMs are probabilistic. A compiler will not randomly change a button's text from "Finish" to "Done" between builds, whereas an LLM might.
• The Necessity of Code Review: There is significant pushback against the idea of deploying code to production without reading it. Critics argue that "not reading the code" is a dangerous practice that ignores the reality of production stability.
• The Feedback Loop: Some suggest that the true value of LLMs is not in replacing the "compiler" step, but in accelerating the feedback loops between specification and implementation, allowing for faster iteration and distillation of a product.

"The idea that a 835-page spec 'just exists' and we run an LLM to implement it is completely flawed. Specs do not appear out of nowhere, they co-evolve with the code."

Conclusion

Software engineering is shifting. While some layers of abstraction that provide mere convenience are dying, layers that enable the expression of important decisions will remain. The future of engineering may not be about writing code, but about managing the decision-making process across the entire vertical stack, using LLMs as the primary tool for exploration and implementation.