The Human-in-the-Loop’s Clear Path: Move Beyond 'Vibe Coding' to 'Agentic Engineering'

• By Howard M. Cohen
• 05/15/2026

Remember when you first experienced describing a software feature in plain English and watching your AI assistant just... build it? That rush. That disbelief. That feeling of "I can make anything now."

That was vibe coding. And it was real. And it was wonderful.

It was also, as it turns out, the party before the real work began.

The Orgins of "Vibe Coding
In February 2025, Andrej Karpathy, co-founder of OpenAI and former head of AI at Tesla, fired off what he himself later called a "shower of thoughts throwaway" tweet. He named the experience everyone was having vibe coding. You tune in to your own "vibes," let the AI generate, embrace the chaos, and forget the code even exists. It went viral because it captured the excitement of what everyone was doing.

A mere 13 months later, Karpathy himself stood before founders at Sequoia's AI Ascent 2026 conference and declared the vibe coding era over. Done. Finished. Kaput.

The New, Improved Professional-Grade Experience
With developers and others wondering whether AI might threaten their careers, Karpathy offered a more constructive frame: the next stage would not end software work, but reshape it around a new discipline he called agentic engineering.

Vibe coding raises the floor for everyone in terms of what they can build. But agentic engineering is about preserving the quality bar of professional software. That's the distinction Karpathy drew in a post on his personal blog. One expands access; the other maintains standards.

And that difference matters enormously to anyone building real things with AI tools today.

What Was Wrong with Vibe Coding?
Nothing went catastrophically wrong, which is almost the problem. The code worked. Features appeared. Apps launched. So, everyone just kept going. We kept prompting, iterating, patching in the same chat window, never writing anything down, never thinking through the architecture, never asking why a particular decision got made. As the Sundance Kid said to Butch Cassidy in the 1969 film, "Will you just let me move?”

Then the context window ran out. Or a new AI model arrived that didn't know what the old one had decided. Or a second developer touched the same codebase and had no idea what was going on. Or you came back to your own project three months later and couldn't explain it to yourself. The kinds of things one should expect when everything is being done in an informal “vibe” kind of way.

The main obvious drawbacks are the lack of best practices and shared conventions, as product analytics expert Mariya Mansurova pointed out on her must-read blog. Teams, she wrote, end up with five different approaches to the same problem inside a single codebase. Decisions evaporate because they only lived in a chat session that’s probably irretrievable. The AI agent starts from scratch every time you open a new conversation. No continuity. Much repetition of effort and token consumption.

Boris Cherny, creator of Claude Code at Anthropic, put the responsibility directly on us during an interview with Lauren Reeder at the Sequoia AI Ascent 2026 event. The job now is to build for the user, she said, then build for the model. That's a subtle but important reorientation. The model can write the code. What it can't do is know what you actually want to build, and why, and what trade-offs matter.

That part is still yours.

Defining Agentic Engineering
If you're looking for an exact definition of "agentic engineering," you could do worse than Karpathy's own definition:

"'Agentic' means an orchestration of agents writes the code, and the human developer oversees and validates the output. 'Engineering' emphasizes that there is a level of expertise required to use agentic workflows for meaningful code production that does not jeopardize the code quality. This skill is one that can be developed and improved."

That word, "engineering," is doing a lot of work here. I believe it's meant to be a deliberate signal that this is a discipline with rigor. Professional-grade rigor, in fact. There's a wrong way to do it, and there's a better way, and the better way can be learned.

The unit of programming changed from typing lines of code to delegating larger macro actions: implement this feature, refactor this subsystem, research this library, set up this service, write tests, run them, fix failures. You're not the coder anymore. You're the director, which means you need to know enough to direct well.

And that really defines the future for software professionals. The gritty coding work is vanishing, emphasizing the importance and value of the deeper architectural acumen and design/engineering expertise.

Spec-Driven Development: Engineering’s Best Best Practice
So, what does "better" actually look like in practice?

Actually, it looks rather familiar to anyone who has ever spent time developing or participating in software development. Once discovery is complete, the next best practice is to create a functional specification document.

Mansurova recently documented her attempt to build a personal fitness tracking app using what's called spec-driven development (SDD). She built a working, deployable application in about 4.5 hours. Not by vibe-coding her way through it, but by starting with structure.

The key difference: before any agent writes a single line of code, you write the functional spec. A mission document explaining why you're building this and what it needs to do. A tech-stack document capturing the core decisions. And a roadmap breaking the work into phases. Taken together, these form what Mansurova calls the "constitution," the governing document that every agent references and every human can read.

This creates an important shift: we decouple the specification describing what we are building and why from the implementation, which is the actual code.

That decoupling solves the biggest failure modes that came from “vibe coding” all at once. Context decay, because the spec travels with the project across sessions and agents, and inconsistent decisions, because everything gets resolved in the spec before code gets written. Loss of reasoning, because the document records why, not just what uses a similar principle in how he runs Claude Code.

Karpathy starts in Plan Mode, iterates until the plan is good, then switches into auto-accept edits mode, letting Claude execute the entire implementation in one go without needing back-and-forth iterative revisions. This prevents the classic failure where an agent makes forty changes you didn't want because it was filling in blanks you left open.

The New Job for the Human-in-the-Loop
Here's what Karpathy said when asked how you'd tell the difference between a mediocre AI-assisted developer and a fully AI-native one: It's about getting the most out of the tools available, investing in your own setup, and knowing how to direct the work effectively.

The value shifts upward, from syntax and implementation toward judgment, taste, and oversight.

That's the key human-in-the-loop role in agentic engineering. Not babysitting every line of code. Not second-guessing every function name. But making overarching architectural decisions, reviewing the outputs that matter most, catching conceptual errors before they compound, and knowing when to trust the agent and when to stop it in its tracks.

Mansurova's account of her process is worth noting here. She catches herself instinctively explaining problems to the agent and asking for fixes, rather than updating the spec first. Keeping the functional specification as the source of truth is what makes the approach robust. The moment you start picking and patching around it, you're back at vibe coding.

Why This Matters for Citizen Developers
If you're a citizen developer, someone building tools for your own work, your team, or your organization without a traditional development background, this shift is actually tremendously good news. You were already doing the most important part. You know what you need to build. You understand the problem. You can define the requirements. What spec-driven development asks of you is to slow down enough to simply write that knowledge down before you hand it to the agent.

Karpathy predicted a split in the industry: some engineers will miss coding, while others will focus on building products. Citizen developers were never attached to coding. They were always in it for the product. That puts them exactly where agentic engineering needs them to be.

The vibe coding era proved that anyone could build. The agentic engineering era asks you to build well.

Those aren't the same thing, of course. The tools are good enough now that the difference among them is almost entirely up to you. For many observers, agentic engineering is the key role in the AI future.