Vibe coding vs agentic engineering: meaning, history and what comes next

Two ways to build with AI—and why the distinction matters

Imagine describing a booking app and watching a usable interface appear. You ask for a calendar, change the colors, try a reservation and adjust what feels wrong. That experience can turn a vague idea into something you can discuss with a customer. It is also a very different achievement from operating a booking service that prevents double reservations, protects customer details and recovers when a payment fails.

Vibe coding and agentic engineering help name those different kinds of work. Their boundaries are still debated, and neither term is a certification or a universally standardized method. This article uses their narrower meanings so that the distinction remains useful. In everyday marketing, vibe coding also serves as a much broader label for almost any software built with AI.

For a founder, the distinction affects what to trust before launching. For a developer, it changes how to divide attention between implementation and verification. For someone choosing an app, it encourages a better question than “Was this made with AI?”: what evidence shows that it solves my problem reliably?

What does vibe coding mean?

Andrej Karpathy introduced the phrase in a post dated 2 February 2025. He described an informal process of giving natural-language instructions, accepting generated changes without reading the diffs, and feeding errors back to the model. His example concerned disposable weekend projects, rather than a prescription for operating every kind of software.

The defining feature was the builder’s relationship to the implementation: attention stayed on what the application did, with limited attention to how its code worked. A person could steer by appearance, behavior and conversational feedback instead of understanding each change. That makes vibe coding a style of exploration, not a particular programming language or brand of tool.

Usage broadened quickly. Simon Willison argued in March 2025 that reviewing, testing and understanding AI-generated code should still be called software development. The distinction matters because someone saying “I vibe coded this” might mean a playful experiment, a carefully reviewed product, or anything between them. Ask about the process behind the label.

Sources: Andrej Karpathy’s original vibe coding post, 2 February 2025 (transcript) · Simon Willison: Not all AI-assisted programming is vibe coding, March 2025

What does agentic engineering mean?

Agentic engineering is software engineering carried out with agents that can perform sequences of development work. Instead of only suggesting a function, an agent may inspect a repository, edit files, run commands, read failures and revise its implementation. Simon Willison’s February 2026 description emphasizes this ability to generate and execute code, and to iterate without human instructions for every individual step.

In this article, the engineering part means that somebody remains responsible for the requirements and evidence. The builder defines a useful outcome, gives the agent appropriate access, checks important assumptions and decides whether the result is ready. Autonomy is delegated within boundaries; accountability for the service does not disappear.

That responsibility need not mean a human types every line or personally watches every command. It means there is a defensible route from a request to a working, maintainable result. A solo founder can adopt this discipline. A large development team can neglect it. Job titles and team size do not determine the quality of the process.

Sources: Simon Willison: Writing about Agentic Engineering Patterns, February 2026

The key differences, side by side

The following comparison is Wantlist’s working framework, not an industry grading system. It describes tendencies at two ends of a spectrum. An exploratory prototype can include good tests, and a disciplined project can still use quick visual experiments.

A short history: from assistance to delegated work

The ambition to make programming more accessible predates modern AI. Higher-level languages, libraries, visual tools and low-code systems all reduced the amount of detail a builder had to manage directly. Language models introduced a different interface: people could describe an intention in ordinary language and receive a proposed implementation.

In June 2021, GitHub launched the technical preview of Copilot. Its announcement described suggestions for whole lines and functions based on the code being edited. This is a useful milestone for the assistant model: the developer remained in the editor, choosing what to accept and how to assemble it.

In March 2023, GitHub’s Copilot X announcement described bringing conversational assistance into the editor and other parts of development. Instead of only accepting a completion, developers could ask about code, errors and documentation. This conversational layer helped establish the habit of explaining an intention and discussing a proposed solution.

By December 2024, Anthropic was publishing patterns for systems that combined language models with tools and feedback. The distinction between a predetermined workflow and an agent choosing its next steps was already explicit. The underlying idea of agentic development therefore predates the popular vibe coding label.

February 2025 supplied the memorable phrase. Karpathy’s post captured the experience of letting a conversational system do much of the implementation while the builder followed the result. Its appeal came partly from making software creation feel approachable to people who would not start by opening a programming textbook.

