Agentic coding vs vibe coding: the difference is where the review happens

tldr: Vibe coding is prompting your way to software you never read. Agentic coding is handing a defined task to an agent that plans, edits, runs your checks, and hands back finished work for review. Over 23 days on our own codebase, agents opened 7 of every 10 merged pull requests (69 of 99), and 4 out of 5 agent PRs (56 of 69) merged without a human touching a single line. The failures had one thing in common.

Agentic coding is handing a defined task to an AI agent that plans, edits files, runs your tests, and returns finished work for a human to review. Vibe coding is prompting your way to software you never really read. Both start with a prompt. Only one of them ends with somebody reading the diff.

I run coding agents against Hashnode, Bug0, and the tool I built to do it, FactoryKit. Since I sell that tool, discount the product mentions accordingly and hold the numbers to a higher standard than the opinions. The measurements in this post all come from one place, the FactoryKit repository between 9 and 31 July 2026, and every one of them is recomputable from git log on a clone.

The questions I hear most, and the ones I want to answer here:

• Is agentic coding just vibe coding with better marketing?
• What can I actually hand off, and what still needs me?
• How do I know the code works if I never watched it get written?
• Does this make me faster, or just busier at review time?

Vibe coding and agentic coding are not the same activity

Both start with a prompt, and that is where the resemblance ends. The difference is whether a human reads the code before it ships.

Andrej Karpathy named vibe coding in February 2025, and his description was not a criticism. He described giving in to the vibes, embracing exponentials, and forgetting that the code even exists. He was building throwaway weekend projects. For that, it works.

I want to defend vibe coding for a moment, because the term has become an insult and it does not deserve to be. It is the fastest way to find out whether an idea is worth building. I have used it to answer questions like "would this API shape feel right" in twenty minutes instead of an afternoon. The output is a prototype, and the correct next step is to throw it away.

Agentic coding starts from the opposite premise. You write a task the way you would write a ticket for a colleague. The agent works somewhere else, runs your checks, and comes back with a pull request. You read that pull request. Review did not disappear from the process; it moved to the end of it.

	Vibe coding	Agentic coding
Unit of work	A prompt in a chat	A task with a definition of done
Where code is written	In your editor, as you watch	In an isolated environment, without you
Who reads the code	Often nobody	A human, at the pull request
When review happens	Never, or after an incident	Before the merge
Failure mode	Unmaintainable code nobody understands	A vague task produces a vague pull request
Where it belongs	Prototypes, spikes, learning	Production repositories

What unread code costs you later

Vibe coding does not fail on the first change. It fails on the fourth, when someone has to modify code that no human has ever read.

The mechanism is duller than the story. Unreviewed code compounds. Every later change is made against assumptions nobody verified, by a model that has no memory of why the first version looked that way. You do not notice the debt while the prototype is working. You notice it the first time you need to change something under pressure, and discover nobody in the building knows where the load-bearing walls are.

Our closest brush with this is preserved in git, and it shows what review is actually for. On 20 July 2026 an agent built image upload for task attachments in FactoryKit. The feature worked. The follow-up task, filed the same day and preserved as a branch name, begins "we added ability to upload images, but images are available publicl...". The agent had left the uploads readable by anyone with the URL. Because every change lands as a pull request that a human reads and dogfoods, it surfaced within the day and the fix merged as its own reviewed pull request before the lead branch did.

Run that same afternoon under vibe coding and there is no reviewer and no follow-up task. The bucket stays public until an incident finds it for you. The model's mistake was identical in both worlds; what differs is whether anything stands between the mistake and production.

The handoff line

4 out of 5 agent pull requests merged without a human adding a single commit, 56 of 69. Agents opened 7 of every 10 pull requests merged into the FactoryKit codebase over 23 days, 69 of 99. The 13 that needed a human hand had something in common, and it was not difficulty.

This is the part I have not seen anyone publish, so here is ours.

How this was measured. The repository is FactoryKit itself, which we build with the factory. The window runs from the first commit on 9 July 2026 to 31 July 2026, which is 23 days. The agents are Claude Code, Codex, and Grok Build, chosen per task. Every number below comes from git log on that repository, so you can recompute all of it from a clone rather than taking my word for it. A pull request counts as agent-authored if it came from a factory/ branch. It counts as merged unchanged if every commit on that branch was authored by the factory, and as corrected if a human committed to the branch before it merged.

