From vibe coding to agentic engineering

Vibe coding made one layer of engineering faster. Six layers became more important. Here is what we are building to close the gap.

I run deep code reviews across my team regularly. In one of those reviews, I went through pull requests from multiple engineers, hundreds of files, every one of them AI-assisted. Tests passed. Linting was green. The work looked finished from the outside. I scored every PR across seven dimensions: security, performance, simplicity, correctness, architecture, spec quality, and maintainability. Architecture scored well. Security was strong. Correctness lagged behind everything else.

That gap tells you everything about where we are right now in AI-assisted development. The code compiles. The patterns are consistent. But when I ask, does this actually solve the right problem, the answer gets uncertain. The code is correct at the function level and ambiguous at the intent level. I kept finding implementations that did exactly what the prompt described and missed what the user needed. Because I had not given the engineers enough clarity on what the intent was before they started prompting.

That review changed how I think about what is happening in our industry. The shift from vibe coding to what Andrej Karpathy calls agentic engineering is a story about what you build around the tools. And most teams, including mine, are still figuring that out.

One layer got faster, six became more important

When Karpathy spoke at Sequoia’s AI Ascent 2026, he made the most useful distinction I have seen this year. Vibe coding raises the floor. It lets almost anyone build software by describing what they want. Agentic engineering raises the ceiling. It is the professional discipline of coordinating fallible agents while preserving correctness, security, taste, and maintainability. He used the word engineering on purpose.

Worth noting: the people who build the most impressive things with vibe coding are almost always experienced engineers and founders. They already understand the problem, already have the solution in their head, already know what good looks like. Vibe coding works for them because the layers above and below the code already exist in their experience. They are not vibe coding from nothing. They are vibe coding from decades of knowing what to build and why. The tool accelerated the typing. The thinking was already done.

I have been thinking about this through what I call the seven layers of engineering. When machines write the code, the work decomposes into layers that most teams never had to separate before.

Design as intent: what are we building, for whom, and why.
Spec as contract: inputs, outputs, edge cases, constraints.
Architecture as constraint: boundaries, responsibilities, dependencies.
Code as proof: implementation that proves the design can work.
Tests as guarantee: evidence that the proof holds under real conditions.
Review as ownership: human judgment that checks whether intent survived implementation.
Context as memory: the record of why decisions were made.

Layer 4, code as proof, got faster. AI made code generation nearly free. But layers 1 through 3 and 5 through 7 became more important, because when the code writes itself, the engineering moves to everything around the code.

The industry is catching up to this. The evolution from prompt engineering to context engineering to what Martin Fowler’s team at Thoughtworks calls harness engineering reflects the same progression. The discipline keeps moving further from the typing and closer to the thinking.

I wrote in Nobody Remembers Why about engineering teams forgetting at three levels simultaneously. The seven layers are the answer to what they need to remember. When a team only operates at Layer 4, prompting and accepting output, it produces code with no design intent, no spec, no architecture rationale, no ownership, no memory. That is vibe coding. When a team operates across all seven layers and uses AI to accelerate Layer 4 within boundaries set by the other six, that is agentic engineering.

The teams that see this early are the ones building the layers. The rest are still optimizing for keystrokes.

What we are actually building around the tools

Here is what we are doing, what is working, and where we are still getting it wrong.

We started requiring a written spec before implementation for any non-trivial change. Workflows, new domain aggregates, cross-module integrations, and schema changes. The spec takes 30 to 60 minutes. A reviewer walks through it with the author in about 15 minutes. That 15-minute conversation consistently catches design issues that would cost hours to find in code review. The pattern held every time we checked: PRs with specs had fewer edge case bugs, cleaner boundaries, and reviewers who could verify intent instead of guessing at it. PRs without specs turned review into archaeology, reverse-engineering what the engineer was trying to build. The spec is the product. It is what exists before the first prompt, and it is what makes the agent’s output verifiable instead of plausible.

Here’s the thing about reviews. Every PR now goes through four layers before merging. First, CI: syntax, types, lint, format. Automated, no human time. Second, AI review: pattern compliance, cross-file consistency, standard enforcement, plus what Karpathy identifies as the four failure modes of AI agents: silent assumptions, overcomplication, unauthorized edits, and weak success criteria. Third, human review: business intent, architecture decisions, scope assessment. Fourth, product review: user impact, microcopy quality, workflow correctness.

AI owns the first two layers. Humans own the second two. Human reviewers were spending time on issues that AI catches reliably and without fatigue: barrel export bugs, missing test updates, and i18n sync problems. Meanwhile, AI was attempting business intent and UX judgment, where it lacks the context to be accurate. Give AI everything, and it gives noise. Give it a specific layer, and it gives a signal.