That same month, Anthropic introduced Claude Code as a limited research preview for delegated coding work in the terminal. It provides a concrete example of the shift from discussing code to giving a tool the ability to act on a development environment. The label and the executable tools were developing alongside each other.

By February 2026, practitioners such as Willison were organizing agentic engineering into documented patterns. The conversation increasingly concerned how to supervise executable work, preserve understanding and evaluate results. This is a history of changing emphasis, not a clean replacement: autocomplete, chat, visual builders and coding agents continue to coexist.

Sources: GitHub: Introducing GitHub Copilot, June 2021 · GitHub: Copilot X and conversational development, March 2023 · Anthropic: Building effective agents, December 2024 · Andrej Karpathy’s original vibe coding post, 2 February 2025 (transcript) · Anthropic: Claude Code research preview, February 2025 · Simon Willison: Writing about Agentic Engineering Patterns, February 2026

A model, an agent and a workflow are different things

A language model produces outputs from its inputs. A coding agent adds an environment, tools and a loop: inspect something, choose an action, execute it, observe the result and continue. The surrounding software determines which files and services are available, what permissions apply and when the work must stop.

A workflow can instead prescribe the sequence: generate a patch, run a test command and send the result for review. Anthropic’s architectural distinction places predefined control flow on the workflow side and model-directed tool use on the agent side. Real products may combine both.

Agentic engineering describes how those capabilities are used to build software. It is different from building an AI-agent product: an agent can help create an ordinary booking website with no AI feature at all. It also does not require a swarm of agents. Start with one clearly scoped task; add parallel work when tasks can actually proceed independently.

Sources: Anthropic: Building effective agents, December 2024

The same feature, built in two different ways

Consider an app that lets people save useful tools to a private shortlist and share selected entries. An exploratory prompt might ask for attractive cards, a Save button and a shareable page. Within a short experiment, you can learn whether people understand the layout and whether the shortlist feels useful. Sample data may be sufficient for that question.

A production brief needs to settle more. Who owns a list? Are notes private? What exactly does a share link reveal? Does removing an entry invalidate its link? Can account B request account A’s records by changing an identifier? What happens if an underlying app becomes private after someone saved it?

An engineering process turns those questions into behavior and checks. The agent implements ownership checks on the server, persistence and the sharing rules. Verification uses two accounts, a signed-out visitor, a revoked link and an app whose visibility changes. A mobile browser check confirms that the interface communicates the same rules.

Both approaches can contribute to one product. Explore the interaction first, then preserve what you learned while establishing the conditions needed for real use. The dangerous handoff occurs when a convincing preview silently becomes a service with private data and users, without anyone revisiting its assumptions.

Where vibe coding is especially useful

Exploration is valuable when you do not yet know what to build. A founder can compare two onboarding flows. A teacher can try a small interactive explanation. A designer can test how a filter panel behaves. A developer can create a disposable demonstration of an unfamiliar interaction before deciding whether it belongs in the product.

The useful output may be a decision rather than reusable code. If a prototype reveals that nobody understands the proposed workflow, discovering that early can justify the experiment even when the implementation is discarded. Preserve the learning: screenshots, the user’s reaction, the task that failed and the changes that helped.

Choose the environment to match the experiment. Sample data, an isolated preview and a modest scope make it easier to explore freely. When the idea starts requiring live customer records, privileged integrations or recurring charges, reassess how the work should be controlled. A small interface can still trigger consequential actions.

A practical agentic engineering workflow

The workflow below is an original Wantlist example for a small application change. Scale the checks to the consequence of a mistake. Adjusting a caption and changing account permissions deserve different levels of verification.

For an existing product, begin with what already works. Have the agent inspect the relevant files, project instructions and test commands. Capture existing failures before making changes, so that a new failure is not confused with an old one. Then build the smallest complete slice that can demonstrate the intended behavior.

1. Define the outcome: name the person, the task and the observable result. Include one important failure case.
2. State constraints: existing stack, data access rules, integrations, budget and actions that need additional authorization.
3. Provide relevant context: current source files, schemas, examples and documentation for the installed versions.
4. Ask for a scoped implementation plan that identifies assumptions and the changes needed across the full user journey.
5. Implement one coherent change in version control, with meaningful checks against the requirements.
6. Inspect the result: review important data paths and permissions; run the app and examine error, empty and loading states.
7. Verify the deployed environment: repeat the critical journey with appropriate test accounts and real configuration.
8. Record what changed, what passed, remaining limitations, and how to recover if the release fails.

