The Blurring Line Between Vibe Coding and Agentic Engineering: Simon Willison's Deep Reflection

Introduction

Simon Willison—co-creator of the Django framework and a veteran software engineer with 25 years of experience—recently shared a discovery on Heavybit's High Leverage podcast that unsettled even himself: the two AI programming paradigms he once considered clearly distinct—"Vibe Coding" and "Agentic Engineering"—have begun to merge in his own daily work.

This observation strikes at the core tension in AI-assisted programming today: as AI code generation becomes increasingly reliable, how should professional engineers define the boundaries of their responsibility?

The Original Definitions of Two AI Programming Paradigms

Vibe Coding: Programming Without Reading Code

The concept of Vibe Coding was born in early 2025, first coined by OpenAI co-founder Andrej Karpathy. He described a completely new way of programming on social media: relying entirely on large language models to generate code, where developers only need to describe requirements in natural language and then accept the AI's output without performing traditional code review. The rise of this approach is closely tied to the leap in code generation model capabilities between 2024-2025—when model pass rates on code benchmarks like HumanEval jumped from 60% to over 90%, "using code without reviewing it" became viable in certain scenarios.

The core characteristics are straightforward: developers don't review code and may not even know how to program. If what's generated runs, they use it; if it doesn't, they tell the AI what's wrong and hope for the best.

Simon's stance on Vibe Coding has always been clear: it's fine for personal tools—if a bug only affects you, go for it. But building software for others this way is "extremely irresponsible," because low-quality code ultimately harms users.

Agentic Engineering: The Professional Engineer's AI Collaboration Model

In contrast, Agentic Engineering requires the developer to be a professional software engineer with deep understanding of security, maintainability, operations, and performance. In this mode, AI tools like Claude Code serve as amplifiers—amplifying your years of accumulated engineering experience.

