Software teams face a widening split. One group races from concept to clickable demo in minutes, guided by natural language prompts and AI models that churn out prototypes. The other group shoulders the full weight of production systems — the reviews, the incidents at 2 a.m., the migrations that still haunt old code, and the blame when something fails for customers.
Call the first group vibe coders. The second, software engineers. The label matters less than the gap in accountability. And that gap is growing even as tools from Cursor, Claude, and others make generation faster than ever.
Yusuf Aytas laid out the contrast sharply in a post published just yesterday. A vibe coder measures success by time to first working version. A software engineer measures time to safe merge. The difference sounds academic until pull requests land in a shared codebase with real users, compliance rules, and operational pain accumulated over years. (Yusuf Aytas)
Short. Direct. And increasingly relevant as AI-generated code floods repositories.
Andrew Kelley, creator of the Zig programming language, offered a blunt assessment in a recent interview. His project bans AI contributions. He described large pull requests full of unrelated changes, broken legacy behavior, strange dependency additions, and contributors unable to explain what they submitted. “Invariably garbage,” he said. Maintainers spend afternoons cleaning up what took the submitter minutes to generate.
Aytas does not call for bans. He calls for placement. Vibe coding belongs in discovery, where the cost of being wrong stays low. Delivery demands different standards. The same habits that accelerate ideation create review debt when applied to systems that cannot tolerate unexplained decisions.
But the discourse has evolved since the term first surfaced in early 2025. Addy Osmani, engineering leader at Google, drew a clear line in a detailed examination. Vibe coding involves free-flowing, conversational prompts where developers act as orchestrators, often forgetting the code exists once it runs. AI-assisted engineering treats the model as a collaborator inside a structured software development lifecycle, with rigorous review, architecture oversight, and human accountability at every step. (Addy Osmani on Medium)
Osmani warns against conflating the two. Doing so devalues engineering discipline and misleads those entering the field. “No, you won’t be vibe coding your way to production — not if you prioritize quality, safety, security and long-term maintainability at scale,” said Canva CTO Brendan Humphreys, quoted in the piece.
Simon Willison reached a similar tension from the other side. In a post from last month, the longtime developer and creator of Datasette noted that vibe coding works beautifully for personal tools where bugs hurt only the author. “If you’re building software for other people, vibe coding is grossly irresponsible because it’s other people’s information. Other people get hurt by your stupid bugs.” He has watched the line blur in his own agentic engineering work. He no longer reviews every line generated by reliable agents, yet the discomfort remains. (Simon Willison)
Experience, it turns out, matters more. The AI Vibe Coding Paradox, as one analysis framed it, states that the better machines get at producing code, the more valuable human judgment becomes. Without it, architectures collapse under their own weight. (Data Science Collective on Medium)
Teams already see the pattern. A quarter of startups in one Y Combinator cohort reportedly ran codebases almost entirely AI-generated, according to reporting from early 2025. Prototypes fly out the door. Maintenance arrives later. And when it does, seniors turn into code janitors cleaning up after prompt engineers who never built mental models of the systems they touched.
Stack Overflow explored the extreme case: a non-technical person using vibe coding tools to build an application from scratch. The foundation appeared in ten minutes. The result revealed classic signs of unexamined output — scattered structure, assumptions that would not survive real use. The post asked a simple question. Is it any good? (Stack Overflow Blog)
Production reality bites harder. Context lives outside files. It hides in past incidents, customer quirks, security constraints that evolved over time, and strange decisions no one dares touch anymore. Models read vast amounts of code. They do not carry the scars. Engineers do. When a junior prompts an AI to “fix the whole thing,” the habit feels productive until the pager goes off.
Aytas calls this the apprenticeship problem. Juniors should use these tools. They accelerate learning when applied to explanation, comparison, and example generation. Yet the shortcut that skips system understanding weakens the very judgment that separates strong engineers from fragile ones. Code review once served as contributor poker — a way to identify people worth growing into the core team. Unexplained AI output breaks that table.
So what does responsible practice look like in 2026?
Engineers who succeed treat discovery and delivery as distinct modes. They vibe code to test ideas and shrink the distance between concept and something tangible. Then they switch. They bound the task. They reduce decision space before the model touches the keyboard. They convert output into owned work that can withstand review, rollback planning, and operational handover.
Tools have improved. The economics have not.
AI makes code generation cheaper. Safe integration into living systems grows more expensive when output arrives bloated, unexplainable, and disconnected from team conventions. The demo proves something can run. It does not prove the change can be absorbed.
Companies recruiting for “vibe engineer” roles signal the confusion. Some startups ship AI-heavy codebases and celebrate velocity. Others watch technical debt compound after three months, exactly as spec-driven advocates predicted. The pattern repeats across reports from this year.
Willison captured the professional stance best. He wants to build higher quality production systems faster. Tools amplify skill. They do not replace the need for accountability when other people’s data or money sits on the line.
That leaves leaders with a practical choice. Let vibe coding habits leak into delivery and pay later in maintenance, security incidents, and slowed velocity. Or draw the line explicitly. Use the speed where stakes stay low. Enforce ownership where they do not.
The future does not belong to those who generate the most code. It belongs to those who can stand behind it when the system speaks back. Some will orchestrate prompts and walk away. Others will own the outcome. The difference is already visible in who gets promoted, whose code survives contact with reality, and whose teams move fast without breaking things that matter.
And the gap is only widening.
WebProNews is an iEntry Publication