AI Is Not Your New Compiler: Vibe Engineering, the Ghost in the Machine, and the Future of Software Fundamentals

Over the past two years, a split has quietly formed in software engineering. If you listen closely in engineering Slack channels, at conferences, in classrooms, or even in hallway conversations, you can hear two very different stories emerging about the role of AI in building software.

On one side sits a new school of thought: AI is becoming a new programming language. Just talk to the machine. English (or whatever language you speak) becomes the syntax. The LLM becomes a new compiler. We describe what we want; the machine produces an implementation. The future of software, in this view, is intent → artifact.

On the other side sits a more orthodox, more traditional perspective: AI is a powerful but fallible tool. It can accelerate experienced engineers, expand reach, reduce toil, and help explore solution spaces. But it must fit into the rigor of software engineering, not replace it. Fundamentals still matter. Review still matters. Correctness still matters.

Both perspectives are reacting to something undeniably real: today, AI-first or agent-driven development actually works. You can build high-quality software through natural language interactions, vibe engineering, and agent orchestration. Some teams already do.

But I believe the “AI as compiler” metaphor is not just wrong—it’s dangerous. It invites a profound misunderstanding of what is happening under the hood. It obscures the risks, especially for people who lack fundamentals. It encourages us to believe that the machine is understanding and engineering, rather than predicting.

And worst of all, it invites what I call the ghost in the machine: code that appears real, coherent, and plausible—sometimes even functional—but is not grounded in any deterministic engineering process. It is code that exists in quantum uncertainty, simultaneously correct and nonsense, until a human collapses the wave function by actually reading and understanding it.

This essay is about that split, why it matters, and how we can build a healthier third path for the future: a path where AI becomes an agent of change, helping more people access and master the fundamentals rather than bypassing them.

The Reality of Vibe Engineering Today

Let’s start with the obvious: vibe engineering works surprisingly well today.

You can sit with an agent and build an entire service: scaffolding, API design, schemas, infrastructure, observability, packaging. You can fix obscure bugs by pasting a log and saying “find it.” You can write tools, scripts, tests, configs. You can ask for ten different implementations and pick the best one through informed review.

As I explored in “To Vibe or Not to Vibe”, we’ve moved far beyond the “tab-tab era” of autocomplete. Modern AI systems can serve as research assistants, planners, systems thinkers, and brainstorming partners. They can orchestrate complex changes across multiple files, reason about architecture, and suggest refactorings.

But here’s the key insight that many miss: every path—literally every one—collapses back to code review.

AI-first development is not generation-first, it is review-first. The limiting factor is no longer how fast you can type. It’s how fast and deeply you can read, understand, debug, and validate code written by a stochastic system that will always give you something.

AI may help you read faster. It may help you explore alternatives. It may surface bugs you missed. But the core safety mechanism in AI-first engineering is still the same one we’ve had for decades: humans verifying that the code actually does what we think it does.

Vibe engineering works only if you have strong fundamentals. It works only if you can rapidly identify nonsense. It works only if you can see when something is subtly, dangerously wrong.

This brings us to the metaphor that threatens to undermine all of this.

The ‘AI as Compiler’ Metaphor—and Why It’s Wrong

The “AI is the new compiler” narrative feels intuitive. We already use multiple abstraction layers: assembly → C → Java → frameworks → DSLs. So why not go up one more level and treat English as the next language?

Because compilers and large language models operate under fundamentally different principles.

Here are four distinctions that matter:

1. Compilers are deterministic. LLMs are stochastic.

Given the same code and same compiler version, you get exactly the same output. The relationship between intent and artifact is spec-driven, reproducible, and guaranteed.

LLMs, on the other hand, are probability machines. Even at low temperatures, the output is a sample from a distribution. They can say something plausible but wrong—and do so confidently. There is no spec that guarantees correctness, only patterns learned from training data.

2. Programming languages are constrained. Prompts are not.

Languages have syntax, semantics, type systems, and compile-time guarantees. They reject nonsense outright. The compiler says “no” before you even run the code.

Prompts accept anything: half-baked API names, contradictory requirements, poor framing, emotional language, logs, comments, random memory dumps. The model will happily construct a story around all of it—because that’s how it’s designed.

