Karpathy Called Vibe Coding 'Passé' — The Case for Agentic Engineering

Vibe coding was a genuine breakthrough that let people ship real products fast — but at scale it compounds into technical debt nobody understands. This module traces how vibe coding rose, where it breaks down, and the name Karpathy gives to what comes next.

Andrej Karpathy coined the term "vibe coding" in February 2025. His original framing was simple: fully give in to the vibes, let AI build it, and iterate by feeling. No years of technical training required. You describe what you want and the AI handles the rest.

And it worked. A quarter of all startups in Y Combinator's 2025 batch had codebases that were 95% AI-generated. People were shipping real products in days instead of months. That was genuinely new and genuinely useful.

If you started building this way, you were on the right path. Vibe coding was always meant to be the entry point.

The problem is that most people treated it like the destination.

Here is what happens when you vibe code at scale:

Every prompt you fire without a clear plan adds something you don't fully understand. Everything you don't understand makes the next problem harder to fix. It compounds quietly — until suddenly nothing works and you don't know where to start.

You've probably felt this. You're 200 prompts deep. The app was supposed to take two hours but it has been two days. You fix one thing and something else breaks. And you don't know why — because you didn't write any of it.

Stack Overflow surveyed 49,000 developers: trust in AI-generated code dropped from 40% to 29% in a single year. That is not coincidence. That is what happens when people ship things and discover the output isn't as solid as it looks.

The numbers behind the collapse are sobering:

• 45% of AI-generated code contains security vulnerabilities (arxiv 2505.19443)
• Code duplication increased 48% in vibe-coded projects
• Refactoring activity dropped 60%

The breaking apps, the features that conflict with each other, the project that felt fast at the start and then froze completely — that is all the same problem. You were reacting instead of defining.

In early 2026, Karpathy posted a follow-up to his original vibe coding framing. The term he now prefers is agentic engineering. He broke it down in two parts:

"Agentic because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight. Engineering because there is an art and science and expertise to it. It's something you can learn and become better at, with its own depth of a different kind."

Two words. Both matter.

Agentic — you direct, you don't type. You are the architect and the reviewer. The agent is the implementer. Engineering — this is a real skill with real depth. Not luck. Not prompting talent. A learnable discipline.

The shift is captured in one sentence: stop describing, start defining.

---

Agentic engineering is a shift in thinking, not tooling — the same AI produces wildly different results depending on whether you prompt it or direct it. This module contrasts the prompter and the director, then distills the mindset into three concrete habits.

The clearest way to understand the gap between vibe coding and agentic engineering is to compare a prompter and a director using the exact same tools, the exact same AI.

The Prompter says:

"Build me a user dashboard."

The Director says:

"Build me a dashboard that shows these three metrics — daily active users, revenue this week, and churn rate — pulling from the analytics table in our Postgres database. It should update every 30 seconds using a polling hook, and show a skeleton loading state while fetching. Use our existing Card component from the design system. Do not add new dependencies."

Both are using the same AI. The director gets a working feature. The prompter gets something to react to and fix.

The difference is not technical knowledge. It is thinking clarity. The director knew exactly what they were building before AI touched anything.

This is the full table of contrast:

| Aspect | Vibe Coding | Agentic Engineering |

|---|---|---|

| Human role | Describe what you want | Architect, decompose, review |

| Code review | None or minimal | Every diff reviewed |

| Testing | Run it and see | Test-first, agent iterates until green |

| Agent autonomy | Single-turn generation | Multi-step: plan, code, test, commit |

| Best for | Prototypes, MVPs, learning | Production systems, team codebases |

| Failure mode | Technical debt, security holes | Coordination overhead, review bottleneck |

Karpathy's framework comes down to three habits. No extra tools, no coding knowledge required.

Habit 1: Define the output before you open the tool.

Not the feature. The outcome. What do you actually want to have at the end? What does this do for the person using it? What does success actually look like?

