logo
Kurashizu Blogwhere ideas flow
  • Home
  • News
  • Blog
  • About
  • Home
  • News
  • Blog
  • About

© 2026 Kurashizu. All rights reserved.

Admin·New Post·Service Status
Powered by Cloudflare·01.11.26
← Back to news

Claude Is Not a Compiler

Original article
blog.exe.dev|120 points|127 comments|by bryanmikaelian|Jul 21, 2026

Claude Is Not a Compiler

Originally posted on the exe.dev blog by Josh Bleecher Snyder (2026-07-20)

Back in early 2025, I posed a question: Is Claude a compiler?

Looking back, I realize that was a category error. The reality is far more interesting: Claude is actually better than a compiler. To understand why, we need to dismantle how we think about software production.

The Traditional Layered Model

Conventionally, we view software development as a series of descending layers. Each layer increases specificity while abstracting away "irrelevant" details.

Vision→Strategy→Product Plans→Coding Plans→Binaries\text{Vision} \rightarrow \text{Strategy} \rightarrow \text{Product Plans} \rightarrow \text{Coding Plans} \rightarrow \text{Binaries}Vision→Strategy→Product Plans→Coding Plans→Binaries

This hierarchy typically maps to specific organizational roles:

LayerResponsible RolePrimary Focus
Vision/StrategyExecutive / VPDirection & Goals
Product/ArchitecturePM / ArchitectSpecification & Structure
ImplementationEngineerLogic & Source Code
Machine CodeCompilerOptimization & Execution

Note on Hiring: Because of this structure, I prioritize two specific traits when hiring engineers: judgment and comity.

The Role of the Compiler

The compiler handles the final transition from source code to binary. It makes critical low-level decisions regarding:

  • Inlining functions
  • Register allocation
  • Determining whether to emit a warning or trigger a hard failure

These choices are not trivial; they dictate the system's predictability, stability, and performance. A reliable compiler allows the software engineer to ignore these complexities entirely.

The "LLM as Compiler" Fallacy

Around 2025, the prevailing mental model was that LLMs were simply a new layer in this stack. We viewed a coding agent as a tool that "compiled" natural language into source code. In this view, the agent's value was tied strictly to its reliability and the complexity of the decisions it could automate.

However, this stylized view is incorrect.

True value is found in working across layers—a concept known as mechanical sympathy. When the people at the top understand the constraints of the bottom, the result is superior.

Lessons from the Empire State Building

The Empire State Building was completed under budget and in record time because they ignored strict layering. When dealing with the complex chrome-nickel steel cladding, they didn't just pass orders down the chain. Instead, they held an all-inclusive summit:

"...an all-inclusive meeting was called which was attended by representatives of the owner, the architects and builders, the subcontractors rolling the material, the metal workers who were to fabricate and those who were to erect it, and the inspectors who were to test all sheets..."

Imagine the efficiency gained when the actual metal workers could influence the design to ensure it wasn't "slow and miserable" to build.

Why Claude Transcends the Compiler

We often fail because we don't know the right questions to ask, or because organizational overhead (the "silo" effect) prevents the right information from flowing upward.

Claude is superior to a compiler because it operates vertically.

Unlike a compiler, which only sees the bottom layer, LLMs can simultaneously discuss:

  1. High-level strategy
  2. Product requirements
  3. System architecture
  4. Source code
  5. Machine-level execution

While a human expert might still outperform an LLM at any single one of these tasks, the LLM can perform all of them instantly, without needing a calendar invite or managerial approval.

AI Vertical Integration

Case Study: Vibe-Engineering a Distributed DNS

We encountered a bottleneck: our VMs started so quickly that DNS propagation (which can take minutes) became the slowest part of the user experience.

The Iterative Solution:

  1. Step One: We built a custom DNS server to ensure immediate updates.
  2. The New Problem: Latency. Since the server was only in Oregon, distant users suffered.
  3. The Final Goal: A geographically distributed, fully consistent DNS server.

To solve this, we used a process I call "vibe-engineering."

The Workflow

  • Strategic Alignment: We decided in person on a hub-and-spoke model with append-only replication and edge persistence.
  • LLM Research: I used LLMs to explore:
    • Standard distributed DNS designs.
    • Security vulnerabilities and "gotchas."
    • Alternative strategies (e.g., we decided AXFR/IXFR were not for us).
    • Open-source alternatives and failure mode simulations.
  • Agentic Implementation: I deployed multiple concurrent agent loops to build the system, including tests and adversarial reviews.
  • Codification: As agents asked questions about structural or line-level details, I provided answers and converted those into terse, written guidance.
  • Audit: I had new agents compare different implementations to find "silent" decisions—choices the agents made without asking.

The Technical Result

The agents settled on a replication strategy that can be summarized as:

def replicate_dns_entry(last_known_entry):
    # 1. Catch up: Fetch all entries since the last known sequence
    updates = request_entries_since(last_known_entry)
    apply_updates(updates)
    
    # 2. Maintain: Long poll for new entries in real-time
    while True:
        new_entry = long_poll_for_updates()
        apply_update(new_entry)

By working vertically—from the strategic "why" down to the long poll implementation—Claude acted not as a compiler, but as a cross-functional partner.