Agentic Engineering, Not Vibe Coding: How a 12-Year Engineer Ships With AI in 2026

What is the difference between vibe coding and agentic engineering?#

Vibe coding is when you describe what you want, accept whatever the AI produces, and never really read the code. Agentic engineering is when you plan the work, write a spec, point AI agents at it, and personally gate every line before it ships. Same tools, opposite discipline. One optimizes for speed on things that don't matter. The other optimizes for correctness on things that do.

I've been shipping software for 12 years, across native iOS and Android, Flutter, Rust, web, and desktop. I was a working engineer long before any of this tooling existed. So when people ask whether I "vibe code," the honest answer is no. I do something that looks superficially similar and is fundamentally different.

The distinction in five lines#

• Vibe coding is a sensible mode for disposable work where failure is cheap.
• Production work needs a written unit of intent, explicit acceptance criteria, and a human owner.
• AI can make generation faster without making verification cheaper.
• Tests are evidence, not absolution; generated tests need the same review as generated implementation.
• If you cannot explain a diff, its failure modes, and its rollback path, it is not ready to merge.

Where "vibe coding" actually came from#

Andrej Karpathy coined the term on February 2, 2025, describing a mode where you "fully give in to the vibes" and stop thinking about the code as code. He described accepting diffs without reading them closely, pasting errors back to the model, and letting the project grow beyond his understanding (Karpathy on X).

The phrase went mainstream fast. Collins Dictionary named "vibe coding" its Word of the Year for 2025, defining it broadly as using natural-language prompts to help write code (Collins Dictionary).

Worth reading the original tweet closely, though. Karpathy was describing weekend projects. "It's not too bad for throwaway weekend projects," he wrote. The internet turned a specific, honest observation about disposable code into a general philosophy for building everything. That's the part I push back on.

Vibe coding is genuinely fine (for the right things)#

I want to be fair here, because a lot of the backlash is snobbery. Vibe coding is legitimately good for a real category of work:

• Throwaway prototypes you'll delete in a week.
• A script to rename 400 files once.
• A weekend toy nobody else will run.
• A quick spike to see if an idea is even worth pursuing.
• Personal tools where the worst-case bug is that you are mildly annoyed.

For all of that, reading every diff is a waste of your life. Give in to the vibes. Ship it. Move on. The whole point of throwaway code is that it's throwaway. Applying production rigor to a script you'll never run again is its own kind of malpractice.

The problem is not vibe coding. The problem is vibe coding things that other people depend on.

Why the work can feel harder even when the typing gets easier#

This next claim is first-hand experience, not a universal benchmark: a day of serious agentic work often leaves me more tired than a day of hand-writing code. I am doing less typing and more simultaneous judgment. The cognitive load moves upstream into decomposition and downstream into verification. The middle gets cheap; the ends stay expensive.

That distinction matters because "the agent finished" is not a meaningful project state. It may mean only that code was produced. The engineer still has to decide whether the requested behavior was the right behavior, whether the implementation fits the system, and whether the evidence covers the failure modes that matter.

My opinion: the verifier is the bottleneck now, not the model#

My blunt take: in 2026, the model is no longer the constraint. You are.

The models are good enough to produce more plausible code than any human can carefully review. So the limiting factor in shipping quality software stopped being "can the AI write it" and became "can a competent human verify it fast enough." The verifier is the bottleneck.

Some evidence points in the same direction, although it does not prove a universal rule. GitHub's Octoverse 2025 reported 518.7 million merged pull requests, up 29% year over year (GitHub Octoverse 2025). Volume is not value. A longitudinal preprint studying enterprise "ship 2x more" mandates reported larger pull requests, longer review, and more defects as review coverage fell behind (the study on arXiv). A separate benchmark preprint reported that evaluated frontier models found only a subset of the issues human reviewers identified (SWE-PRBench). These are specific studies with specific settings, not a law of software development; they are still a useful warning against treating generated volume as delivered quality.

Together, those findings point to one bottleneck. Generation is nearly free. Verification is not. If your process doesn't respect that asymmetry, you're just manufacturing bugs at scale with better tooling.

Vibe coding vs. agentic engineering#

Here's how I'd draw the line, concretely:

That last row is the uncomfortable one. Agentic engineering works because I can tell when the agent is wrong. The skill that used to be "write the code" is now "recognize good code instantly and reject bad code faster." You cannot verify what you don't understand. Vibe coding lets you skip that. Agentic engineering depends on it.

My actual loop: plan, spec, orchestrate, gate#

This is what a real feature looks like for me. Nothing exotic, but every step exists for a reason.

1. Plan. Before any agent touches the repo, I decide what I'm building and why. What's the smallest version that's actually correct? What are the edge cases? What could break in production? This is human work. AI is genuinely useful as a thinking partner here, but the decisions are mine.

2. Spec. I write the intent down. Not a vague prompt, a spec: what the change should do, what it must not break, the acceptance criteria, the files likely involved. The tighter the spec, the better the agent performs and the easier the output is to verify. A good spec is also a test plan in disguise. This step is where most of the quality actually gets decided.

3. Orchestrate. Now I point agents at the spec. Often more than one, working in parallel on separable pieces. I'm not typing implementation; I'm directing it, correcting course, feeding back when an agent goes down a wrong path. This is the part that looks like vibe coding from across the room. It is not, because of steps 1, 2, and 4.

4. Gate. Nothing merges on vibes. I read every diff. Types have to pass. Tests have to pass, and I read the tests too, because a green suite the agent wrote to match its own bug is worse than no suite. I run it. I try to break it. Only then does it ship. This is the bottleneck, and I treat it as the most important step, not the annoying last one.

The trick to the whole thing: I let generation be cheap and I keep verification expensive. I'll happily throw away three agent attempts to get one I'd sign my name to. What I won't do is lower the bar at the gate because the code came out fast. Speed at the input, rigor at the output.

My production gate checklist#

The four-step loop is the process. This is the final gate I use to decide whether a change is actually done:

• Intent: Can I state the user-visible behavior and the non-goals in two or three sentences?
• Fit: Does the implementation follow the codebase's existing boundaries, or did the agent invent a parallel system?
• Diff: Have I read every changed line, including generated configuration, migrations, and tests?
• Evidence: Did types, targeted tests, the production build, and a real user path pass?
• Failure: What happens when a dependency times out, input is malformed, authorization is missing, or the operation is repeated?
• Security and privacy: Did the change widen data access, expose a secret, log personal information, or move trust into the client?
• Operations: Can I observe the failure and roll the change back without guessing?
• Understanding: Could I debug this at 2am without asking the original agent what it meant?

Not every throwaway script needs this list. Anything that handles another person's data does. The related solo-building rule is even shorter: never merge code you could not have written yourself.

So should you vibe code?#

Yes, sometimes. If you're building a weekend toy, a one-off script, a prototype you'll delete, then give in to the vibes and enjoy it. That's what Karpathy actually described, and he was right about it.

But the moment other people depend on the code, the moment it touches real data, the moment you'll have to maintain it in six months, the discipline has to change. Not the tools. The discipline. You go from "accept the diff" to "own the diff." From vibes to a spec and a gate.

My bet for 2026 and beyond: the engineers who win won't be the ones who generate the most code. The winners will be the ones who can verify faster without lowering the bar. Taste and judgment, including the ability to say "no, that's wrong" before a benchmark catches up, become more valuable as generation gets cheaper. The model got cheap. Being right did not.

That's the difference between vibe coding and agentic engineering. One forgets the code exists. The other never does.