When you can answer that in two sentences, your prompts become 10x more precise.

Before prompt: "Add notifications."

After defining: "Add in-app notifications for new replies to a user's forum posts. Show a red badge on the bell icon with the unread count. Clicking the icon opens a dropdown listing the last 10 notifications with the post title, the replier's username, and a relative timestamp. Marking one as read removes the badge count for that item."

Habit 2: Give the AI one job at a time.

Vibe coders try to build everything in one big prompt. Agentic engineers break the build into small, clear steps.

First, build the login flow. Then build the dashboard. Then connect them. Each step is small enough that you can verify it worked before moving to the next one.

Habit 3: Review before moving on.

Test what you just built before prompting the next step. That one habit alone eliminates most of the "something broke and I don't know where" problem.

If you internalize nothing else from this guide, internalize this: every time AI produces output, you verify it worked before asking for the next thing.

---

The mindset becomes real through four concrete practices: context engineering, task decomposition, verification loops, and checkpoint discipline. This module walks through each one with copy-pasteable examples you can apply to your own project this week.

The agent doesn't know your codebase. Every session, it starts cold. Context engineering is the practice of curating what the agent sees so it can work intelligently inside your project instead of against it.

The primary artifact is a project instruction file. In Claude Code this is CLAUDE.md. In cross-tool workflows it's AGENTS.md. In Cursor it's .cursorrules.

A good context file includes:

• Architecture: What is this project? What are the core patterns?
• Commands: How do you run, test, and typecheck?
• Conventions: What are the rules for this codebase?
• Constraints: What should the agent never do?

Example for a Next.js project:

# CLAUDE.md

## Architecture
Next.js 15 App Router. Server components by default.
Client components only when interactivity is required.
Database: Convex. Auth: Clerk.

## Commands
npm run dev       # Dev server on port 3000
npm run typecheck # TypeScript strict mode check
npm run test      # Vitest suite

## Conventions
- All data mutations go through Convex mutations, never direct DB calls
- Components in /components, utilities in /lib
- Never use console.log in production code — use lib/logger.ts
- Never add new npm packages without asking

## Agent Workflow
- Run typecheck after every code change
- Commit working states before risky changes
- Write tests before implementation
- If stuck for more than 3 attempts, stop and ask

Anthropic's guidance: keep it under 300 lines. Focus on what causes mistakes if it's missing. The agent doesn't need everything — it needs the right things.

The granularity of your tasks determines whether agentic engineering works or wastes time. Too broad, and the agent loses coherence halfway through. Too narrow, and coordination overhead eats your gains.

The right size: one feature, one function, one module per session. Each task should be:

• Completable in one agent session
• Verifiable with a test or manual check
• Independent enough to commit on its own

Here is what decomposition looks like for a real feature — adding rate limiting to API routes:

Feature: Rate limiting for API routes

Task 1: Create Redis rate limiter module
  - File: src/lib/rate-limiter.ts
  - Sliding window algorithm, configurable per tier
  - Tests: src/lib/__tests__/rate-limiter.test.ts

Task 2: Add rate limit middleware
  - File: src/middleware/rate-limit.ts
  - Read limits from DB per API key tier
  - Tests: middleware integration tests

Task 3: Wire into API routes
  - Update src/app/api/chat/route.ts
  - Tests: e2e rate limit behavior

Task 4: Add rate limit headers to responses
  - X-RateLimit-Remaining, X-RateLimit-Reset headers
  - Tests: header presence assertions

Tasks 1 and 4 are independent and can run in parallel or in any order. Tasks 2 and 3 depend on Task 1. Good decomposition identifies these dependencies before you start — not while debugging a broken session at 2am.

Testing is the single biggest differentiator between agentic engineering and vibe coding.

With a solid test, an AI agent can iterate in a loop until the tests pass. This turns an unreliable generator into a reliable system. Simon Willison (prominent AI developer and researcher) articulates this cleanly: write failing tests first (red), then let the agent make them pass (green). The developer writes the specification as tests. The agent writes the implementation.