What the productivity evidence actually says

A 2023 controlled experiment by Peng and colleagues asked developers to implement an HTTP server in JavaScript. The group with GitHub Copilot completed that particular task 55.8% faster than the control group. That is evidence about a bounded implementation exercise, not proof that every team’s full delivery cycle improves by the same amount.

METR’s July 2025 report studied 16 experienced open-source developers completing 246 real tasks in repositories they knew. With the early-2025 AI tools available in that experiment, tasks took 19% longer when AI was allowed. METR explicitly warned against generalizing that result to all developers, tasks or future tools.

The follow-up matters. In February 2026, METR explained that its newer experiment had selection and measurement problems: some developers avoided tasks or participation that required working without AI, and concurrent agent work complicated time estimates. The researchers thought acceleration had probably improved, but said the data provided weak evidence about its size.

These studies examine different conditions and should not be treated as opposite verdicts on the same universal question. For your project, measure accepted work, review time, rework and the user outcome. An agent that writes a feature quickly but leaves a day of debugging may save little. An agent that makes an otherwise unaffordable experiment possible can create value even when a simple stopwatch misses it.

Sources: Peng and colleagues: The Impact of AI on Developer Productivity, 2023 · METR: Experienced open-source developer productivity study, July 2025 · METR: Why its productivity experiment needed redesign, February 2026

The risks change as agents gain access

An incorrect code suggestion is a proposed change. An agent with a terminal, database credentials and a deployment tool can turn an incorrect assumption into an action. Define permissions around the task: access to a test environment should not automatically imply permission to modify production records or send messages to customers.

Prompt injection adds a distinct concern. OWASP describes attacks in which instructions embedded in inputs influence a model’s behavior; indirect attacks can arrive through material the system retrieves. A repository file, web page or support message can contain text asking an agent to ignore its task or reveal information. Treat those materials as data to assess, rather than authority to change the assignment.

Useful engineering controls include isolated execution, scoped credentials, limits on outbound access, reviewable changes and confirmation for consequential actions. A sentence in a prompt is not a substitute for enforced permissions. Keep a record of what actually executed and design a recovery path for mistakes.

Tests also have limits. An agent can write tests that repeat its own mistaken assumption, weaken an assertion to obtain a pass, or mock away the integration that is failing. Verify against independent acceptance criteria and inspect sensitive behavior directly. A second agent’s agreement is another opinion, not independent proof of correctness.

Sources: OWASP: Prompt injection

How to choose tools and a stack without chasing every release

Evaluate the complete working environment. Can you inspect and export the code? Can the agent run the relevant tests? Can you see what changed? Does the preview use the same authentication and storage assumptions as deployment? Can you keep secrets on the server and limit which external actions the agent may take?

For a web application, a conventional stack might combine Next.js and TypeScript with PostgreSQL, an authentication library, object storage and a deployment pipeline. That is an example, not a requirement for agentic engineering. The valuable properties are documented interfaces, a maintainable dependency set, observable behavior and a way to test and restore the system.

Distinguish a tool’s maximum capability from its fit for your work. A visual app builder may be a good place to evaluate an idea. A repository-based agent may suit an existing codebase. Neither category automatically establishes accessibility, reliable permissions or a sustainable operating cost.

Run a small comparison using the same brief. Include an existing bug, a data permission rule and one deployed user journey. Record how much intervention was needed and whether you could understand the result afterwards. This gives you evidence about your workflow without pretending a general leaderboard can choose an engineering process for you.

What builders and teams still need to learn

For a new builder, the first useful skills are concrete: understand what belongs in the browser and on the server, how a database record persists, how authentication differs from permission, where a secret is stored, and how to restore a previous version. You do not have to master an entire computer science curriculum before experimenting, but you need a path to understanding the parts your users rely on.

For experienced developers, delegation introduces its own work. Give agents enough context without burying the task, identify assumptions early, keep changes reviewable and decide which evidence matters. Read critical code and use explanations or walkthroughs to expose misunderstandings. An explanation should be checked against the implementation, just as the implementation is checked against the requirement.

