Vibe Coding vs Agentic Engineering: How AI Is Changing Software Development

Vibe coding vs agentic engineering comes down to one question: who owns the quality bar when AI writes the code? Vibe coding means you prompt, accept, and run. Agentic engineering means you spec, supervise, review, and verify before anything ships.

Andrej Karpathy coined vibe coding in February 2025. A year later, at Sequoia AI Ascent 2026, he drew the line again: vibe coding raises the floor. Agentic engineering preserves the professional quality bar. Simon Willison adds a useful test: if you reviewed, tested, and can explain every line, that is not vibe coding. That is software development with an LLM as a typing assistant.

---

What is vibe coding?

Vibe coding is building software by describing what you want and letting the model decide most of the implementation.

Karpathy's original post is blunt. He accepts all diffs. He pastes error messages back with no comment. He works around bugs he cannot fix. He said it plainly: forget that the code even exists.

That workflow looks like this:

Describe what you want
        ↓
AI generates the code
        ↓
Run it
        ↓
Paste errors back
        ↓
Repeat until it "works"

MIT Technology Review notes the key detail. Not all AI-assisted coding is vibe coding. You must be willing to skip review and surrender control to the model.

Vibe coding shines for:

• weekend prototypes
• UI experiments
• proof-of-concepts
• internal throwaway tools
• learning what models can do

The speed is real. The risk shows up when the demo gets users, money, or a maintenance timeline.

---

What is agentic engineering?

Agentic engineering is the disciplined way to build production software with AI agents under human ownership.

Karpathy frames it at Sequoia: you coordinate fallible, stochastic agents without dropping security, taste, or maintainability. IBM's definition matches: human engineers orchestrate agents, break work into tasks, supply context, and validate output.

This is not the same as agentic coding. Agentic coding is the execution loop: plan, edit files, run tests, retry. Agentic engineering is the full practice around that loop: specs, architecture, review gates, and accountability.

The core rule:

The engineer owns the decisions. AI accelerates the execution.

A typical agentic engineering workflow:

Engineer defines the goal and constraints
        ↓
AI structures requirements and flags gaps
        ↓
Engineer fills missing context
        ↓
AI drafts an implementation plan
        ↓
Engineer reviews and challenges the plan
        ↓
AI implements inside approved boundaries
        ↓
Engineer verifies tests, diffs, and behavior

Responsibility stays with you. Speed comes from agents doing mechanical work at scale.

---

Vibe coding vs agentic engineering: side by side

Neither label is a moral verdict. Vibe coding is a valid mode for low-stakes work. Agentic engineering is what you need when other people depend on the software.

---

The 90% problem with AI-generated code

The 90% trap. AI can produce most of a feature in hours. The last stretch can eat days or weeks.

You get components, APIs, auth flows, and tests fast. Then you hit:

• hidden dependencies
• duplicated logic
• edge cases the prompt never named
• regressions in unrelated modules
• business rules that conflict quietly

The model is not always wrong line by line. It often lacks the context you never wrote down: past trade-offs, future requirements, and why an abstraction exists.

A codebase is more than visible files. It holds business decisions, historical constraints, and implicit assumptions. When those live only in chat history, AI makes locally reasonable choices that fail globally.

Practical rule. Let AI blast through the first 90%. Switch to verification mode for the last 10%. That is where production lives.

---

The AI coding knowledge gap

Knowledge gap risk. You can merge thousands of AI-generated lines and still not explain how the system works.

Someone asks: "How does checkout work?" You open the file for the first time with them on the call.

Someone asks: "Why this database shape?" The honest answer is: "The model suggested it."

That is an engineering failure, not an AI failure. Generated code is fine. Unowned code is not.

Watch for code that:

• nobody intentionally designed
• nobody can explain
• nobody knows what depends on it
• nobody wants to touch

That debt compounds. Every future change gets slower and scarier.

Agentic engineering closes the gap with review, docs, and tests before merge. You should be able to explain any module you ship.

---

Who owns the architecture in AI-assisted development?

AI should not own your architecture. You should.

Give agents explicit boundaries:

• database schemas and data models
• API contracts and interfaces
• folder structure and module rules
• state management patterns
• coding conventions and dependency limits
• security and compliance constraints

Agents can propose alternatives. They can flag risks. They can suggest refactors.

You make the final call.

AI can propose. The engineer decides.

The most dangerous habit I see: the model offers three options. You ask, "Which do you recommend?" You pick its answer without understanding trade-offs.

