Agentic engineering is a way of building software where AI agents plan, write, test and fix code under human direction, and the team trusts the result because of specs, tests and review, not because of the vibes. That one sentence is the difference this article is about.
One of our clients funds and manages class action litigation. When we moved their delivery to agents, merged pull requests went from 7.5 to 20.8 a week. Cycle time, from first commit to merged PR, dropped from 7.7 to 2.7 days.
Every one of those PRs was still tested and reviewed. That is the part I care about.
I lead the agentic delivery practice at Vazco, and most of my work is on fintech and legaltech products. There, a bug can mean a wrong payout or a broken audit trail. Speed only counts if you can prove the code is correct.
This article explains how I separate the three ways teams build with AI today, why they differ in how they earn trust, and how to pick the right one.
TL;DR
- Vibe coding, AI-assisted development and agentic delivery all shorten the path from idea to software. They differ in how they create confidence in the output.
- Vibe coding is great for discovery: prototypes, demos, one-off tools. You judge it by whether it runs.
- AI-assisted development is today's mainstream: humans drive, AI speeds up each step, and confidence comes from the review and CI process you already have.
- The agentic mode delegates whole tasks to agents across the full lifecycle. Confidence comes from specs, tests the agents run themselves, and layered review.
- Speed without lower standards is possible, but only when specs, tests and reviews can carry the extra volume. Our case study below shows what that looks like.
Why do the labels "vibe coding" and "agentic" cause so much confusion?
Some teams say they are "doing vibe coding." Others say they are moving to "agentic" workflows. Others call roughly the same thing "AI-assisted development." Often they mean very different workflows with very different quality standards.
Addy Osmani calls vibe coding a "suitcase term": it now covers everything from a weekend hack to a disciplined workflow with human oversight (Addy Osmani). Simon Willison made the same point a year earlier in Not all AI-assisted programming is vibe coding.
This matters beyond vocabulary. The label you pick shapes how you staff teams, what you expect from senior engineers, and what you are willing to ship.
Asking "how much AI do you use?" does not help much. Almost everyone uses it a lot now. The better question is:
Why do we believe this output is good enough to own and ship?
I use four questions to answer it:
- Confidence model: what makes us trust the change?
- Where intent lives: in someone's head and a chat history, or in artifacts the team can reuse?
- Reversibility: is this a throwaway prototype, maintainable code, or a repeatable delivery system?
- The human's main job: typing, steering, reviewing or supervising?
What is vibe coding?
Vibe coding is prompt-first programming where you accept what the model generates and judge it by whether it runs, without reading the code closely.
The term comes from Andrej Karpathy, a founding member of OpenAI and former head of AI at Tesla, where he led the Autopilot work. In February 2025 he described a style of coding where you "fully give in to the vibes" and "forget that the code even exists" (Karpathy on X).
Addy Osmani gives the version I find most useful for engineering teams. Vibe coding is not just heavy AI use. It is the loop of prompt, accept, run, and reprompt, without reviewing the diff (Addy Osmani). The human steers by outcomes.
When is vibe coding the right choice?
More often than engineers like to admit. Good fits:
- a greenfield proof of concept or MVP you want in front of users this week
- a hackathon demo
- a one-off internal script only you will run
- learning a new library or testing a product idea with a client
In these cases speed matters more than structure, and you can throw the code away. That is a real benefit.
What are the limits of vibe coding in production?
The trade-off is clear. The confidence model is "it seems to work." That holds as long as the code stays small and short-lived.
Once you need to change it, scale it, secure it or hand it to someone else, you have to build the understanding you skipped. Often the cheapest path is to keep the prototype as a working spec and rebuild it properly. That is fine if you planned for it. It hurts when nobody does.
What is AI-assisted development?
AI-assisted development is the familiar delivery process with AI speeding up individual steps, while humans still make every important decision.
Picture an axis. On one end, the human writes code by hand. On the other end, agents deliver whole tasks under supervision. AI-assisted development sits in the middle of that axis, and today most teams live there.
Humans decide what to build, how to sequence it, which standards apply, what gets merged and what gets released. AI helps with implementation, tests, refactoring, debugging, documentation and scaffolding.
Thoughtworks goes further in its Looking Glass 2026 report. Even when AI runs across the full lifecycle, which it calls AI-first software delivery, humans and AI should co-construct software under human-in-the-loop stewardship, with rigorous engineering oversight.
How does AI-assisted development create confidence?
It borrows confidence from the process you already have. A developer prompts for a function, reads it, edits it, and commits it. A teammate reviews the PR. CI runs the tests. The release follows your normal rules.
Nothing new has to be built for trust. The developer is still the author of every change. AI makes them faster at typing, searching and drafting, but the developer's judgment is still the gate.
That is its strength and its ceiling. Throughput is still limited by how many changes one person can write and review. You go faster, but you are still working one change at a time.
What is agentic engineering?
Agentic engineering (AE) is a delivery model where engineers hand well-scoped tasks to AI agents that plan, implement, test and fix code, while humans own the spec, the architecture, the review and the result.
Karpathy proposed the name in February 2026, a year after coining vibe coding. He said he chose it because "there is an art & science and expertise to it" (Business Insider). People also call this agentic coding. I prefer "engineering," because coding is only one part of it.
The human's job changes. You spend less time writing code and more time defining work, setting constraints and checking results. Peter Steinberger's essays on shipping at inference speed show what this looks like for one strong practitioner.
How does agentic engineering create confidence?
Trust comes from a verification system, not from one person reading every line as it is typed. In our projects that system has three parts:
- Intent written down. A spec exists before the agent starts. Project rules, test commands and conventions live in the repository, not in someone's head.
- Agents verify their own work. Agents do more than produce code that passes static analysis. They run the software and check its behavior directly: unit, integration and end-to-end tests, and new tests for every change.
- Layered review. Every PR gets an AI review. Higher-impact changes also get a human review, so engineers spend attention where the risk is.
I think quality assurance is the biggest difference between vibe coding and AE. In vibe coding the human checks whether it seems to work. In agentic engineering the agent has to prove it works before a human looks.
Does agentic engineering stop at writing code?
No. If agents only write code, you have moved the bottleneck to planning, review and release. We use agents at every stage of the software development lifecycle:
- Planning and specs: breaking a feature into tasks and drafting specs for a human to approve
- Implementation: writing code test-first against the spec
- Testing: running the full test suite and adding new tests
- Review: an AI review on every PR before a human sees it
- Release and maintenance: helping with deploys, changelogs and investigating issues
Vibe coding vs. AI-assisted development vs. agentic engineering: how do they compare?
| Criterion | Vibe coding | AI-assisted development | Agentic engineering |
|---|---|---|---|
| Confidence model | “It runs” | Human authorship plus existing review and CI | Specs, agent-run tests, AI and human review |
| Where intent lives | Prompts and someone’s head | The developer’s head, tickets | Written specs and repo rules |
| Reversibility | Disposable | Maintainable code | Repeatable delivery system |
| Human’s main job | Prompting and trying | Writing and steering | Defining, supervising, reviewing |
| Who reads the code | Often nobody | The author and a reviewer | AI reviews every PR; humans review high-impact ones |
| Tests | Optional | As before | Required; agents run and write them |
| Best for | Prototypes, demos, personal tools | Mainstream team delivery | High-leverage delivery on strong foundations |
| Main risk | Code nobody understands | Speed capped by human typing and review | Weak foundations get amplified |
Do the tools define which mode you are in?
No. The same tool can support all three modes. You can vibe code in an agentic tool, and you can do careful agentic delivery with a simple setup.
At Vazco each team uses a different harness, tuned to its project. What defines the mode is the workflow around the tool: where intent lives, how output gets verified, and who signs off.
How do we do agentic engineering at Vazco?
Here is one project in numbers.
Case study: a litigation funding platform
Our client runs a FinTech and LegalTech product that helps fund and manage class action litigation. In this domain, correctness and auditability are not up for debate.
We rebuilt the delivery process around AE:
- Spec-driven AI coding. Every task starts from a written spec.
- Test-driven development. Agents write tests first, then the code.
- Automated quality control on every change. During every implementation, agents run the full unit, integration and end-to-end test suites and add new tests.
- Layered review. Every PR gets an AI review. Higher-impact changes also go through human review.
Merged PRs per week increased 2.8x, and every PR was still tested and reviewed.
The review number matters most to me. Faster coding is only safe if oversight keeps up. Reviews now start 3.5 times sooner, so the AI never outruns the humans who sign off.
Lead time improved less than cycle time. A third faster from PR to production is a good result, and it also shows where the next bottleneck sits: in the release path, not the code.
How does this compare with industry benchmarks?
Thoughtworks is blunt about AI speed claims: "Claims about the ability of AI to speed up the software delivery process are often wildly exaggerated, but we've observed a typical uplift of up to 15%" (Thoughtworks Looking Glass 2026).
Our numbers look very different: about 2.8x more merged PRs and 65% shorter cycle time. These are not like-for-like figures. Thoughtworks describes typical uplift across many organizations, and we are measuring one project with our own metrics.
Still, I read the gap as a signal. Adding AI to an unchanged process seems to give modest gains. The bigger gains came when we redesigned the process around specs, TDD and layered review.
Where does this approach struggle?
Agentic engineering is harsh on organizational weaknesses. Weak tests, vague tickets, undocumented repos, unclear ownership and loose review all become visible fast.
Agents do not fix these problems. They amplify them. That is why Addy Osmani's focus on tests and well-scoped tasks is the best warning label I have seen (Addy Osmani).
Is AI-assisted development just a transitional stage?
My bet is yes. AI-assisted development is a transitional category.
It is not wrong, and it is not going away tomorrow. Most teams should spend time there first. But I think the long-term center of gravity is agentic. That is my opinion, and it rests on two observations.
First, the strongest practitioners already describe workflows that look less like assistance and more like supervised delegation. Steinberger's essays are one example. Osmani's line between AI-assisted and agentic work points the same way.
Second, the tools are moving in that direction. Most major coding tools now offer agent modes that search the codebase, edit many files, run commands and open pull requests.
The Thoughtworks figure of up to 15% typical uplift points the same way: AI layered on today's process helps, but the larger gains need a different process.
So I treat AI-assisted development as a bridge. It builds the habits the agentic mode needs later: clean repos, good tests, explicit instructions, well-framed tasks and disciplined review.
How can you move your team to agentic coding?
You don't need to start with the labels. Start with the four questions, then work through these steps:
- Write specs first. Pick one repo and require a short written spec before an agent starts a task.
- Keep tasks small. A task an agent can finish and test in one go is easier to review.
- Make tests required. Agents should run unit, integration and end-to-end tests on every change and add new ones.
- Put rules in the repo. Test commands, conventions and constraints belong in files the agent reads, not in someone's memory.
- Layer your review. AI review on every PR, human review where the impact is high.
- Measure. Track merged PRs, time to first review, cycle time and lead time before and after, so you know whether it works.
Then match the mode to the work:
- Vibe coding for discovery.
- AI-assisted development for mainstream team delivery.
- Agentic engineering for high-leverage delivery, when your verification system is strong enough to support real delegation.
What should you remember?
The difference between the three modes isn't how much AI you use. It is how you earn the confidence to ship. This approach makes teams much faster only when specs, tests and reviews are strong enough to carry the extra volume.
One thing to try tomorrow: pick one repository, write a spec for one small task, give it to an agent with your test command, and compare the result with your usual workflow.
If you are planning to bring AI agents into your team's delivery process, we are happy to share what worked for us. See how we approach agentic engineering at Vazco.
FAQ
What is agentic engineering?
What is vibe coding?
What is the difference between vibe coding and agentic engineering?
Is AI-assisted development the same as agentic coding?
Is agentic engineering safe for regulated products like fintech?
About the authors
References
- Andrej Karpathy, original "vibe coding" post on X, February 2025 (archived copy)
- Lakshmi Varanasi, "The guy who coined 'vibe-coding' says the next big thing is 'agentic engineering'", Business Insider, February 2026
- Simon Willison, "Not all AI-assisted programming is vibe coding (but vibe coding rocks)", March 2025
- Addy Osmani, "Agentic Engineering", February 2026
- Thoughtworks, Looking Glass 2026, "AI and software delivery"
- Peter Steinberger, "Shipping at Inference-Speed"
.webp)