Claude Code is a command-line AI programming agent released by Anthropic in 2025, fundamentally different from traditional code completion tools (like GitHub Copilot's inline completion mode). It uses an "agentic loop" architecture: after receiving a high-level task description, it autonomously plans execution steps, reads the file system, executes terminal commands, runs tests, fixes errors, and self-corrects across multiple iterations. The key breakthrough in this architecture lies in "tool use" capability—the model doesn't just generate code text but can invoke external tools to verify its own output. Similar tools include Cursor's Agent mode, Devin, and autonomous programming systems based on OpenAI Codex. These tools upgrade AI from "suggester" to "executor"—the technical foundation for what Simon calls the "amplifier" effect.

"The goal is to build high-quality production systems: if you're just building low-quality things faster, that's bad. I want to build higher-quality things faster."

The Unsettling Convergence: From Line-by-Line Review to Selective Trust

Here's where the problem lies: as coding agents become increasingly reliable, Simon found that he's no longer reviewing every single line of AI-written code—even for production-level projects.

He gave a specific example: asking Claude Code to build a JSON API endpoint that executes a SQL query and outputs results—it just gets it right. Add automated tests, add documentation, and you know in your gut it'll handle things well. But you genuinely haven't reviewed that code.

This gave him real guilt: if I haven't reviewed the code, is it truly responsible to put it directly into production?

Using Team Trust as an Analogy

Simon found a somewhat comforting analogy: in large organizations, when another team delivers an image resizing service, you don't read every line of code they wrote. You read the documentation, resize a few images to verify it works, then start building your own features. You only dive into their codebase when something goes wrong.

He's begun treating AI agent output the same way. But the unease remains—human teams have professional reputations and organizational accountability mechanisms as guarantees, while Claude Code does not.

Guarding Against Normalization of Deviance

Simon candidly pointed out that there's a risk of "normalization of deviance" here. This concept originated from sociologist Diane Vaughan's research on the 1986 Challenger space shuttle disaster. She found that NASA engineers observed abnormal erosion of O-ring seals across multiple launches, but because it never led to catastrophic consequences, the team gradually came to view this deviation from design specifications as an "acceptable normal state." The concept has since been widely applied to aviation safety, medical errors, and software engineering.

In software engineering, typical normalization of deviance includes: skipping code reviews but the system doesn't crash, ignoring security warnings but not getting attacked, not writing tests but functionality appears normal. Each "lucky success" recalibrates the team's risk perception threshold, until one deviation happens to trigger a catastrophic chain reaction.

Back in the AI programming context: every time the model writes correct code without oversight, it makes you more relaxed the next time. Over time, the probability that you'll over-trust AI at some critical future moment keeps increasing.

This gradual inflation of trust is precisely the engineering risk that's hardest to guard against.

Evaluating Software Quality in the AI Era

The convergence of these two paradigms raises a deeper question: how should we evaluate software quality?

Software quality assessment has undergone multiple paradigm shifts. In the 1970s-80s, quality was primarily measured through formal verification and lines of code; in the 1990s, CMM (Capability Maturity Model) introduced a process-oriented quality perspective; in the 2000s, the Agile movement placed "working software" above documentation; in the 2010s, DevOps culture emphasized operational metrics like deployment frequency and change failure rate. Now, the era of AI-generated code is catalyzing yet another paradigm shift.

In the past, a GitHub repository with 100 commits, a polished README, and automated tests typically meant the author had invested significant effort and time. Now, the same thing can be generated in half an hour, looking and structured exactly the same.

"Even for my own projects, I can't tell anymore."

Simon reached a pragmatic conclusion: rather than test coverage and documentation completeness, he values someone having actually used the thing. A Vibe Coding project that real users have been using daily for two weeks is more trustworthy than a beautifully generated project that has barely been validated in practice.

This perspective aligns with Netflix's Chaos Engineering philosophy: a system's reliability can only be proven through continuous operation under real load, not inferred through static analysis or test coverage. In the era of AI-generated code, traditional code review assumes the reviewer can understand the code's intent and context, while AI-generated code often lacks this traceable "chain of intent"—further amplifying the importance of runtime validation.

In other words, actual usage duration is replacing code review as the new quality signal.

The Bottleneck in Software Development Has Shifted

When code output goes from 200 lines per day to 2,000 lines per day, the entire software development lifecycle needs to be redesigned—because existing processes are fundamentally built around the assumption that "writing a few hundred lines of code takes a day."

The Theory of Constraints (proposed by Eliyahu Goldratt) states that any system's overall output is limited by its weakest link. In traditional software development, code writing is typically the primary bottleneck—explaining why the entire industry built code review, continuous integration, Sprint planning, and other processes around it. When AI increases coding speed by an order of magnitude, the bottleneck inevitably shifts to other stages: requirements clarification, architectural decisions, test validation, security auditing, and deployment operations. This is highly consistent with manufacturing history—when CNC machines increased machining speed 10x, the bottleneck shifted to design, material preparation, and quality inspection.

The bottleneck shift doesn't only occur in downstream testing and deployment—it happens upstream too. Anthropic's design lead Jenny Wen noted: traditional design processes are so rigorous and conservative because design mistakes meant engineers would waste three months of development time. But if building costs drop dramatically, the design process can also tolerate greater room for experimentation.

This means AI programming tools aren't just changing the "writing code" step—they're reshaping the entire chain from design to delivery. When downstream bottlenecks disappear, upstream conservative strategies lose their reason for existence, and the entire value chain needs rebalancing.

Why Software Engineers' Careers Remain Secure

Despite the blurring boundaries between Vibe Coding and Agentic Engineering, Simon isn't worried about software engineers' career prospects, for three reasons:

1. AI is an amplifier of experience, not a replacement: The more engineering knowledge you possess, the faster you can move with AI tools. A novice and a senior engineer using the same AI tool still produce vastly different quality output. The key here is that effective use of AI tools requires developers to have the ability to judge output quality—you need to know what good architecture looks like, what a secure implementation is, what maintainable code looks like, in order to guide AI in the right direction and correct it when it goes astray.
2. Software development is inherently extremely difficult: Even with all AI programming tools, building reliable production-grade software remains "extremely hard"—that hasn't changed. Consistency problems in distributed systems, security vulnerability prevention, performance optimization for large-scale systems, legacy system migration—the complexity of these challenges far exceeds generating individual code snippets.
3. Users want professionally validated products: As political commentator Matthew Yglesias put it, what people actually want isn't to Vibe Code their own tool—it's for professional software companies to use AI to build better, cheaper products.

Regarding concerns about "enterprises building AI systems to replace SaaS," Simon's view is equally pragmatic: no enterprise will adopt a CRM system unless at least two large enterprises have successfully used it for six months. Solutions validated in real-world scenarios will always have irreplaceable market value.

Conclusion: Acknowledging Discomfort Is Itself a Form of Professionalism

Simon Willison's reflections reveal a critical inflection point in the development of AI programming tools: when tools become sufficiently reliable, the line between "responsibly using AI" and "blindly trusting AI" becomes increasingly difficult to maintain.

This isn't a solved problem—it's a tension that every engineer using AI programming tools like Claude Code must remain vigilant about. Normalization of deviance doesn't sound an alarm; it simply erodes your standards of judgment bit by bit without you noticing.

Acknowledging this discomfort is perhaps itself a way of maintaining professionalism.