That feels fast. It quietly moves architecture, libraries, and error handling out of your hands. You become an approver, not an engineer.

---

How to give AI persistent project context

Prompt memory is fragile. Project knowledge should live in the repo.

I keep a docs/ tree agents can read on every run:

docs/
├── architecture.md
├── product-requirements.md
├── technical-requirements.md
├── database.md
├── api-contracts.md
├── coding-standards.md
└── decisions/
    ├── authentication.md
    ├── state-management.md
    └── payment-architecture.md

When a decision changes, update the doc. Agents get the same source of truth your team would use.

This beats re-explaining auth rules in every session. For the agent loop itself, see what is agentic coding.

---

A debugging workflow that keeps you in control

Weak debugging with AI:

"There is a bug. Fix it."

Strong debugging starts with your understanding.

Step 1: Name the bug

Write down:

• what happens now
• what should happen
• when it happens
• how to reproduce it
• whether it is deterministic

Step 2: Map the blast radius

List affected modules, files, APIs, database calls, and state.

Step 3: State expected behavior

Give the agent a precise spec of correct behavior. Not vibes. Facts.

Step 4: Ask for a plan first

Let the agent reason about changes before it edits anything.

Step 5: Challenge the plan

Ask:

• Does this change architecture?
• Could this regress elsewhere?
• Is there a simpler fix?
• Does this break an existing abstraction?
• What edge cases remain?

Step 6: Implement inside the approved plan

Only now let the agent write code.

Step 7: Verify against the original bug

Run the reproduction steps. Confirm the plan's acceptance criteria.

---

How to ship new features with agentic engineering

"Build feature X" is not a spec. Start with understanding.

Understand the feature and user outcome
        ↓
Define expected behavior and edge cases
        ↓
Identify affected modules and files
        ↓
List constraints (security, perf, data)
        ↓
Create an implementation plan
        ↓
Review and challenge the plan
        ↓
Approve boundaries
        ↓
Let agents implement
        ↓
Verify behavior and tests

Implementation should be the output of reasoning. Not a substitute for it.

---

When vibe coding is the right tool

Use vibe coding when:

• stakes are low and the audience is you
• speed matters more than maintainability
• you are exploring whether an idea can work at all
• the code may be deleted next week

Karpathy scoped it that way from day one: throwaway weekend projects. Simon Willison uses it for experiments and prototypes too.

The trap is the good demo. A prototype that works often gets pushed toward production without a rewrite. Plan the handoff before you vibe-code your way into a liability.

---

When agentic engineering is required

Switch to agentic engineering when:

• real users depend on uptime
• money, health, or regulated data is involved
• a team must maintain the code without you
• security and audit trails matter
• the codebase will live longer than one sprint

That covers most client work and most products worth your name. It matches how I ship Astra Chat, MatesLive, and fintech features where mistakes are expensive.

Veracode's 2025 GenAI Code Security Report tested 100 LLMs on 80 coding tasks. Insecure code showed up in 45% of cases (Veracode, 2025). You cannot catch that by vibes. You catch it with review, static analysis, and tests.

---

Is vibe coding bad for production?

Not automatically. Using AI in production is normal now.

Vibe coding in production is the problem: accepting output you cannot explain, test, or defend.

Production needs definition of done, not "it ran once on my machine." Braingrid's framing is useful: in vibe coding, the model owns done. In agentic engineering, you own done, and agents prove they met your bar.

---

How do you learn software engineering with AI?

Build. Then inspect what you built.

Use AI to implement faster than you could alone. Then ask:

• Why this architecture?
• Why this abstraction?
• What breaks at scale?
• What happens when this fails?
• Could I explain this to another engineer?

That loop compounds skill:

Build with AI
      ↓
Inspect the diff
      ↓
Reason about trade-offs
      ↓
Question assumptions
      ↓
Learn
      ↓
Build again with tighter specs

AI amplifies ability. It does not replace judgment. The engineers who win combine deep technical knowledge with fast agent execution.

---

Conclusion

AI can write the code. That part is settled.

The open questions are harder:

• Do you understand what shipped?
• Do you still control the architecture?
• Can you explain the decisions behind the system?

Vibe coding vs agentic engineering is how I answer those before every production merge. Vibe when the stakes are low. Engineer when people depend on the result.

Use AI to move faster. Use your engineering knowledge to decide where to go.

Never trade speed for loss of control.