"Are we vibe coders now?"
That was the verbatim pushback I got from engineers during early Claude Code adoption at the enterprise org I worked with. It carried weight. Was switching to a Claude-first workflow a craft downgrade? Was the new normal "describe what you want, accept what comes back, ship it on Friday"? The question was sincere. The people asking it had every reason to ask. The Stack Overflow Developer Survey 2025 captured the climate: positive sentiment toward AI tools dropped to 60%, 46% of developers distrust AI accuracy, and 66% cite "almost right, but not quite" as their top frustration. They had been burned. They were not wrong to flinch. (The recovery playbook for that burned cohort is its own post; this one is about the discipline question that comes after the trust question.)
The answer I gave them, and the answer this post is built around, is that AI Coding is not one thing. It is an umbrella over a discipline spectrum, and where you sit on that spectrum has little to do with the tools you have installed. It has everything to do with who owns the verification loop. I take that diagnostic to the market level, where Gartner's IDE-optional prediction collides with it, in IDE-optional is earned, not granted.
AI Coding Is the Activity. Vibe Coding and Agentic Development Are the Discipline Levels.
AI Coding is the umbrella. Underneath sit a range of practices that look different on the outside but share the same activity: a developer producing software with substantial help from a large language model. The variable that separates them is not the tool. It is the rigor of the loop around the tool.
Andrej Karpathy coined "vibe coding" in February 2025. He meant "fully giving in to the vibes" and forgetting the code exists, framed as a throwaway-project mode for personal exploration. Within a year, the label had been picked up by tool vendors and developer Twitter. It was laundered into something else: a marketing posture for shipping production software fast. By April 2026, Karpathy reframed the practice at Sequoia AI Ascent. He introduced "agentic engineering" as the professional successor. Vibe coding raises the floor, agentic engineering raises the ceiling. Agents orchestrated inside a system that preserves the engineering quality bar. The term creator had moved on. The teams using the label, in my experience, had not.
The most useful framing I have seen comes from Backslash Security. They break AI Coding into three named tiers along a control continuum. Full Vibe means no review, no feedback loop beyond reprompting. Guided Vibe is light editing under shared human-AI control. Structured Vibe is human-directed with strict code review and testing. Agentic systems sit at the ceiling of that same spectrum as a fourth stop, not as a separate category. The VibeX 2026 workshop at EASE 2026 tracks the same span in academia. It runs from token-level completions to autonomous multi-file agents. The spectrum framing has won across security research and academic curriculum.
Calling these "different tools" is a category mistake. They are the same activity at four different rigor levels. The agentic-development starter guide I wrote earlier this month covers the operational form that the discipline takes when you commit to it: the plan-audit-implement-verify cycle, run for every task, every time. This post is about a different question: how do you tell which tier you sit on right now?
The Diagnostic Is Who Owns the Verification Loop
Vibe coders do not check their work, and most of them do not know how. That is the diagnostic in one sentence. It is uncomfortable because it is harsh, and it is harsh because it is precise.
Anthropic's own Claude Code Best Practices documentation puts it as plainly as a vendor will. Giving Claude a way to verify its work is the move it emphasizes. Without a check the model can run, the doc continues, "looks done" is the only signal available, and you become the verification loop: every mistake waits for you to notice it. Anthropic's engineering team describes the verification stack disciplined agentic work runs on. Tasks have explicit success criteria. Each task gets multiple trials. Code-based, model-based, and human graders layer together. Transcripts get logged. The same posture professional engineering orgs have used on human-written code for decades.
Ownership of the verification loop looks like three layers in priority order. First, human review on every change of consequence. The review must be calibrated to what the change can break, not a glance at a diff before merging. Second, automated tests. For greenfield work, tests get written first. The Superpowers plugin's /writing-skills skill bakes test-driven development into its iron-law sequence: no skill ships without a failing test first. Third, dedicated verification subagents with personas tuned to your situation. Examples: a paranoid security reviewer, or a literal-reading documentation auditor. Stack them because no single layer catches everything.
The opposite of all this is not laziness. It is mismatched mechanism. A team can write clear directives in CLAUDE.md and still find them ignored at runtime. That is because CLAUDE.md is advisory by design, not a guarantee. If a rule has to hold every time, it belongs in a hook, not a paragraph. The grey-literature review at arXiv 2510.00328 gives the empirical shape: 36% of self-described vibe-coding practitioners skip QA entirely. 18% accept output without verification. Only 29% apply systematic review and testing. The diagnostic is not perfect (some vibe coders do informal review). It is the most reliable single signal you can ask of a workflow. Organizations do not let engineers code and ship without a check. The same standards apply to AI Coding.
When "Agentic" Is Just Vibe Coding With Extra Steps
The part most adjacent posts skip is the data. The discourse on this topic is opinion plus anecdote. Primary research from 2025 and 2026 is sitting in plain sight, and almost nobody puts it next to the framing question. So:
Read those four numbers as one story. The Veracode 2025 GenAI Code Security Report tested over 100 LLMs and found cross-site scripting was missed in 86% of relevant samples. Security performance was flat across model size and training sophistication. The METR randomized controlled trial measured experienced open-source maintainers and found they were 19% slower with AI tools. They predicted 24% faster going in and still believed they were 20% faster after the measured slowdown.
Opsera's 2026 enterprise benchmark found AI cuts time-to-PR by up to 58%, and then those PRs sit 4.6 times longer in review. GitClear's 2025 analysis of 211 million changed lines shows copy-paste exceeded refactoring for the first time on record. None of this is what success looks like.
It is what "extra steps" look like. A team switches from Copilot to Claude Code, adds two CI hooks, calls the existing diff review "agentic oversight," and labels the result agentic. The label is comfortable. The verification loop is no closer to enforced than it was last quarter. And the failure mode is not gone, just moved. It shows up at code review, in security audit, in the next migration, in the on-call page at 3am for a CVE that was sitting in the diff a junior reviewer accepted. An earlier post on workflow versus training covered the team-level version of this same pattern; the engineering manager's governance guide covers what closing the loop looks like at organizational scale.
When the Force Multiplier Holds (and When It Doesn't)
Here is what the upper end of the spectrum buys you when the verification loop is owned. As one of my agentic-development test runs, I took on a large initiative on a codebase and tech stack I had never touched before. From the outside it looked like vibe coding: a single engineer, a model, an unfamiliar repo. It wasn't. The foundation underneath was a Claude Code infrastructure tailored to that codebase, well-defined feature documentation, and a curated suite of skills encoding the team's standards. I shipped the implementation in under two weeks. The estimate before I started: four mid-to-senior engineers for over six weeks, around twenty-four person-weeks. Same activity as vibe coding on the surface. Different verification loop underneath.
The strongest published counter to the spectrum framing is the academic argument that vibe coding and agentic development are architecturally distinct paradigms: one has no embedded validation loop, the other has fully integrated execution pipelines as a first-class feature. Reviewing vibe-coded output, the argument goes, makes it reviewed vibe coding, not agentic. The argument is correct about the artifact and wrong about the cause. The architecture follows the discipline. When you choose to own the verification loop, you build the embedded pipeline. When you don't, you don't. The architectural binary is the downstream effect of the verification choice.
VibeCheckMe is the case-study version of this point: a production app I built entirely from a phone, 13,176 lines across 75 files, 253 commits, zero user-facing error states because the fallback system was designed in. The Claude iOS surface looked like the most vibe-coded surface possible. The verification loop was structural. The AI Persona Profiler is the contrast set: a 12-point validation rubric with two tests designed to fail produced a 59-out-of-60 voice fidelity score. Different surfaces, same posture.
If it's for work or anything professional, you're better off leaving the vibes behind.
A counter-example worth naming so this doesn't read like a sales pitch: throwaway pages, single-shot fun projects, mobile-game playgrounds where stakes are low and you won't run the code twice. Vibe-code those freely. I'm personally too neurotic to skip the infrastructure even on a fun mobile-game playground; that's a personal habit, not a prescription.
The One Question to Take to Monday
AI Coding is one activity. Vibe coding and true agentic development are positions on its discipline spectrum. The diagnostic that distinguishes them is who owns the verification loop, and the failure modes of getting it wrong don't show up until production. The single question to take to your next standup: in your current workflow, who owns the verification loop, and what enforces their ownership? If the answer is "the engineer, sometimes, when they remember," you know which tier you are at and which tier you wanted to be at.
If you want a second pair of eyes on whether your team's setup owns the loop or just labels itself agentic, the assessment surfaces architecture gaps that hide in plain sight, or book a 15-minute walkthrough and we'll look at where the verification loop sits in your stack today. Encoding the verification loop into the tooling is the project I do most often.