Measure	Count	Share
Pull requests merged in the window	99
Opened by an agent	69	69.7%
Opened by a human	30	30.3%
Agent PRs merged with no human commit	56	81.2% of agent PRs
Agent PRs a human committed to first	13	18.8% of agent PRs
Commits authored by agents	95 of 403	23.6%
Median commits per agent PR	1	(longest, 10)

Two things in that table surprised me. The first is the gap between 69.7% of pull requests and 23.6% of commits: agent changes arrive as small, self-contained units while the human commits cluster into architectural work. Small units, not small work. The integrations page in that window shipped as one agent pull request, six commits, nothing human on the branch. The second surprise is that the rate held as we leaned harder, 21 agent pull requests in the first week, then 23, then 25. I expected the curve to bend once the easy work ran out. It did not. The biggest week was the last one, week three running 19% ahead of week one.

That is a higher share than Ramp reports for Inspect, which passes more than half of their merged pull requests, up from 30% at the start of the year. The caveat: our 69.7% comes from a far smaller and younger codebase, which makes it easier, not harder.

Now the interesting 18.8%. Read the branch names of the corrected ones and a pattern shows up that has nothing to do with engineering difficulty. The tasks that came back needing a human were the ones where I had not written down what finished looked like. A task like "sometimes tasks fail mid way with this error" carries its own definition of done, since the error either still happens or it does not. A task that asks the agent to make an experience feel better does not, because the definition of done never left my head.

I have started calling this the handoff line: the boundary between work you can specify and work you still have to do yourself. Everything above it is a task. Everything below it is a conversation you have not finished having.

The uncomfortable implication is that the 18.8% measures me as much as it measures the agent. When I write a sharp task, I get a mergeable pull request. When I write a lazy one, I get a plausible diff that solves the wrong problem, and I usually deserve it.

Three runs show what the percentages hide. All three are findable in the repository by branch name; none of this is a reconstruction.

The clean one. On 18 July we pasted an error into the task box more or less raw. The task text begins, verbatim, "message": "API error (status 404 Not Found)" and mentions Grok Build. That was nearly the whole specification. The agent traced it to the Grok Build harness, changed two files, 14 lines added and 6 removed, and the pull request merged as a single agent commit with nothing from us. This is the handoff line's best case: the task carried its own definition of done, because the error either still reproduced or it did not.

The one that took a chain. The image upload feature from earlier in this post is also the window's messiest run. The lead task, "add the ability to support image upload when creating a task", turned into four pull requests. While the lead branch was open, three follow-up tasks merged as their own reviewed pull requests on 20 July: one of the agents could not read the uploaded image visually, the uploads were publicly accessible, and the start-task button needed disabling mid-upload. The lead branch merged the next day carrying ten commits, one of them mine, the only human commit in the chain. Merged after correction rarely means a wall of red review comments. It looks like this, a conversation conducted in follow-up tasks. Step back from the mess and the chain is the point: a user-facing feature with a security surface and a storage bucket went from first task to reviewed production code in two days, with one human commit. Complex work did not defeat the factory. It decomposed into it.

The abandoned ones. 92% of everything the factory started ended up merged, 69 of 75 branches. The 6 that did not put the abandonment rate at 8%. Their names are readable in the repository today: a feature for choosing which branch to check out, a team settings page, an investigation that begins "why does factory sometimes sends this er...". On one of the six, the last commit is mine, which means I stepped in to salvage the run and then walked away anyway.

What this data cannot tell you: it is one repository, worked on by the two people who wrote the tool, over 23 days. Git records that a human touched a branch, not why. Some of those 13 corrections were the agent getting it wrong and some were me changing my mind, and the same goes for the six abandoned branches; I am not going to pretend the log distinguishes them. Splitting the 69 tasks by category would need the full task text, which the branch names truncate.

What agentic coding needs to work at all

The categories above the handoff line share one property: the agent can tell whether it succeeded. That is a property of your infrastructure, not of the model.

The loop is not complicated. A task arrives. An isolated environment is created and your repositories are cloned into it. The agent implements the change, runs your checks, and gets a bounded number of attempts to fix what it broke, 3 in our case. Then the change is verified, and a pull request is opened for a human.

Three things have to be true before any of that produces work you would merge.

You need an isolated environment, because an agent that can reach your laptop or your production credentials is a security question, not a productivity one. You need a check suite you actually trust, because the agent's sense of "done" is exactly as good as the signal your repository gives it. And you need a review surface that carries evidence, because reading a diff tells you what changed and not whether it works.