DORA’s 2025 research describes AI as amplifying an organization’s existing strengths and weaknesses. Its emphasis is on the surrounding system, not simply acquiring a tool. That is a useful lens for teams: improving feedback, documentation and delivery practices may matter as much as changing the model.

There is also a learning trade-off. Delegating every difficult detail can make progress feel fast while leaving nobody able to diagnose a failure. Use AI to increase feedback: ask why an approach was chosen, predict what a change will do, then run the check. Understanding develops through those comparisons, not through accepting an explanation on trust.

Sources: DORA: State of AI-assisted Software Development 2025

The future: plausible directions, not a promised timetable

The following is Wantlist’s editorial outlook as of September 2026. These are possibilities to prepare for, not claims that a particular capability, adoption rate or employment outcome is inevitable.

First, more development work may move from individual suggestions to delegated outcomes. Builders could spend less time requesting each edit and more time supplying context, evaluating evidence and deciding what should ship. The constraint is not only model capability: unclear requirements and weak feedback can still derail a longer task.

Second, verification may become a more prominent part of the product experience. A useful agent interface can show the requirement, changed files, executed checks, observed result and unresolved uncertainty together. Better browser testing, isolated environments and reproducible demonstrations would make it easier to judge a result without relying on a confident completion message.

Third, standard interfaces can make tools easier to connect. The Model Context Protocol, introduced in November 2024, is an example of an effort to connect AI applications with external data and tools. Wider interoperability could reduce integration work, but protocol compatibility does not establish that a tool is trustworthy or an action is authorized.

Fourth, small teams may be able to attempt a wider range of software products. That could increase the importance of finding a real need, earning trust and reaching users. More inexpensive implementations do not automatically produce more valuable businesses. Support, distribution, operating costs and maintenance remain part of the product.

Finally, changes to jobs and learning are likely to be uneven. Some tasks may need fewer manual implementation hours, while others create more demand for review, integration or product judgment. The evidence discussed here does not establish a date when developers become unnecessary. It supports measuring how work changes, rather than treating either universal replacement or no meaningful change as settled fact.

Sources: Anthropic: Introducing the Model Context Protocol, November 2024

How to move your next project forward

Choose the next step around the uncertainty you need to resolve. If you are unsure whether an interaction is useful, build a small prototype and put it in front of someone with that need. If the interaction already makes sense, work through persistence, permissions, failure handling and the deployed journey before depending on it.

Keep a short handoff document when moving from experiment to product: the user problem, what the prototype established, what is simulated, the data involved and the conditions for release. This prevents an attractive demo from carrying assumptions into production unnoticed.

For Wantlist builders, the same discipline applies to the public introduction. Explain what the app does today, show real product evidence and distinguish availability from plans. People looking for an app need to understand its fit for their task. The method used to generate the code is background information; demonstrated usefulness gives them a reason to try it.

Questions builders often ask

Is all AI-assisted coding vibe coding? In the broad casual usage, people sometimes mean that. In the narrower meaning used here, no: reviewing, understanding and testing generated changes is a different process from steering mainly by the visible result.

Do I need multiple agents for agentic engineering? No. A single agent working inside a clear specification and verification process is enough. Several agents can help with independent tasks, but also introduce coordination and review work.

Can a non-programmer use agentic engineering practices? Yes. Writing acceptance criteria, checking a complete journey and recording limitations are accessible starting points. Bring in appropriate technical expertise for systems whose correctness or permissions you cannot evaluate yourself.

Does agentic engineering mean building an AI agent? No. It concerns using agents in the engineering process. The product you build can be a conventional website, mobile app, internal service or developer tool.

Does passing the tests make an AI-built app production-ready? It establishes that those checks passed in that environment. Readiness also depends on what the tests cover, deployment configuration, permissions, recovery and the actual user experience.

About this article

This Wantlist explainer was researched and drafted with AI assistance. Historical milestones and research results link to original announcements, practitioner writing and research publications; Karpathy’s original post is linked through an accessible transcript. Practical scenarios, the comparison framework and the future outlook are Wantlist editorial analysis. The article does not claim an independent benchmark, a formal definition shared by the whole industry, or a forecast of a particular tool’s performance.