Test-first agentic workflow:

// Step 1: Human writes the test — this IS the spec
describe("user notification badge", () => {
  it("shows unread count when notifications exist", async () => {
    const { getByRole } = render()
    expect(getByRole("status").textContent).toBe("3")
  })

  it("hides badge when all notifications are read", async () => {
    const { queryByRole } = render()
    expect(queryByRole("status")).toBeNull()
  })
})

// Step 2: Agent implements until tests pass
// Step 3: Human reviews the implementation
// Step 4: Commit if review passes

Beyond unit tests, run typecheck, lint, and build after every agent session. These catch drift before it compounds.

The rule is simple: commit working states before every significant change.

If the agent fails, roll back instead of trying to fix forward. Starting fresh from a known-good state has a higher success rate than correcting a broken agent session. This is not pessimism — it is engineering discipline applied to a new medium.

Practical checkpoint rhythm:

1. Task defined and context loaded → commit current state
2. Tests written → commit
3. Agent implements, tests pass → commit
4. Human review passes → move to next task

Never start a new task from a broken or untested state.

---

Most prompts fail because the human hasn't finished thinking, not because the AI is limited. This module gives you a reusable Architect Prompt Template — and a filled-in example — that forces the thinking before the prompt.

Most prompts fail not because the AI is limited, but because the human hasn't done the thinking yet.

A vague prompt forces the AI to guess about:

• What success looks like
• What the existing system constraints are
• What should NOT change
• Who the user is and what they actually need

The Architect Prompt Template fixes this by requiring you to answer those questions before writing a single word to the AI. The discipline of filling it out IS the value — by the time you've completed it, you've already done the hard thinking.

The following is a reusable template. Every section in [BRACKETS] is a placeholder you fill in. Sections marked (optional) can be removed if not relevant.

---

## Context
Project: [PROJECT_NAME]
Tech stack: [TECH_STACK — e.g., Next.js 15, Convex, Clerk, TypeScript]
Relevant files: [LIST KEY FILES — e.g., app/dashboard/page.tsx, lib/api.ts]
Current behavior: [WHAT CURRENTLY HAPPENS in this area of the codebase]

