“I’m actually getting nervous as AI-written code becomes more reliable” — this might sound like a humblebrag about technological progress, but what truly sent chills down my spine was realizing I was unconsciously letting go of certain engineering instincts.

When Simon Willison mentioned on a podcast that “the line between vibe coding and agentic engineering is blurring,” I immediately revisited his article from three months ago, Not All AI Programming Is Vibe Coding. Back then, he clearly distinguished the two approaches: the former being “blindly hammering out code” like mystical programming, while the latter involved professional engineers rigorously building production-grade systems with AI tools. But the latest interview revealed a red flag: when AI-generated code reaches a high enough accuracy rate, even seasoned developers start slacking on code reviews—this isn’t a technical issue but the emergence of an ethical gray zone in engineering.

Many might interpret this trend as “AI-driven productivity liberation,” but skipping three verification steps leads to misjudgment:

First, examine the divergence in application scenarios. Willison initially insisted that vibe coding was only suitable for personal toy projects because “the damage is limited to oneself,” while agentic engineering must take responsibility for security, performance, and maintainability. But now he admits that even when handling production code, he’s stopped reviewing AI outputs line by line—treating them like microservices delivered by another team, only digging into implementation details when something breaks. This “trust transfer” essentially applies human collaboration norms to AI, but the critical difference is: a human team is accountable for code quality, while Claude Code isn’t.

Second, establish trust-building mechanisms. The podcast’s analogy of an “image-scaling service” is particularly telling: human teams build credibility through historical delivery quality, while AI tools lack such a reputation system. Currently, developers’ trust in AI stems entirely from repeated validation (“it never messes up JSON APIs”), but this empiricism has a fatal flaw—just as high test coverage doesn’t guarantee zero bugs, local reliability doesn’t equal global trustworthiness. Upon reviewing Willison’s examples of relaxed code reviews, I found they mostly involved repetitive glue code (CRUD endpoints, data format conversions, etc.), which ironically creates a “false sense of security.”

Third, assess paradigm shifts. The most dangerous cognitive bias today is framing the economic calculation of “review cost > expected risk” as a technological leap proclaiming “AI has passed the Turing test.” As Willison’s unease reveals: with 25 years of experience, he knows which code can skip scrutiny, but juniors might replicate this workflow without risk discernment. It’s like how seasoned drivers still watch the road in autonomous mode, while novices might doze off.

Returning to the core issue: as AI tools blur the line between “hobbyist” and “production” coding, what we’re truly losing is the “defensive driving” mindset in code reviews. A stopgap solution, as Willison practices, is creating a “trust tier list”—which patterns are exempt (e.g., data-cleaning scripts) and which demand manual review (e.g., auth logic)—with the list evolving alongside team maturity. But the deeper conflict lies in how engineers’ pride is shifting from “I wrote robust code” to “I deployed a working system.” This value realignment may warrant more caution than the tech itself.

The easiest trap is equating “AI-generated code ≈ human-engineered code.” The real difference isn’t accuracy but error patterns—humans make typos but maintain logical consistency, while AI might produce syntactically perfect code with bizarre security holes. Next time you hear “this endpoint never fails,” ask: did we test thoroughly, or were the test cases too forgiving?

(Final word count: 1,980)