This class of tool is getting crowded, which is a good sign for the model rather than a bad one. Devin from Cognition, Google's Jules, the GitHub Copilot coding agent, OpenAI's Codex, Cursor's background agents, and FactoryKit all share the same shape: a task goes in, a pull request comes out. They differ in what surrounds that loop, and the surroundings are the entire product.

What changed in my week

I have not opened a local development environment in weeks. The work did not disappear. It moved from typing to specifying and reviewing.

The day looks different now. I write tasks, queue them, and review evidence-backed pull requests as they arrive. Simple tasks come back in about 5 minutes, moderate ones in 10 to 15, and complex ones in 20 to 30. Several run at once, which is the part that changed my throughput more than any single agent capability.

Averaged over the window, a merged agent pull request landed every 8 hours, around the clock, for 23 straight days: 3 a day in one repository, alongside two people doing their own work. The number I care about is not that one though. It is the 56 that needed nothing from me after I wrote the task.

What got harder is the part nobody warns you about. Writing a good task is a real skill, and it is the skill the handoff line actually measures. I spend more time on the first two sentences of a task than I used to spend on a small commit, and it pays for itself every time.

Where agentic coding ends up

One agent working on one task is a tool. A queue of them with shared context, your checks, and a single approval gate is a software factory.

This is not speculation about where the industry might go, because the largest teams are already there. Ramp built an internal background agent called Inspect that now produces more than half of their merged pull requests, up from 30% at the start of the year. Uber built Minion, which ships about 1,800 code changes a week and is used by 95% of their engineers.

Neither company bought that. There was nothing to buy, so they assigned platform teams and built it; what that build actually costs is its own post. What they built has a name now, an AI software factory, and the interesting question for everyone else is no longer whether the model works. It is who does the work of standing one up, given that most engineering organisations do not have a platform team to spare and the ones that do have other plans for it. Our answer at FactoryKit is that we go and do it, with forward-deployed engineers who install the factory in your infrastructure and run it on your backlog before handing it over, but the shape of that answer matters more than whose it is.

The shape of the job changes either way. If the handoff line is real, and our data says it is, then the valuable skill stops being how fast you write code and becomes how precisely you can describe finished work. Engineers become editors with leverage. The backlog stops being a graveyard and becomes a queue.

I would rather be wrong about this in public than vague about it, so the numbers above are the ones I have. If your data looks different, I want to see it.

And if you want the factory without the platform-team project, that is what we sell: the engine behind the 69 pull requests above, stood up inside your infrastructure and run on your own backlog before we hand it over, or self-serve on our cloud if you would rather start with a single repository. Book a demo, or start at factorykit.ai.

FAQs

What is agentic coding?

Agentic coding is handing a defined task to an AI agent that plans the work, edits files, runs your tests, and returns finished code for a human to review. The agent works on its own rather than suggesting lines while you type, and the review happens at the pull request instead of in the editor.

What is the difference between vibe coding and agentic coding?

Vibe coding removes the review: you prompt your way to working software and never read the code. Agentic coding moves the review to the end: an agent completes a defined task and a human reviews the result before it merges. The difference is not model quality, it is whether anyone reads the diff.

Is vibe coding bad?

No, it is misapplied. Vibe coding is a fast way to build prototypes, spikes, and throwaway tools, and it is genuinely useful for deciding whether an idea is worth pursuing. It becomes a problem when the prototype quietly becomes production code that nobody has read.

Is agentic coding safe for production code?

It is as safe as its isolation and its checks. Run every task in an isolated environment, never give the agent real credentials, keep a human approval gate at the pull request, and verify user facing changes before merging. Without those, you are vibe coding with extra steps.

How is agentic coding different from GitHub Copilot or Cursor?

Copilot and Cursor assist inside your editor while you work, so you supervise in real time. An agentic coding tool, sometimes called a background coding agent, takes a task away and returns a pull request. You review its output rather than watching it type.

What kinds of tasks can I hand to an AI coding agent?

In our runs, the work that came back ready to merge had a checkable definition of done: bug fixes with a reproduction, changes covered by tests, and well specified additions. The work that failed was ambiguous product decisions where the definition of done existed only in my head.

Do I still need to review code an agent wrote?

Yes. Review is the point, not the overhead. Agentic coding does not remove review, it concentrates it at the pull request, which only works if that pull request carries evidence that the change behaves correctly.