A Plain-English Guide for Business Leaders
In December 2025, Andrej Karpathy — the engineer who co-founded OpenAI, ran AI at Tesla, and a year earlier had personally coined the term “vibe coding” — noticed something had changed. He kept asking the latest AI coding models for bigger chunks of work. They kept coming back correct. He couldn’t remember the last time he’d had to fix their output himself.
Four months later, at Sequoia Capital’s AI Ascent 2026 event, he said something that made the developer world sit up: he’d never felt more behind as a programmer in his career. Not because AI was replacing engineers, but because the discipline of working alongside it had quietly turned into a different job. He gave that job a name: agentic engineering.
If you’ve heard the term in a vendor pitch, a board deck, or your own engineering team’s Slack and you’re not sure whether it’s a real discipline, a rebrand of “vibe coding,” or just the AI industry’s newest buzzword, you’re not alone. This guide covers what agentic engineering actually means, where the term came from, how it differs from (and sometimes uncomfortably resembles) vibe coding, and what to ask before you bet production systems on it.
So, What Is Agentic Engineering?
Agentic engineering is the disciplined practice of directing AI coding agents to write and run code at scale, while a human engineer retains ownership of the architecture, the specification, and the verification of everything those agents produce. The “agentic” half means agents do most of the typing. The “engineering” half means a professional is still accountable for what ships.
Karpathy’s own framing splits cleanly along those same two words. “Agentic” describes an orchestration of agents writing code while a human developer oversees and validates the output, staying in the loop as the agent or multi-agent system works through each subtask. “Engineering” describes the expertise needed to use that workflow to produce real, working code without quietly trading away quality — a skill, in his framing, that can be built and improved like any other.
That second half is really the entire point of the term. Plenty of AI-assisted coding involves agents. Not all of it involves engineering discipline. Agentic engineering is the version that does.
Where Did the Term Come From?
The timeline matters here, because it explains why this term exists and why the industry is still settling on exactly what it covers.
Karpathy first coined “vibe coding” in a February 2025 post describing the experience of having a natural-language conversation with an AI and letting it build the application, without reviewing what it actually wrote. The phrase caught on fast, especially with non-engineers building their first prototypes. Simon Willison, the developer behind the Django web framework, drew an early line in the sand: if you carefully review and understand every line a model generates, you are not vibe coding. Vibe coding, in his original definition, specifically meant building software without reviewing the model’s output at all.
That line got blurry fast. By early 2026, Google engineer Addy Osmani was describing “vibe coding” as a suitcase term, stretched to cover everything from a weekend hackathon build to a fully disciplined, agent-driven professional workflow. Willison had already tried to name that disciplined end of the spectrum himself, proposing “vibe engineering” back in October 2025. It didn’t stick. As Osmani later put it, telling a CTO you’re “vibe engineering” their payment system tends to make them visibly nervous, no matter how rigorous the practice actually is behind the name.
Then came Karpathy’s December 2025 inflection point, and the name he chose for it. At Sequoia’s AI Ascent 2026 event, a year almost to the week after coining “vibe coding,” he told interviewer Stephanie Zhan he’d “never felt more behind as a programmer.” The term he introduced for what comes next — agentic engineering — resonated in a way “vibe engineering” hadn’t; developers half-jokingly started rebranding themselves “agent engineers” on social media within days. By late April 2026, IBM had published its own explainer on the term, treating it as established enough to need defining for an enterprise audience. That’s roughly where things stand today: a term barely six months old, already being formalized by enterprise vendors, with its own definition still being actively argued over by the people who use it daily.
FURTHER READING
➤ How AI Agents Are Changing Software Engineering Workflows
Agentic Engineering vs. Vibe Coding: What’s Actually Different?
| Vibe Coding | Agentic Engineering | |
| Term coined | Andrej Karpathy, February 2025 | Andrej Karpathy, named publicly in April 2026 (building on disciplined practices Simon Willison and others were already describing) |
| Core idea | Describe what you want in natural language and accept what the AI builds | Direct AI agents to write and execute code while you own the spec, architecture, and review |
| Code review | Minimal or none | Every meaningful change is checked against a quality bar you define |
Best suited for | Prototypes, hackathon builds, personal tools, learning projects | Production systems, customer-facing software, anything with real users or real consequences |
| The human’s role | Prompts, accepts or rejects, re-prompts | Architect, reviewer, and final decision-maker |
| What typically goes wrong | Bugs ship because nobody reviewed them | Bugs ship because review and governance didn’t scale with how fast agents produce output |
| Scales to the enterprise? | Not safely, on its own | Yes — when paired with the governance practices covered below |
The simplest way to hold the distinction in your head: vibe coding raises the floor, letting people build things they couldn’t have built before. Agentic engineering raises the ceiling, letting experienced engineers ship more without lowering the bar they’d otherwise hold themselves to.
One honest caveat worth knowing before you repeat this distinction in a planning meeting: even Willison, who helped popularize it, admitted in May 2026 that the line has started blurring in his own production work. As agents get more reliable, he’s stopped reviewing every line, even on work he ships professionally — “those things have started to blur for me already,” in his words. The two practices aren’t a clean binary so much as a spectrum, and where your team sits on it depends less on which tools you use and more on how much verification you’ve actually built into the process.
Why This Actually Matters for Your Business
This isn’t just a vocabulary debate for engineers. The gap between “using AI to write code” and “engineering with AI agents responsibly” is exactly where production incidents come from.
IBM’s explainer on the topic points to a revealing tension in Stack Overflow’s 2025 Developer Survey: 84% of developers already use or intend to use AI-assisted programming, yet 46% say they distrust the accuracy of what these tools produce, against only 33% who feel confident in the results. In other words, adoption has outrun trust. Most teams are already doing some version of AI-assisted coding. Far fewer have built the verification habits that would justify trusting it in production.
The clearest recent illustration of what happens when that gap goes unaddressed is Amazon’s. According to reporting on internal documents (originally surfaced by Business Insider), Amazon experienced a string of incidents starting in the third quarter of 2025, including a March 2026 outage in which its Q coding assistant was named as a contributing factor, and a follow-up incident days later that disrupted millions of customer orders. Dave Treadwell, Amazon’s SVP of e-commerce services, told staff the company was rolling out a 90-day “code safety reset” — mandatory two-person review for every change, formal documentation requirements, and leadership audits across its most critical systems. He described the goal as adding “controlled friction” to a process that had started moving faster than the company’s review practices could keep up with.
Amazon didn’t get hurt by using AI to write code. It got hurt by the review and governance around that code not scaling at the same pace the agents did. That’s the entire argument for treating agentic engineering as a discipline rather than just a faster way to type.
What Agentic Engineering Looks Like in Practice
Karpathy points to engineer Peter Steinberger as an example of what this looks like at the frontier: running dozens, sometimes upward of a hundred, agents in parallel, automating not just code generation but deployment sequences, bug detection, and pull-request management. The key detail isn’t the number of agents. It’s that Steinberger understands what each one is doing and can verify the output. He’s not outsourcing his understanding of the system. He’s outsourcing the execution of it.
Scaled down to a single engineer or a small team, the same discipline tends to show up as a few consistent habits:
- You own the spec, not just the syntax. Before any agent writes a line, someone defines what “correct” actually means for this piece of software — the requirements, the constraints, the edge cases that matter. Agents are very good at filling in implementation details once that’s clear, and much worse at guessing it for you.
- You verify; you don’t just hope. Every meaningful change gets checked against that definition of correct, whether through automated tests, structured code review, or both. The goal isn’t slowing agents down for its own sake — it’s making sure speed doesn’t quietly become a synonym for “unchecked.”
- You keep architectural decisions human. Agents are strong at producing working code within a structure you’ve defined. They’re far less reliable at deciding what that structure should be, especially where security, data handling, or long-term maintainability are on the line.
- You treat agent output as advice from a fast, occasionally wrong, junior colleague. Karpathy’s “jagged intelligence” point is the useful mental model here: today’s models can refactor a hundred-thousand-line codebase competently and still get a simple common-sense judgment wrong elsewhere. Knowing which kind of task you’re handing off changes how much you check it.
- You let the agents handle scale, not judgment. The honest pitch for agentic engineering isn’t that it removes engineering work. It’s that it removes the typing and lets one experienced engineer credibly direct work that used to require a much larger team — without quietly lowering what “production-ready” means.
Is Your Organization Ready for Agentic Engineering?
Before your team (or a partner) starts building production software this way, it’s worth answering four questions honestly:
- Does someone own the spec before agents start working? If “what we’re building” is defined loosely or changes mid-stream, agentic workflows amplify that ambiguity instead of resolving it.
- Do you have a real verification process, not just a vibe check? Automated tests, defined code review standards, and a clear quality bar are what separate agentic engineering from vibe coding at scale — not the tools you’ve licensed.
- Does your review process scale with how fast agents produce code? Amazon’s experience is the cautionary case here: the problem wasn’t using AI, it was a review process built for a slower era running headlong into one that wasn’t.
- Do you have someone senior enough to catch what the agents can’t? Karpathy’s point about jagged intelligence applies inside your organization too — you need a person who can tell the difference between an agent that’s reliably right and one that’s confidently wrong.
If you answered “not yet” to more than one of these, that’s not a reason to avoid agentic engineering. It’s a reason to build the governance alongside the adoption, rather than after an incident forces the issue.
Agentic Engineering FAQs
It’s the practice of directing AI coding agents to write and run code at scale while a human engineer owns the architecture, specification, and verification of the result.
No. Vibe coding means accepting AI-generated code with little or no review, which is fine for prototypes but risky for production. Agentic engineering keeps a human accountable for reviewing and directing that output, which is what makes it viable for systems other people depend on.
In most cases, your existing engineers are the right people. Karpathy and Willison both make the same point from different angles: these tools amplify existing engineering judgment rather than replace the need for it. Experience with architecture, security, and code review transfers directly; what’s new is mostly the workflow around directing agents.
It can be, when paired with the verification and governance practices above. Amazon’s 2026 incident is a useful example of what happens when AI-generated code moves faster than the review process built to catch its mistakes — the fix wasn’t abandoning AI-assisted coding, it was rebuilding the guardrails around it.
Low-code and no-code tools constrain what you build to a vendor’s pre-built components and platform. Agentic engineering uses general-purpose coding agents inside your own codebase and architecture, directed by an engineer, which makes it more flexible but also puts more of the responsibility for correctness back on your team.
They sit at different layers of the same problem. Agentic engineering is about how code gets written and reviewed. Platform engineering is about the infrastructure, tooling, and guardrails that let any engineering team, agent-assisted or not, ship safely and consistently. We’ll cover platform engineering in detail in an upcoming post — the two disciplines reinforce each other more than people expect.
The Bottom Line
Agentic engineering isn’t a rebrand of vibe coding, and it isn’t a guarantee that AI-written code is automatically safe to ship. It’s a name for something more specific: the set of habits — owning the spec, verifying the output, keeping architecture decisions human — that let experienced engineers use AI agents to do more without quietly lowering the bar for what “done” means.
That’s also, not coincidentally, the exact gap most companies are running into right now. Adoption of AI coding tools is already high. The discipline to use them responsibly at production scale is still catching up, one incident report at a time.
At Doshby, this is the work we do every day — building and shipping production software with AI agents in the loop, without treating “AI wrote it” as a substitute for “an engineer verified it.” If you’re trying to figure out whether your team is already doing agentic engineering or just fast, expensive vibe coding, let’s talk.
