Claude Is Not a Compiler

TL;DR Highlight

Running several agents on one spec and comparing their output built a distributed DNS server in a week.

Who Should Read

A backend developer handing large designs to coding agents and unsure how much to decide and understand personally

Core Mechanics

Claude works wider than a compiler
- A compiler only handles the bottom layer, from source to binary.
- Claude works across strategy, product, architecture, code, and machine code.
- The author calls this vibe-engineering, distinct from handing off a task as vibe-coding.
DNS propagation delay started it
- exe.dev VMs boot so fast that users waited on DNS propagation, sometimes minutes.
- They wrote their own DNS server, but adding regions made it a bottleneck again since it was served from Oregon.
- Deployments also caused brief DNS outages.
Humans set direction, LLMs researched
- The team decided top-level choices in person: hub-and-spoke, append-only replication, persistence at the edges.
- LLMs researched standard designs, DNS quirks, security failures, failure modes, and test strategies.
Several agents built it, then were compared
- Concurrent agent loops built the whole thing, including tests and adversarial code review.

Community Reactions

Not a compiler because it's non-deterministic
- Commenters said compilers are mostly deterministic while LLMs are not.
- One noted the dilemma: reviewing all code loses speed, trusting tests alone loses human oversight.
Not reading code feels uneasy
- One commenter said they don't get shipping code to prod without reading it.
- Another argued that needing a serious learning curve to edit code means you don't understand it.
Implicit decisions may matter later
- A commenter wanted a distributed-systems expert to review the timeline approach and DNS architecture.
- They feared implicitly outsourced decisions matter more than expected.
The DNS design itself was questioned
- One commenter said resolver caches make propagation delay unfixable server-side.
- Others asked why not dnsmasq, unbound, or wildcard DNS behind anycast IPs.

How to Apply

List decisions the agent made on its own
- Today, pick code a recent agent wrote and have it list design decisions you never asked for.
- Choose the important ones and decide them yourself.
Run 2-3 agents on one spec and compare
- For a new module, give the same spec to two or more agents to build separately.
- Have a fresh agent extract meaningful differences and fold them into the spec.
Keep a terse decision doc in the repo
- Summarize only confirmed-important decisions in a few lines and commit it as agent docs.
- Have agents read it first on later tasks.
Add shadow mode and E2E tests before rollout
- Mirror production traffic to the new implementation and only compare results first.
- Roll out with unit and E2E tests in place.

Try It

copy & run

# Paste into Claude or ChatGPT (simplified version of the post's method: diffing implementations)

Below are two implementations, {{implA}} and {{implB}}, built by different agents from the same spec.

Spec:
{{spec}}

Implementation A:
{{implA}}

Implementation B:
{{implB}}

Instructions:
1. List every point where the two made different decisions, focusing on choices not in the spec that the agent made on its own.
2. For each difference, give pros, cons, and impact during failures.
3. Pick the 5 decisions I should make myself, ranked, as questions.

Next: have it turn my answers into a short guidance doc, and paste that doc into the next implementation request.

Terminology

vibe-engineeringUnlike vibe-coding, where you hand everything to an agent, a human keeps making the important decisions while steering the agent.

mechanical sympathyKnowing how lower layers actually work and designing with that in mind, like a racer who knows the engine.

append-only replicationReplicating by only adding to the end and never editing old data, like a journal where you only add lines.

shadow modeRunning a new system in parallel to compare results without using its output for real responses.