Agentic engineering vs. vibe coding: what changes when the code goes to production
Published
Vibe coding is building software with an AI model without reviewing the code it writes: you describe what you want, accept the result and check only whether it seems to work. Agentic engineering also has coding agents write most of the code, but a person writes the specification, sets the limits, reads what goes to production and can explain it, with tests in place and every agent session logged. Vibe coding suits prototypes and personal tools. Agentic engineering is for software other people depend on.
Where the two terms come from
Andrej Karpathy coined "vibe coding" in a post on X on February 2, 2025, for a way of programming where you "forget that the code even exists." In the same post he wrote, "I 'Accept All' always, I don't read the diffs anymore," and he was clear about the scope: it was "not too bad for throwaway weekend projects."
About six weeks later, Simon Willison gave the term a narrower definition: "building software with an LLM without reviewing the code it writes." Applying it to every kind of code written with AI help, he argued, "gives a false impression of what's possible with responsible AI-assisted programming."
In October 2025, Willison suggested "vibe engineering," only partly in jest, for the other end of the spectrum: experienced developers who use AI to go faster "while staying proudly and confidently accountable for the software they produce." On February 4, 2026, Karpathy looked back on his original post. At the time, he wrote, you would mostly use vibe coding "for fun throwaway projects, demos and explorations." A year later, programming via LLM agents "is increasingly becoming a default workflow for professionals, except with more oversight and scrutiny." Many people had tried to come up with a better name for that version, and his "current favorite" was "agentic engineering." Later that month, Willison added a note to his October post: "Agentic Engineering" looked like it was "coming out on top."
Side by side
| Vibe coding | Agentic engineering | |
|---|---|---|
| Who writes the code | An AI model, from conversational requests | Coding agents, from a written specification |
| Who reads it | Nobody, by definition | A person who answers for the result, before it reaches production |
| How you know it works | It seems to work when you try it | Automated tests, plus manual checks of the edge cases |
| What is left afterward | The code | The code, the tests, the specification and a record of each agent session |
| Cost of a mistake | Low, by choice | Real: customers, money, regulated data |
| Who maintains it | Usually the person who built it, by prompting again | The team, because someone has read every change and can explain it |
| Where it fits | Prototypes, demos, spikes, personal tools | Systems in production, legacy modernization, anything other people rely on |
The table describes scope. Both use the same kind of tools; what changes is how much checking surrounds them.
Vibe coding for the right job
Willison defends vibe coding for the right projects. "For low stakes projects and prototypes," he asks, "why not just let it rip?" By March 2025 he had published more than 80 experiments built that way. His checklist for when it is OK starts with the stakes: think about how much harm the code could cause if it has bugs. He also asks for care with secrets such as passwords and API keys, with private data, and with anything billed by usage, where a feature built without a billing limit can run up thousands of dollars in charges.
Inside a company, that leaves room for a clickable mock-up for stakeholders, a one-off script or a spike to see whether an idea holds up. Our reading: a prototype built this way is most useful as a specification for what gets built next.
What production software needs
Software that customers, auditors or other teams depend on needs three things that vibe coding, by definition, leaves out.
Review: a person reads what goes to production. Willison's golden rule for production work is that he won't commit any code to his repository "if I couldn't explain exactly what it does to somebody else." In a company, that person is also the one who answers for the change. A coding agent cannot carry that responsibility, so someone on the team has to.
Tests: an agent saying "it works" is not evidence. In his October post, Willison warns that without tests, "your agent might claim something works without having actually tested it at all," and any new change "could break an unrelated feature without you realizing it." On an existing system, the first tests to write are the ones that pin down what the system does today, known as characterization tests, before anything is replaced.
A record of what the agent did. A diff shows the result, not how the agent got there. Willison notes that being able to "understand when and how something was changed is even more important when a coding agent might have made the changes." A session record goes a step further than version control: it keeps the request, the steps, the model, the cost, the result and the authorship of each session, including work that never became a commit. More in Observability for coding agents.
Where this sits on the levels of AI coding autonomy
Dan Shapiro's scale, from level 0 to level 5, measures how much of the work of programming moves from a person to AI. It has no slot for vibe coding. Our reading: vibe coding shares one trait with level 5, the dark factory: nobody reads the code. Willison talked to one team that works at level 5 by design, and in that team "a huge amount of the coding agent work goes into testing and tooling and simulating related systems." Vibe coding, as Karpathy and Willison describe it, is a lighter practice meant for projects where little is at stake.
In our mapping, agentic engineering covers levels 3 and 4. At level 3, in Shapiro's description, the person spends the day reviewing diffs. At level 4, the person writes and argues over the specification and comes back later to see whether the tests pass; the post's illustration has the human trusting the system's self-checks and checking the final results much later. Ithaca operates its agentic development platform at level 4 with a rule of its own: coding agents execute, people on the team read what goes to production, and every session is logged, with its authorship. Reading before production is Ithaca's rule, not part of Shapiro's definition. The full scale is in Levels of AI coding autonomy.
When to use which
Vibe coding is a reasonable choice when the code will be thrown away or only you will use it, it holds no secrets or private data, nothing it calls is billed by usage, and a failure would cost you an afternoon.
Agentic engineering is the choice when other people depend on the software, it touches customer data, payments, health records or audits, someone else will have to maintain it, or the code is already running in production.
Taking a prototype to production. Use the prototype as the specification for the production version:
- Write down what it does: the screens, the rules, the edge cases you found by trying it.
- Turn that behavior into tests.
- Build or rework it with coding agents under review, with a person reading every change that goes to production.
- Log every agent session from the start.
The platform in practice: Dr. Consulta
Dr. Consulta modernized its subscription system, which had been in production for eight years, using the agentic development platform, with its own team supervising. Compared with the period before the modernization, infrastructure cost is 75% lower, and one representative feature went from about two weeks to up to three days. That feature is an example, not a measurement of the whole backlog. Read the Dr. Consulta case study
Frequently asked questions
What is the difference between vibe coding and agentic engineering?
In both, AI writes most of the code. In vibe coding, nobody reviews it: you accept the result if it seems to work. In agentic engineering, a person writes the specification, reads what goes to production and can explain it, with tests in place and every agent session logged.
Is vibe coding bad?
No. Simon Willison, whose definition this page uses, recommends it for low-stakes projects and prototypes. The risk starts when vibe-coded software holds secrets or private data, costs money when it misbehaves, or is used by other people without anyone having read it.
Can a vibe-coded prototype go to production?
Not as it is. Use it as a specification: write down what it does, turn that behavior into tests, then rebuild or rework it with a person reading every change that goes to production and every agent session logged.
Where does agentic engineering sit on the levels of AI coding autonomy?
In our mapping onto Dan Shapiro's scale, it covers levels 3 and 4: at level 3 the person reviews the code the AI writes; at level 4 the person writes the specification and checks the results later. Ithaca operates at level 4 with its own rule: people on the team read what goes to production, and every session is logged.
Book a demo
See the agentic development platform working at level 4, the way it runs alongside your team: coding agents execute, your team supervises and reads what goes to production, and every session is logged, with its authorship.
Sources
- Andrej Karpathy, post on X, February 2, 2025. The original "vibe coding" post.
- Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)," March 19, 2025. The definition, the golden rule and when vibe coding is OK.
- Simon Willison, "Vibe engineering," October 7, 2025, updated February 23, 2026. The other end of the spectrum: tests, version control and code review.
- Dan Shapiro, "The Five Levels: from Spicy Autocomplete to the Dark Factory," January 23, 2026. The scale and the description of levels 3, 4 and 5.
- Simon Willison, "The Five Levels: from Spicy Autocomplete to the Dark Factory," January 28, 2026. The traits of a team working at level 5.
- Andrej Karpathy, post on X, February 4, 2026. A year later: "more oversight and scrutiny" and "agentic engineering" as his current favorite name.
