AI as a Compiler, Not a Programmer

Over the past few months, I've been thinking about a different way to use AI coding agents.

Today, the common workflow looks something like this: "Build me a REST API." The AI decides the architecture, creates classes, chooses libraries, invents helper functions, and generates hundreds of lines of code. We then review and edit what it produced.

While this is productive, it also means the AI owns many of the design decisions.

What if we flipped the workflow?

Instead of asking the AI to design software, we write the software ourselves — but in a human-readable specification.

For example:

FILE auth.spec

CLASS AuthService

FUNCTION login(username, password) -> Token

PROCESS
1. Find user.
2. If missing, return InvalidCredentials.
3. Verify password.
4. Generate JWT.
5. Return token.

The AI's only job is to compile this into Python, TypeScript, Rust, or any other language. The specification becomes the source of truth. The generated code becomes an implementation.

Why?

I think this changes the relationship between developers and AI. Instead of:

• AI owns the architecture.
• Human reviews the code.

We get:

• Human owns the architecture.
• AI owns syntax, boilerplate, imports, formatting, and repetitive implementation.

What Already Exists?

A paradigm called as spec-driven development already exists but actually it's more like this way :
Most SDD tooling right now (Spec Kit, Agent OS, etc.) still has the AI write the spec collaboratively from a rough prompt, then implement it.

If the AI writes the spec, the AI is still making the design decisions, just one layer removed. So the main problem with AI owning the design decisions still remains.

What I'm talking about is having the human write the pseudocode per file by hand then treat AI as a tool that converts that pseudocode into actual code.

What Happens When the Human's Spec is Wrong or Incomplete?

This is another problem. But it has a simpler solution also, have the AI make suggestions where the pseudocode seems ambigious or incorrect, the AI stops the execution and suggests corrections/details and human improves the pseudocode as per their competence.

Yes, this reintroduces AI judgment, but scoped to flagging gaps rather than filling them silently — the human still decides, the AI just points.

Maintainence and Evolving Codebase

Another thing to think about is, the spec and code must change in resonance not in isolation during maintainence i.e. as the codebase evolves so does the spec.

A possible solution is a CI workflow that fails if code and spec do not match. But how exactly that should work is an open problem too. Using an LLM as a judge for this stage seems expensive and non-deterministic and making the spec file too specified turns it into a programming language basically.

Possible Rules

The agent should follow strict rules:

• Never invent APIs.
• Never rename functions or classes.
• Never change architecture.
• Never add features that aren't in the spec.
• If something is ambiguous, ask instead of guessing.

Benefits

This approach could make AI-generated code more predictable.

• The human keeps ownership of design.
• Specifications become documentation.
• Code reviews compare implementation against the spec.
• The same specification could generate implementations in multiple languages.
• Regeneration becomes possible without losing intent.

Open Questions

This is only an idea, not a finished methodology. Questions I'm still exploring:

• What should a good .spec format look like?
• How much detail should live in the specification?
• Can agents generate deterministic implementations from it? Although LLMs are not deterministic but can we achieve a certain level of determinism via a hard harness over the agent and unambigious instructions.
• Can repositories eventually be built around specifications instead of source code?

If you've tried this and it broke down, I want to know where