AI Compilers: do we still review the code agents write?

Here's a question I can't stop thinking about: if an AI coding agent can generate working software from a plain-English description, do we still need to version-control the code it writes? Do we even need the code?

Follow that thread far enough and you arrive somewhere strange. Maybe git and GitHub — the twin pillars of modern software collaboration — become optional. Maybe the AI agent just generates the binary, and the "source code" as we know it stops being the artifact we care about.

I don't think this is a settled question. I think it's one of the most interesting open questions of the AI coding era. Let me walk through why.

We've been climbing the abstraction ladder for seventy years

The history of programming is a history of moving the abstraction layer higher.

We started with machine code — raw ones and zeros fed to the processor. Assembly language arrived as a thin human-readable layer over it, and some programmers at the time considered even that a crutch. Then came FORTRAN and COBOL in the 1950s, and the skeptics said the same thing: a compiler could never produce machine code as good as a hand-tuned assembly programmer. For a while, they were right. Then compilers got better, hardware got faster, and the argument evaporated.

C gave us portable systems programming. C++ and Java gave us objects and memory management. Python, Ruby, and JavaScript traded raw performance for developer speed, and we accepted the trade gladly. Swift and Kotlin gave us safety and expressiveness. At every step, we gave up direct control over a lower layer and trusted a tool to handle it — and at every step, productivity won.

Notice what happened each time: we stopped reading the layer below. Almost nobody reviews the assembly their Swift compiler emits. We trust the compiler, and we verify the behavior.

Natural language prompts to an AI coding agent look a lot like the next rung on that ladder. The prompt is the new source code. The agent is the new compiler. Which raises a provocative question about the middle layers.

Do we still need Python and Swift in the loop?

Today's agents write Python, TypeScript, or Swift — languages designed to be readable by humans. But if humans increasingly aren't the ones reading the code, why route through a human-oriented language at all?

You could imagine instructing an agent to emit assembly, or LLVM IR, or the binary directly. The high-level language exists to bridge human intent and machine execution — and if the agent is the bridge now, the language in the middle starts to look like an implementation detail. A serialization format. Something the agent uses if convenient and skips if not.

There are real counterarguments. High-level languages aren't just for reading — they encode decades of hard-won guardrails: type systems, memory safety, borrow checkers. They're also how today's agents were trained, and they give us a debuggable checkpoint when things go wrong. Skipping them means trusting the agent with everything those layers used to catch.

"We need this layer because we've always had it" is exactly what the assembly programmers said about FORTRAN.

If we don't review code, what do we review?

This is where I think the ground is genuinely shifting. The pull request review is built on an assumption: that a human reading the diff is a meaningful quality gate. When an agent generates ten thousand lines in an afternoon — or generates no human-readable lines at all — that assumption breaks.

What replaces it? Verification of behavior rather than inspection of text:

• Integration tests that pin down what the system must actually do, end to end
• Evals that measure the agent's output against the outcomes we care about, the way we already evaluate the models themselves
• Contracts and specs that become the durable, versioned artifact — the thing we humans write, argue over, and refine

In this world, the engineering craft moves from writing implementations to specifying intent and building the harnesses that verify it. We stop reviewing the "how" and get rigorous about the "what." Honestly, that's where the leverage always was.

And what do we version-control? Perhaps not the generated code, but the prompts, the specs, and the eval suites — the true sources from which everything else is derived. You don't check compiler output into git today. Maybe tomorrow's equivalent is not checking in the agent's output either.

Maybe we should call them AI compilers

"Coding agent" frames these systems as junior developers we supervise line by line. But the trajectory looks more like a compiler: a trusted transformation from a higher-level description to an executable artifact, verified by tests rather than read by humans.

We don't review compiler output. We don't version-control compiler output. We test the result and trust the toolchain. If AI agents earn that same trust — and that's a big if, one that hinges on reliability we haven't fully achieved yet — then "AI compiler" might be the more honest name.

I want to be clear: this is an open question, not a prediction. Determinism, security, auditability, and regulatory requirements may keep human-readable source and code review with us for a long time, especially in critical systems. The transition, if it comes, will be uneven.

But every previous generation of programmers watched an abstraction layer they mastered become something the toolchain handled. It would be surprising if our generation were the exception.

So I'll leave it as a question: in five years, what will your team actually be reviewing — the code, or the evals?

---

Frequently asked questions