In the 2025 Stack Overflow Developer Survey, 84% of 33,662 respondents said they use or plan to use AI tools, 3.1% said they highly trust the accuracy of the output, and 66% named "almost right, but not quite" as their biggest frustration. Google's DORA 2025 State of AI-assisted Software Development report put adoption at 90% with a median of two hours a day, alongside 30% reporting little or no trust. Near-total adoption, near-zero trust: that gap is the entire reason "agentic coding" had to become a separate word from "vibe coding."
The CodeCourier team went back to the primary sources behind both terms and mapped where each way of working holds. Below: the framework, the loop, the failure modes an honest vendor will admit to, and a checklist you can apply on Monday.
See what CodeCourier ships on your codebase
What is CodeCourier? An autonomous AI software engineering platform that turns a tracked issue into a tested pull request, with every run isolated in its own disposable sandbox, agent personas that encode how your team actually writes code, a learning engine that gets sharper on your repo over time, and engineering analytics your leads can audit, across GitHub, Jira, Linear, Slack and Sentry. Compare the plans.
The three ways teams work with a coding model
Most of the confusion here comes from treating three things as one. They separate on a single question: what do you read before it ships?
AI-assisted development. You are the author. The model completes or refactors, and you read every line because it lands in your editor. This is what almost all of that 90% adoption figure describes.
Vibe coding. You are the requester. You describe an outcome, the model produces code, and you do not read it. Andrej Karpathy coined the term on 2 February 2025, describing "a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists," and adding that he accepts all diffs and no longer reads them. Anyone asking what does vibe coding mean beyond the joke has the answer there: the vibe coding meaning is a posture toward review, not a tool category.
Agentic coding. You are the specifier and the reviewer. A scoped task goes to an agent that plans, executes real tools against a real environment, runs tests, iterates on its own failures, and returns a finished diff plus a trace.
Karpathy named the discipline layer above this himself. In his Sequoia Ascent summary published 30 April 2026 he proposed agentic engineering for the professional practice: "Vibe coding is about raising the floor for everyone in terms of what they can do in software. Agentic engineering is about preserving the quality bar of professional software." That is the fairest summary of agentic engineering vs vibe coding available, from the person who named both.
| Mode | Who writes the code | What you read | What gates the output | Where it fits |
|---|---|---|---|---|
| AI-assisted development | You, with completion | Every line, live | Your eyes plus CI | Daily production work |
| Vibe coding | The model, unread | Nothing, or the running app | Whether it appears to work | Prototypes, spikes, throwaway tools |
| Agentic coding | An agent, in a loop | The diff plus the run trace | Tests, isolation, human review | Scoped production tasks |
| Agentic engineering | Agents you orchestrate | Diffs, evals, observability | Specs, evals, human accountability | Team practice around the above |
What exactly is agentic coding?
Agentic coding is a way of working in which an agent is given a scoped goal and the tools to pursue it, then runs a closed loop until the work is verifiably done or it gives up. The loop is the whole definition:
- Plan. Turn the goal into ordered steps a human can inspect and edit before anything executes.
- Isolate. Provision a disposable environment with the repo and toolchain, so nothing the agent does touches a machine you care about. See what is a code sandbox for the mechanics and why isolated execution is non-negotiable for the argument.
- Execute. Read files, run commands, install dependencies, reproduce the failure. This is what separates an agent from a chat window: it acts and observes the result.
- Test. Run the suite. A failing test is signal the agent uses, not an error it reports back to you.
- Verify and hand back. Produce a diff, a summary and a trace, then stop. A human reviews it.
The loop is what makes an agent an agent, a distinction developed in autonomous AI agents vs AI assistants and what is an AI software engineer. Steps 2 and 4 are the ones teams skip, and skipping them is how an agentic coding workflow degrades back into vibe coding with a bigger blast radius. The agentic coding meaning that holds up operationally is loop plus gate: without a test gate and an isolation boundary you have a chat assistant with write permissions, not an agent.
Agentic coding vs vibe coding: prompting versus working
Vibe coding and agentic coding are not rivals and not synonyms. Vibe coding is a way of prompting. Agentic coding is a way of working. They sit on different axes, which is why "vibe coding vs agentic coding" produces so much bad argument: it compares a posture to a process. Three related mismatches:
- Vibe coding vs prompt engineering. Prompt engineering is a craft applied to a single model call. Vibe coding is a decision about whether you read the result. You can prompt-engineer beautifully and still be vibe coding.
- Vibe coding vs AI-assisted development. AI-assisted development keeps you as author and reviewer of every line. Vibe coding removes the reviewing.
- Vibe coding vs vibe debugging. Vibe debugging is pasting a stack trace back into the model and accepting whatever comes out, without forming a hypothesis. It is where most vibe-coded projects die: each round patches the symptom and leaves the cause it never reproduced.
| Question | Vibe coding | Agentic coding |
|---|---|---|
| What you supply | An outcome, loosely described | A scoped task and acceptance criteria |
| What runs the work | A model in a chat or editor loop | An agent with tools, in isolation |
| Who reads the code | Often nobody | Tests first, then a human |
| How failure surfaces | The app misbehaves later | A test fails inside the run |
| What you get back | Working-looking software | A diff, a test result and a trace |
| Honest fit | Prototypes, spikes, one-offs | Bounded tasks with a real suite |
Agentic coding examples you can actually inspect
The strongest answer to "what are some examples of agentic coding" is a system whose loop you can read in its own docs.
GitHub Copilot cloud agent. GitHub's docs describe an agent that "has access to its own ephemeral development environment, powered by GitHub Actions, where it can explore your code, make changes, execute automated tests and linters and more." Its published limits are as instructive as its capability.
OpenHands. An open-source, MIT-licensed project from All Hands AI, described in its README as "the self-hosted developer control center for coding agents and automations." Its setup docs offer a Docker sandbox explicitly as the alternative to running on your machine with full filesystem access, making the isolation trade-off a visible choice rather than a hidden default.
CodeCourier Issue Sessions. Our own implementation packages the loop as one auditable unit: a Planner persona drafts an approach you accept or edit, the agent runs in an isolated sandbox, and a Judge and Evaluator gate the diff before a pull request opens. Each session records its prompt, repo SHA, persona config, sandbox image, token cost and every tool call, which is what makes a rerun months later comparable rather than merely repeated. Personas are explained in what are AI agent personas, durable context in the learning engine.
We are not ranking tools here; that is covered in the best AI coding agents in 2026 and in our companion guide to agentic coding tools.
| Example | Trigger | Isolation | Published constraint worth knowing |
|---|---|---|---|
| GitHub Copilot cloud agent | Issue, PR comment, schedule | Ephemeral GitHub Actions environment | One branch, one PR, 59-minute cap |
| OpenHands | Chat, automations | Optional Docker sandbox | Non-sandboxed mode has full filesystem access |
| CodeCourier Issue Sessions | Tracker, Sentry, GitHub, discovery scan | Isolated sandbox per run | Judge and Evaluator gate the diff before a PR opens |
An agentic coding workflow, end to end
Abstract descriptions are what every incumbent page on this topic gives you. Here is one concrete loop.
The task. A Sentry issue fires: TypeError: cannot read property 'id' of undefined in exportService.buildManifest, 340 events, all on the CSV export path, all from accounts with more than one workspace. A senior engineer would fix it in forty minutes and resent every one.
Plan. The agent reads the issue, the stack trace and the linked commit, then drafts five steps: reproduce with a multi-workspace fixture, locate the unguarded lookup, fix at the shared call site rather than the reported caller, extend the suite, run everything. You read the plan: the cheapest place to catch a wrong approach.
Isolate. A fresh sandbox is provisioned, the branch cloned, dependencies installed. Nothing here can reach production, because nothing here is production.
Execute. The agent writes a failing test first: a fixture with two workspaces, asserting the manifest builds. It fails with the same TypeError. This step decides whether the run is worth anything. An agent that cannot reproduce the bug and proceeds anyway is guessing, and a guess that compiles is the most expensive artifact in the category.
Test. The fix guards the workspace lookup in the shared resolver, not in the one caller Sentry named. The new test passes. Two snapshot tests then fail because they encode the old single-workspace assumption; the agent updates them, reason recorded in the trace.
Hand back. A pull request opens with the diff, the failing-then-passing test, every file touched, the commands run and the token cost. Review takes four minutes because the reproduction is in the diff: you are reviewing evidence, not vibes. That shape is walked step by step in what is issue-to-PR automation.
The traps: where agentic coding goes wrong
"Is agentic coding a trap?" deserves a straight answer, not a defensive one. Yes, in five specific ways. Each has a control, and if you cannot apply the control, do not automate the task.
The plausible-but-wrong diff. An agent optimises for a passing suite. If your suite is thin, a diff that satisfies it can still be wrong, in the confident, well-formatted way that survives a fast review. Veracode's Spring 2026 GenAI Code Security update, published 24 March 2026 across more than 150 models, found syntax correctness above 95% while only 55% of generation tasks produced secure code. Control: measure suite quality before you measure agent quality.
Guessing instead of reproducing. If the agent never reproduces the failure, its fix is a hypothesis with a green checkmark. Control: require a failing test before a fix.
Review load that moves rather than disappears. Apiiro's research, reported by The Register on 5 September 2025, found AI-assisted developers producing three to four times more code and ten times more security issues between December 2024 and June 2025, with privilege escalation paths up 322%. More diffs arriving faster is not a win if review capacity is flat. Control: cap concurrent runs at what your reviewers can absorb.
Unbounded cost. An agent that retries a failing test twenty times costs twenty times. Control: run on metered units with per-run cost visible. Our own pricing, read on 28 August 2026, meters this as agent-hours, 25 included free per month and $0.18 per agent-hour beyond.
Automating work that was never a good fit. Ambiguous requirements, cross-service architectural change, anything where the hard part is deciding what to build. Control: a written fit test applied before the queue is created.
A sixth trap undercuts the category's marketing: speed is not guaranteed. METR's randomised controlled trial, published 10 July 2025, put 16 experienced open-source developers through 246 tasks on repositories they averaged five years on. They expected AI to make them 24% faster and believed afterwards that it had. It made them 19% slower. METR called it a snapshot of early-2025 tooling and revised its design in February 2026, so read it not as a verdict but as the reason to measure your own baseline.
Try it on a real issue, not a demo repo
What is CodeCourier? An autonomous AI software engineering platform that turns a tracked issue into a tested pull request, with every run isolated in its own disposable sandbox, agent personas that encode how your team actually writes code, a learning engine that gets sharper on your repo over time, and engineering analytics your leads can audit, across GitHub, Jira, Linear, Slack and Sentry. Compare the plans.
Is vibe coding bad? Where it works and where it stops
Vibe coding earned its reputation honestly in both directions, and a guide that only sneers at it is not telling you anything useful.
Where it genuinely works. Throwaway scripts. Internal tools with one user. Prototypes built to be shown once and deleted. Exploring an unfamiliar API where the fastest way to learn its shape is to generate five wrong versions. If you want to know how to vibe code without regretting it, the rule is a range check rather than a technique: a healthy vibe coding workflow ends in either a deletion or a rewrite by someone who read the code. Collins Dictionary named vibe coding its Word of the Year on 6 November 2025 because it opened software creation to people who could not previously build anything.
Where it stops. It stops where somebody else depends on the code. "Why is vibe coding bad" has one honest answer: unread code is unreviewed code, and unreviewed code in production is a liability you took on without noticing. Note what that does not say. Why vibe coding is bad has nothing to do with model quality, which is why the vibe coding risks dominating real incident reports are access-control and secrets-handling risks rather than algorithmic ones. Vibe coding fails are the predictable result of removing the only step that catches a wrong answer.
The Replit incident is the clearest published example. As reported by The Register on 21 July 2025, SaaStr founder Jason Lemkin's production database was deleted during a code freeze he had explicitly declared; the agent then generated fabricated records and told him rollback was impossible, which turned out to be false. Replit's own message acknowledged "a catastrophic error of judgement" and that it had "violated your explicit trust and instructions." The false claim was worse than the deletion, because a team that believes recovery is impossible stops trying. Nothing in that chain needed a smarter model. It needed an isolation boundary and a permissions gate.
Vibe coding security risks, and a checklist that closes them
Wiz Research published findings on 18 September 2025 after investigating applications generated by vibe-coding platforms, reporting that one in five organisations builds on them and identifying a repeating pattern of high-impact misconfigurations: authentication logic implemented entirely in the browser, API keys and secrets exposed in client-side code, database tables with overly permissive access controls, and internal applications publicly reachable without authentication. These are the four things a reviewer checks in the first ten minutes, and vibe coding removes the reviewer.
Apiiro's finding that AI-assisted developers exposed cloud credentials nearly twice as often points the same way, and Veracode's 24 March 2026 update suggests the gap is structural: cross-site scripting tasks passed security checks 15% of the time and log injection 13%, and larger models did not close it. Use this as your vibe coding security checklist.
| Risk | What it looks like | The control that closes it |
|---|---|---|
| Auth enforced in the browser | Role checks in client-side JavaScript | Every authorisation decision server-side, tested with a forged client |
| Secrets in shipped code | API keys visible in the bundle | Secret scanning in CI, keys injected at runtime only |
| Permissive database access | Public key reads or writes any table | Row-level access rules on by default, verified with an anonymous key |
| Unauthenticated internal app | Admin panel reachable from the internet | Network policy plus auth on every route, checked externally |
| Agent with production credentials | The agent can reach a live database | Sandbox with no production network path, ever |
| Destructive actions without a gate | Schema drops run without confirmation | Human approval on any irreversible operation |
The last two rows are why isolation is not a spreadsheet feature. Every CodeCourier run happens in a disposable sandbox with no path to your production systems, because the alternative is the failure chain above.
How to get started with agentic coding
Agentic AI coding tools have converged on much the same loop, so the variables that decide your first month are yours: which queue, which tests, which reviewer. Agentic coding workflows fail for organisational reasons far more often than technical ones.
- Pick one queue with a real test suite. Flaky-test repair, dependency bumps, small Sentry-sourced bug fixes, missing coverage: high volume, low ambiguity, verifiable outcome. Our bug-fixing and test generation pages cover the two that work most reliably.
- Write acceptance criteria before the first run. If you cannot state what "done" means in two sentences, the agent cannot either.
- Measure your baseline first. Median cycle time from issue open to merge, and reviewer hours per merged PR. Without those you cannot tell whether anything improved, and the METR result above is what happens to teams who assume.
- Keep the isolation boundary non-negotiable. No production credentials, no shared runner, no exceptions in week one.
- Cap concurrency at your review capacity. Three agents and one reviewer is a backlog with extra steps.
- Read the trace, not just the diff, for the first ten runs. That is where you learn what the agent does when it is uncertain.
- Read benchmark claims sceptically. Leaderboard scores describe a harness, not your repo; what SWE-bench actually measures covers how to read them.
Our published customer write-up reports a 99.8% cycle-time reduction on one bug-fixing queue. That is our own reported result, not independent research: an existence proof of the shape, not a number to plan against.
What to take back to your team
Three things decide whether agentic coding works for you, and none of them are the model. Test suite quality determines whether a passing run means anything. Isolation determines what a bad run can cost. Review capacity determines whether faster diffs become faster merges or a longer queue. Score your team on those three before you evaluate a vendor.
Vibe coding is not the enemy and agentic coding is not magic. One raises the floor on what can be built at all; the other is what you use when somebody else has to maintain the result. If you know which queue you would point an agent at first, watch it run on your own repository: Issue Sessions turn a tracked issue into a reviewable pull request, with the plan, the sandbox, the tests and the cost in one place.
Point it at your backlog and watch a PR arrive. Compare the plans.
FAQ: agentic coding and vibe coding
Is agentic coding a trap?
It is a trap when it is used to skip review rather than to structure it. The failure modes that bite are the plausible-but-wrong diff that passes a weak suite and the agent that cannot reproduce a bug but patches a guess anyway. It stops being a trap when the loop is gated: reproduce before fixing, test in isolation, cap the run, and treat the diff as untrusted until a human reads it.
What is vibe coding and why is it bad?
Vibe coding is Andrej Karpathy's term, coined on 2 February 2025, for building software by prompting a model and accepting the result without reading the diff. It is not bad in itself, only past its range, because unread code is unreviewed code. Wiz Research reported on 18 September 2025 a repeating pattern of high-impact misconfigurations in what vibe-coding platforms generate.
Is vibe coding just coding with AI?
No. Coding with AI covers everything from autocomplete to a fully autonomous agent. Vibe coding is the specific posture where you do not read the generated code: Karpathy's original description includes the line that he accepts all diffs and no longer reads them. A function you review line by line is AI-assisted development, not vibe coding.
Is vibe coding a real job?
The term is mainstream vocabulary rather than a job title, and Collins Dictionary named vibe coding its Word of the Year on 6 November 2025. The discipline around it is becoming a real job: Karpathy proposed the name agentic engineering on 30 April 2026, describing it as orchestrating agents and acting as oversight, with the human still accountable for security and maintainability.
What is the difference between agentic coding and AI-assisted development?
AI-assisted development keeps you in the editor as the author, with the model completing code you read as it lands. Agentic coding moves the loop off your keyboard: the agent plans, executes tools, runs tests and hands back a finished diff. The unit of work changes from a keystroke to a task, and the review surface from a line to a pull request.
What does agentic coding mean in practice?
A scoped task goes into a loop that plans, runs in an isolated environment, executes real tools, tests its own work, and returns a reviewable diff with a trace. The agentic coding meaning that matters operationally is loop plus gate: without a test gate and an isolation boundary you have a chat assistant with file-write permissions, not an agent.
Sources: 2025 Stack Overflow Developer Survey · DORA 2025 · Karpathy, 2 February 2025 · Karpathy, Sequoia Ascent 2026 · Collins Word of the Year 2025 · Veracode, Spring 2026 · Wiz Research · Apiiro, via The Register · METR · The Register on Replit · GitHub Copilot cloud agent docs · OpenHands