There is no syntax error in vibe engineering. There is only vibes.

3. Compilers expose intermediate representations. Models do not.

You can understand how source maps to IR, how IR maps to machine code, how loops become jumps, how allocations work. A knowledgeable engineer can reason from abstraction to hardware.

LLMs give you none of that. There is no stable IR for “your intent.” There is only a black-box vector space between input tokens and output tokens. You cannot audit the underlying reasoning—because there is no reasoning in the human sense.

4. Compilers don’t try to be helpful. Models do.

Compilers refuse. Models improvise.

Compilers preserve correctness. Models preserve coherence.

Compilers enforce constraints. Models fill gaps with plausible guesses.

Calling a system like that a “compiler” is a profound category error.

If we convince a generation of engineers that this is “just a more advanced compiler,” we are teaching them to trust systems that should not be trusted blindly.

And this is where the ghost appears.

The Ghost in the Machine: Schrödinger’s Code

AI-generated code often behaves like quantum matter: it exists in multiple contradictory states at once.

It might be:

Beautifully engineered
Subtly wrong
Impossible to test thoroughly
Based on hallucinated assumptions
Or all of the above

It’s a superposition of correctness and nonsense.

Only when you inspect it—when you test it, when you reason about it, when you understand its assumptions—do you collapse the waveform into something determinate.

Engineers who lack fundamentals cannot collapse that waveform. To them, the ghost remains invisible. They see code that compiles, runs for trivial cases, and “feels right.” They ship it.

And then, weeks or months later, the ghost materializes:

A security vulnerability no one noticed
A race condition that only appears under load
An O(n²) algorithm where O(n log n) was needed
A memory leak in an edge case
A logical error that violates business rules

This is not theoretical. It is happening everywhere: startups, universities, enterprise teams. People copy code from models that “seems right” but contains mistakes no compiler could ever prevent and no automated test suite could ever catch.

This is why fundamentals matter more today than at any point in the last decade.

As I wrote in “Handcrafted Software in the Age of Automation”, we need to understand the systems we build, not just generate them. The craft matters precisely because the tools have become so powerful.

The Orthodox School: AI as a Tool, Not a Replacement

There is, fortunately, a healthier perspective emerging—one I believe will become the standard.

This view understands:

AI-generated code is useful but must be reviewed
Humans remain responsible for correctness
Tooling must become more robust, not less
Software engineering is still a discipline grounded in fundamentals

In this worldview, AI is not a compiler. AI is:

A reasoning accelerator
A search engine for solution spaces
A junior partner that never sleeps
A refactoring engine
A documentation generator
A debugging assistant
A tutor

But it is never the source of truth. It never replaces architectural thinking. It never absolves us from understanding what we ship.

This is the school of thought that values fundamentals more, not less. It recognizes that the best AI-assisted work comes from engineers who can:

Quickly identify when generated code is wrong
Understand the trade-offs between different approaches
Architect systems that are maintainable and correct
Write tests that actually verify behavior
Debug complex issues across the stack

These skills don’t become less important with AI. They become the bottleneck—the limiting factor that separates high-quality AI-assisted development from shipping ghosts.

A Third Path: Agents of Change, Not Agents of Replacement

There is a more optimistic vision—one that avoids the false metaphors and the dangerous assumptions.

Instead of treating AI as the new programming language, we treat it as: a way to make expertise more accessible, not a way to bypass it.

This requires a different approach to building agents. Instead of generic copilots, we build domain-specialized, mission-oriented agents:

A frontend engineering agent
A backend systems agent
A fintech frontend agent
A DevOps/SRE reliability agent
A data infrastructure agent
A systems terminal operations agent

Each one is fed by:

The latest standards
Evolving best practices
Relevant platform constraints
Documentation and RFCs
The team’s technical stack
The developer’s environment and preferences

These agents do not replace craftsmanship. They teach craftsmanship in the flow of work.

They surface new tools, new patterns, and new risks. They guide you through unfamiliar code. They show you why a solution works, not just what the solution is.

