Security Engineer Pushes Back on Anti-AI Bias: Does Writing Code with AI Really Mean 'Vibe Coding'?
The community mocks all AI-assisted development as vibe coding, conflating definitions; what truly deserves criticism is unreviewed bad code.
An engineer with over a decade of software and security experience points out on Reddit that the community's hostility toward AI-assisted development has reached an absurd level: whenever a project touches AI, the comments flood with "vibe coded" and nobody reads the content anymore. He clarifies that the term was coined by Andrej Karpathy to mean relying purely on vibes and giving up understanding the code; Simon Willison also drew the line that code which has been reviewed, tested, and understood isn't vibe coding. His own workflow—building with Claude Code, having a second agent review, and reviewing and testing it himself before release—still gets labeled. The article also cites DHH's announcement that 37signals has gone pencils down on handwritten code, and the Linux kernel's acceptance of AI-assisted code that humans review and take responsibility for, showing industry benchmarks have already shifted. The core controversy is accountability: bad code and unreviewed code deserve criticism, not blanket rejection just because AI was involved.
An engineer with over a decade of experience in software and security posted on Reddit, saying the community's hostility toward AI-assisted development has reached "absurd" levels. His observation is specific: whenever someone shares a project built with AI, the top comment is often the same phrase—"vibe coded." No matter how much work went into the project, the moment AI appears, people stop reading the content and just start mocking.
"Vibe coding" has been misused
The engineer points out that the term has a clear definition. When Andrej Karpathy coined "vibe coding," he was describing "fully giving in to the vibes... and forgetting that the code even exists." Simon Willison drew the line: if you've "reviewed, tested, and understood all the code, then it's not vibe coding."
In other words, using AI to generate a first draft and then putting it through human review and testing is a different thing from "handing everything to AI with your eyes closed." But in reality, the two get conflated. The poster's own workflow is: build with Claude Code, have a second agent do the review, and finally review and test it himself before release—and even then, it still gets labeled "vibe coded."
Andrej Karpathy is a founding member of OpenAI, former Director of AI at Tesla, and the person who coined the term "vibe coding." He initially used the term on social media to describe an extreme AI programming experience: being fully immersed in a conversation with a large model, continuously accepting suggestions by feel, running, hitting errors, and letting the model fix them again—without even reading the generated code line by line.
Simon Willison is a co-creator of the Django web framework and a long-time active open-source developer and commentator on AI tools. His definition of "vibe coding" emphasizes accountability: it only counts as vibe coding when the developer gives up understanding and reviewing the code; if the code has been read by a human, tested, and its behavior can be explained, then "AI-assisted programming" is the more accurate term. This distinction shifts the discussion from "whether AI was used" to "whether humans still maintain control and responsibility"—and it's also the key concept for understanding the controversy throughout this article.
Industry benchmarks have already shifted
The post also cites a fairly striking fact: at Rails World, DHH—the creator of Rails himself—said that 37signals has gone "pencils down" on handwritten code, and that agent-written code has become the norm. On the other side, the Linux kernel has also begun accepting AI-assisted code, on the condition that humans review it and take responsibility.
When the creator of Rails no longer writes code by hand, the problem was perhaps never the tool itself. The poster's conclusion is: bad code deserves criticism, and lazy, unreviewed code deserves even more criticism—but rejecting everything simply because it's "touched by AI" isn't code review, it's just bias.
DHH (David Heinemeier Hansson) is the creator of the Ruby on Rails framework and co-founder of Basecamp and 37signals, long known for being outspoken about engineering practices and how teams work. Rails is a highly influential web development framework, and its "convention over configuration" and rapid-build philosophy have been adopted by a large number of startups and product teams. That's why DHH's announcement at Rails World that the team has gone "pencils down" and that agent-written code is now the norm carries strong signaling effect: it doesn't come from an outside observer, but from a framework creator known for engineering taste and productivity.
The Linux kernel is one of the most critical open-source projects in the world, and its contribution process is known for strict code review and maintainer accountability. The kernel community's condition for accepting AI-assisted code is that human contributors must review it and bear corresponding responsibility—fundamentally different from casually pasting model output, and it draws an operable governance boundary for "AI participating in development."
The real issue behind the controversy
At its core, this debate is about accountability. The Linux kernel's acceptance conditions are clear: humans review, humans are responsible. The shift at 37signals doesn't mean giving up on quality either—it means moving human effort from typing to design and gatekeeping. The concern of opponents—that "AI generates unmaintainable code"—is real, but the solution should be a stricter review process, not a blanket rejection.
The question the poster raises at the end is worth every developer thinking about: where do you draw your line? Since when did "built with AI" become an insult?
Related articles
VERS: Editing Activation Explanations to Halve Reasoning Model Tokens
VERS guides reasoning models by editing activation explanations, cutting 45.8% of tokens on GSM8K with only a 0.82 pp accuracy drop and transferring to larger models, but losing accuracy on competition problems.
Finding Errors Is Not Enough: Selective Model Escalation for Entity-Targeted Sentiment Analysis
This study explores selective model escalation for entity-targeted sentiment analysis, comparing data collection ordering, uncertainty-driven re-examination, and model routing—finding that minority-class priority only helps at very small data volumes, the oracle upper bound far exceeds actual gains, and escalation must be tailored to each dataset.
WAS-PO: Using Whitened Advantages to Solve the Correlation Trap in Multi-Reward Reinforcement Learning
WAS-PO paper proposes whitening advantages to correct correlation bias in multi-reward RL: when rewards are correlated, naive weighted summation effectively applies Σ^{1/2}w instead of w. Experiments show training reward improves steadily, but held-out accuracy does not improve in sync, and under two rewards it actually falls behind.