We also run a two-minute pre-review scan on every PR for four AI-specific failure modes: code that solves a different problem than the spec, more complexity than the task requires, unrelated changes bundled in, and vague success criteria with no acceptance tests. This scan catches issues in roughly a third of PRs. The highest-value gate we have. It prevents hours of wasted review on PRs that need restructuring before they are reviewed.

The AI did not get better between the good PRs and the weak ones. The input did. Clear input makes review verification. Vague input makes review archaeology.

The shift most teams have not made yet

I think about AI coding maturity in six levels.

Level 0: You judge AI by whether it writes code you would write.
Level 1: AI assists your coding. You are still the brain.
Level 2: AI writes code you review. Prompt, generate, fix, repeat.
Level 3: AI follows your instructions. Step-by-step scaffolding. You specify HOW.
Level 4: AI solves your problem. You specify WHAT and WHY. AI figures out HOW.
Level 5: AI reasons about the system. You give context, constraints, and identity. AI makes decisions. You validate outcomes.

Most teams are stuck at Level 2 or 3. They have the tooling for Level 4. They do not have the mindset. The jump from Level 3 to Level 4 is the hardest because it requires trusting the model to think. Writing success criteria instead of execution steps. Giving up control of HOW.

At Level 5, I have been experimenting with giving AI the system’s identity alongside the problem. Architecture principles, design values, code character, the patterns we use and the patterns we avoid. When I give an agent our architecture doc, our ADRs, and our coding standards alongside a task, the output changes. It stops generating code for the system and starts reasoning as the system. That is the ceiling Karpathy is talking about. Reaching it requires all seven layers to be documented, maintained, and fed to the agents as context.

I wrote in Your Team Ships Faster with AI but Your Systems Don’t about teams measuring the gain at the engineer level and missing the cost at the system level. The six levels clarify where the cost comes from. At Level 2 and 3, the engineer controls the typing, but AI controls the thinking. At Level 4 and above, the engineer controls the thinking, and AI controls the typing. That inversion is the shift. It requires that the thinking actually exists somewhere that the agent can access it.

At Level 2 and 3, the engineer controls the typing but AI controls the thinking. At Level 4 and above, the engineer controls the thinking and AI controls the typing. That inversion is the shift.

What does this change about engineering roles

My own role changed this year. Less time reviewing code. More time reviewing the inputs that shape the code. Are the specs clear enough that an agent can follow them? Are the review layers catching what they should? Is the team building mental models of the system, or just prompting and accepting output?

Some of my engineers pushed back. They want a BA to analyze requirements, translate them into clean PRDs and user stories, hand the spec to developers, then pass the output to QA. Analyst writes. Developer codes. QA validates. Clean handoffs, clear boundaries.

That model is disappearing. The industry is moving toward what companies like OpenAI, Anthropic, and Google call forward-deployed engineers, people who sit inside the problem, work with customers and users, own the spec, the implementation, and the outcome end-to-end. AI made the coding fast. What remains is the understanding, and the understanding cannot be handed off.

This is uncomfortable. More time writing specs, more time talking to users, more time in the layers above and below the code. Less time typing. More energy thinking. Some of my team sees this as extra work. I see it as the actual work, always there but hidden behind handoffs between roles.

What this shift means depends on where you sit.

If you are a software engineer, your job is no longer writing code. Your job is owning outcomes. Understanding the problem before prompting. Writing specs that define what done looks like. Reviewing AI output against intent. Being able to explain why this approach was chosen. The six layers above and below the code are now your primary work. Code is the easy part.

If you are a founder or someone using AI to build software, understand why it works when it works. If you lack domain context, AI will generate something that looks right and solves the wrong problem. The risks go beyond functionality. AI-generated code regularly introduces security vulnerabilities, exposes user data, mishandles authentication, creates attack surfaces that a non-technical founder would never notice. You ship it because the demo works. The breach happens when someone finds the hole the model left open. Your advantage is your understanding of the problem. Write it down. That is your spec. For everything you do not understand, especially security and data handling, get someone who does to review it before it reaches users.

If you are an engineering manager or CTO, code review has changed. When I review PRs now, I score across seven dimensions: security, correctness, simplicity, performance, architecture, spec quality, and maintainability. What I am really measuring is engineering mindset. Does this engineer understand why they built it this way? Do they own the trade-off? Did intent survive implementation? Review is where you see whether your team is engineering or just prompting. It is where ownership becomes visible.

The future of software development is not learning how to write better code. It is learning how to write better specs and better rules, so the right thing gets built in the right way. The teams making the transition from vibe coding to agentic engineering are the ones who understand this. Specs, review layers, context documentation, and ownership culture. The foundation that makes agent output trustworthy instead of plausible.

Foundation first. Always. The tools changed. The requirement did not. It just became visible.

When your team prompts an agent tomorrow morning, how many of those seven layers will exist before the first prompt? And which layers are you still building?