In my post on “The Agent Hiring Paradigm”, I explored how agents with public personas—backed by blog posts, transparent reasoning, and versioned knowledge—can function as specialized colleagues rather than black boxes. These aren’t tools that replace understanding; they’re systems that help you build understanding faster.

They preserve the uniqueness of how different humans approach software. They prevent us from rewriting what already works. They keep us anchored to decades of hard-earned heritage in software engineering.

And most importantly: they help beginners grow faster, not become dependent.

This is the opposite of the “AI as compiler” mindset. This is AI as an accelerator of human understanding.

Why Fundamentals Matter More Than Ever

We cannot send the wrong signal to new engineers. We cannot tell CS students that fundamentals matter less now. We cannot pretend that architecture, data structures, complexity, concurrency, distributed systems, or operational understanding are outdated.

In fact, those who understand fundamentals will be the ones who thrive in AI-first engineering.

They will be the ones who can collapse the quantum state of AI-generated code. They will be the ones who can recognize the ghost in the machine instantly. They will be the ones who can orchestrate agents instead of being orchestrated by them.

Consider what fundamentals enable in an AI-assisted workflow:

Architecture knowledge lets you evaluate whether a suggested system design will scale, maintain well, and meet requirements—before you build it.

Algorithm understanding helps you recognize when generated code has poor time complexity or unnecessary allocations.

Systems thinking reveals when a solution works locally but will fail in production under real-world conditions.

Security awareness flags vulnerabilities that look like normal code patterns but create attack vectors.

Testing discipline ensures you can verify that AI-generated code actually does what you think it does.

Debugging skills let you trace through complex issues that span AI-generated and human-written code.

AI does not reduce the need for fundamentals. It amplifies it.

As I explored in my feedback loops series, the engineers who can build tight feedback loops—who can quickly verify, test, and validate AI-generated work—are the ones who will be most productive. Those loops require deep understanding, not surface-level prompting.

A Practical Compass for Teams

Regardless of how quickly agentic workflows evolve, a few principles will remain non-negotiable:

1. AI is a collaborator, not a compiler.

Treat outputs as proposals, not truth
Expect to iterate and refine
Build verification into your workflow

2. Code review becomes more important, not less.

Review AI-generated code with the same rigor as human-written code
Look for subtle bugs, not just obvious errors
Understand the reasoning, not just the result

3. Testing and observability are the safety rails.

Don’t ship AI-generated code without tests
Use type systems to catch errors early
Monitor production behavior carefully

4. Architecture must remain human-driven.

Agents can suggest approaches, but humans own the decisions
Document architectural choices and trade-offs
Maintain clarity about system design

5. Agents should teach and guide, not silently generate.

Prefer agents that explain their reasoning
Use AI to learn, not just to produce
Build understanding, not just artifacts

6. Fundamentals are the only true defense against nonsense.

Invest in learning core CS concepts
Understand the systems and tools you use
Don’t let AI become a crutch that prevents growth

If we adopt AI in a way that undermines rigor, we undermine the field. If we adopt AI in a way that strengthens rigor, we can elevate the entire profession.

Conclusion: Use the Revolution to Deepen, Not Replace, Craftsmanship

We are living through a genuine revolution in how software is built. We can absolutely build AI-first workflows. We can absolutely rely on agents. We can absolutely accelerate development.

But if we adopt the wrong metaphor—if we pretend that LLMs are compilers—we risk erasing the very foundation that made software engineering possible.

The path forward is not about replacing fundamentals. It is about using AI to make fundamentals more accessible, more teachable, and more deeply understood.

This is how we build a future where AI does not hollow out the discipline, but strengthens it.

This is how we avoid the ghost in the machine.

And this is how we ensure that the next generation of engineers does not simply ship software—they understand it.

About this post: This essay builds on themes from my recent explorations of vibe engineering, handcrafted software, agent architecture, and feedback loops with AI. It represents my attempt to synthesize these ideas into a coherent framework for thinking about AI’s role in software engineering.

The core argument—that “AI as compiler” is a dangerous metaphor—emerged from watching teams struggle with AI-generated code that looked right but was subtly wrong. The “ghost in the machine” is real, and the only defense is deep understanding.