## Goal
Build: [ONE-SENTENCE DESCRIPTION of what you want to exist when this is done]
Success looks like: [TWO SENTENCES describing what "done" means — observable behavior, not implementation details]
User impact: [Who uses this and what can they now do that they couldn't before?]

## Constraints
- [CONSTRAINT 1 — e.g., Do not modify the database schema]
- [CONSTRAINT 2 — e.g., Must work without adding new npm packages]
- [CONSTRAINT 3 — e.g., Must not break existing tests in __tests__/auth.test.ts]
- [CONSTRAINT 4 — e.g., Use the existing Button component from /components/ui]

## Output Format
Deliver: [WHAT FILES should be created or modified]
Tests: [WHAT TESTS should pass when you're done]
Do not: [WHAT THE AGENT SHOULD EXPLICITLY NOT DO]

## One Job (this session only)
[SINGLE SPECIFIC TASK for this session — not the whole feature, just this step]
Stop after: [THE EXACT CONDITION at which you stop and report back]

---

Here is the same template filled in for a real task: adding unread notification badges to a vybecoding.ai forum feature.

---

## Context
Project: vybecoding.ai
Tech stack: Next.js 15 App Router, Convex, Clerk, TypeScript, Tailwind CSS
Relevant files:
  - app/(main)/forums/page.tsx (forum listing)
  - components/forums/ForumNav.tsx (navigation component)
  - convex/notifications.ts (notification queries — exists but unused in UI)
Current behavior: The forum nav shows a bell icon but it is static. No badge. No dropdown. No real data connected.

## Goal
Build: A notification badge on the bell icon that shows the count of unread forum reply notifications for the logged-in user.
Success looks like: When a user has unread replies to their forum posts, a red badge with the count appears on the bell icon. When all replies are read or there are none, no badge appears.
User impact: Forum users immediately know when someone has replied to their posts without refreshing the page.

## Constraints
- Do not modify the Convex notifications.ts schema — only add a new query if needed
- Use the existing Badge component from /components/ui/badge.tsx
- Must work for logged-out users (show no badge, no error)
- Do not add new npm packages
- Do not change the layout or spacing of ForumNav.tsx beyond the badge addition

## Output Format
Deliver:
  - Modified components/forums/ForumNav.tsx with badge logic
  - New convex/notifications.ts query: getUnreadCount (if it doesn't exist)
  - Test: components/forums/__tests__/ForumNav.test.tsx covering badge show/hide
Do not: Build the full notification dropdown. Do not mark notifications as read. Do not add any animation.

## One Job (this session only)
Add the unread count badge to the bell icon in ForumNav.tsx, connected to real Convex data.
Stop after: The badge renders correctly in the browser with real data and the test file passes.

---

The difference in output quality between a prompt like "add a notification badge" and this filled-in template is not small. It is the difference between a working feature and an afternoon of fixes.

---

The real transition is not from writing code to writing prompts — it is from writing code to designing agent systems. This module names the skills that matter in 2026 and gives you a first session to run this week.

The transition from vibe coding to agentic engineering is often misunderstood as "from writing code to writing prompts." That describes vibe coding.

The actual shift is: from writing code to designing agent systems.

The valuable skills in 2026:

• Knowing what to build (product thinking)
• Breaking it into verifiable steps (systems design)
• Setting up conditions for verification (testing strategy)
• Evaluating agent output with rigor (code review)

These are the same skills that made senior engineers valuable before AI — applied to a new medium. IBM's research framed the paradox: AI-assisted development rewards rigorous engineering practices more than traditional coding ever did. Better specs yield better agent output. Stronger tests enable confident delegation. Cleaner architecture reduces hallucinations.

| Dimension | Vibe Coding | Agentic Engineering |

|---|---|---|

| Primary output | Code | Reviewed, tested agent output |

| Time allocation | 80% prompting, 20% fixing | 20% defining, 20% context setup, 60% reviewing |

| Bottleneck | Getting AI to produce anything | Task decomposition, review throughput |

| What gets you 10x | Writing prompts faster | Decomposing work better, reviewing faster |

You do not need multi-agent teams or expensive infrastructure to start. A single agent plus the practices in this guide gets you most of the benefit.

This week's practice run:

1. Pick a feature you've been putting off — something real, not a toy project
2. Write a CLAUDE.md (or equivalent) for your project: architecture, commands, conventions, constraints
3. Decompose the feature into 3-5 tasks. For each task, write one sentence of acceptance criteria
4. For the first task: write the test first, then hand it to the AI with the filled-in Architect Prompt Template
5. Verify the output passes the test before moving to task 2
6. Commit after each passing task

Do this once and you will feel the difference immediately. Not because the AI got smarter — because you got clearer.

The people who build the most interesting products in the next few years are not going to be the best coders. They are going to be the clearest thinkers. People who can define what they want with precision and direct AI to execute it.

Karpathy's original vibe coding post launched a generation of builders. His follow-up named what they need to become next. The gap between where you are and that level is closer than you think.

Vibe coding was the right way to start. Agentic engineering is what you build toward.

The skills are learnable. The habits are specific. The ceiling you've been hitting has a door in it — and now you have the blueprint to find it.

---

Resources

• Andrej Karpathy on X — original agentic engineering framing
• Morph: Agentic Engineering — The Post-Vibe-Coding Paradigm
• Stack Overflow Developer Survey 2025
• Simon Willison on AI-assisted development
• Anthropic: Agentic Coding Trends Report 2026
• Claude Code documentation — CLAUDE.md context files

---

Guide by vybecoding.ai — practical guides for builders navigating the AI-first development era.