Vibe coding best practices, and when to switch to agentic coding

What is vibe coding, and how is it different from agentic coding?

In earlier posts we covered the parts of a coding agent one at a time: hooks, subagents, skills, worktrees, auto mode and sandboxes. This post brings them together under one question: what does it take to vibe code well, and where do people fall into traps? We describe each habit briefly and link the post that covers it in detail.

Andrej Karpathy coined the term on X on 2 February 2025. In his post, as Wikipedia quotes it, he described how he worked: he accepted every change with “Accept All”, no longer read the diffs, and pasted error messages back to the agent with no comment. In his own words, this was not too bad for throwaway weekend projects. In short, vibe coding means having AI write code you don’t read and looking only at the result.

Simon Willison’s post of 6 May 2026 draws the line clearly. For him, vibe coding means working without looking at the code at all: you might not even know how to program; you say what you want, and if it works, it works. That is fine for a tool only you use, where a bug only hurts you. If you build software for other people, though, vibe coding is “grossly irresponsible”, because other people get hurt by your bugs. Agentic engineering is the other end: a software engineer who understands security, maintainability, operations and performance using these tools. The tools themselves are called agentic coding tools: in Anthropic’s definition, an agent that reads code, edits files and runs commands. So agentic coding is the way of working in which the agent writes and runs the code on its own; the difference between vibe coding and agentic engineering is whether you read the result and take responsibility for it.

The advice in this post rests on that line too. In a tool you use yourself, in a prototype or while you are learning something, vibe coding is fine. Code that other people use, that holds user data or that takes logins or payments is different: don’t ship it unread. The habits below are what move vibe coding towards agentic coding that someone has taken responsibility for.

If you are asking what coding with AI is called in general, the answer is AI-assisted coding; vibe coding is the end of it where nobody reads the code. Two other terms are often confused with it. Spec-driven development is almost the opposite: the agent writes a spec, a plan and a task list before the code. Harness engineering is a different topic: it describes the structure you build around the model.

What changed in coding tools this autumn?

In September and October, all five tools changed in the same direction: the agent asks you less, works on its own for longer and runs more in parallel. From the release notes:

Source: the tools’ release notes, 21 October 2026. Versions: Claude Code 2.1.284 and 2.1.286, Codex CLI 0.162.0, Antigravity CLI 1.3.5; the Copilot row is from VS Code’s September releases. On 18 June 2026, Google shut Gemini CLI off for Google AI Pro and Ultra subscribers and for free users and put Antigravity CLI in its place; companies and people using paid API keys can keep using Gemini CLI.

The common direction is clear: the agent carries a job further without asking you. Approval prompts were mostly answered yes without being read anyway; we covered the vendors’ own measurements of this in the auto mode and sandbox post. The real control has to sit in the agent’s loop and work while you are not watching: a test, a hook, CI. Claude Code’s verify change does exactly that: it has the agent run the check you wrote before it commits.

What does research say about vibe-coded apps?

Three studies were published or updated in August and September; all three are on arXiv, as preprints that have not been peer reviewed. The largest is the study by Deng, Fan and Meng; its latest version is dated 14 September 2026. The researchers collected 9,041 open-source apps built with Claude Code and Lovable, audited the 200 of them that were deployed, and found 1,186 vulnerabilities. AI auditors picked out the candidate vulnerabilities first; two authors with security expertise then examined each one separately, and it counted as a vulnerability only if both found it exploitable.

The result: 91% of the apps had at least one vulnerability, and 65.77% of the vulnerabilities were rated critical or high. They cluster in broken access control, injection and authentication. Access control is the part that makes sure a user can reach only their own data; when it is missing, the app still works, so a demo doesn’t show it.

The researchers also reproduced some of these vulnerabilities to see what helps. Two things reduced them the most: a prompt that makes production-ready code a condition for the job to count as done, and a harness with security checks added. But no setting removed them all. One more result stands out: in 90 of the 434 runs where a vulnerability was triggered (20.7%), the agent noticed the risk itself and wrote the insecure code anyway; often it left a warning or a comment instead of a fix. The agent knowing the risk is not enough; the check has to run before the job is done.

Andročec’s study of 21 August 2026 asks a small but direct question. It had the same agent and the same model write each of 6 web apps twice, in a single pass. The only difference between the two prompts was a section of security requirements added to the end of the second. The version with security requirements had fewer confirmed findings in every app (24 against 51), and none of them was critical or high. The most serious finding, though, was caught only by manual testing. The author also warns that the sample is small and each version was generated once; the results are observations, not a statistical effect.

Kraishan’s study (12 September 2026) looks somewhere else: what happens to agents’ pull requests after merge? It compared 37,623 pull requests from five commercial agents with humans’ pull requests in the same repositories. The result is “vendor-specific rather than uniform”: in the 90 days after merge, the revert rate of 3 of the five agents could not be statistically told apart from humans’; one was reverted less often and one more often. Suspicious patterns such as hard-coded credentials or eval turned up less often in the agents’ code than in humans’; but this is a pattern scan, not confirmed vulnerabilities. The data runs from December 2024 to July 2025, so it says nothing about how today’s tools and models rank. We covered how to read a comparison like this in the SWE-bench post.

Developers, too, trust most what they can check. In Stack Overflow’s 2026 survey, published on 6 October (more than 30,000 respondents; not a random sample but volunteer responses), 48% of respondents said they trust AI when they can easily validate its answers. Most of the habits below exist to make that easier.

Where do the five tools’ guides agree?

All five tools have their own best practices guide. On 21 October 2026 we read them all and put their advice on each topic side by side. For Copilot we read three of GitHub’s guides together (VS Code, Copilot CLI and the cloud agent); Cursor’s is a blog post dated 9 January 2026, and the others are undated. How many guides mention each of the six habits:

The five guides agree on 3 habits. The other 3 are recommended by 4 guides; Antigravity CLI’s guide doesn’t mention them, but it does recommend running parallel subagents in the background on large jobs, and the CLI has a /diff view that shows the changes. What each guide says:

Source: the five tools’ best practices guides, 21 October 2026. The Copilot column is from the guides for VS Code, Copilot CLI and the Copilot cloud agent. Each cell is a shortened version of the guide’s own sentence. “Not in its guide”: we found no sentence saying this in the guide we read that day; it may be in the tool’s other documentation.

A check. The agent stops when the job looks done. According to Claude Code’s guide, without a check it can run, “looks done” is the only signal it has, and every mistake waits for you to notice it. Tests, a build, a linter or a script that compares output with a sample: anything that reads as pass or fail will do. When the agent says “the tests pass”, ask for the command it ran and its output. The agent can check a UI in the browser; we covered turning that into a lasting Playwright test in the computer use post.

A plan. A plan keeps the agent from solving the wrong problem. Claude Code’s guide also says when to skip it: if you can describe the diff in one sentence, you don’t need one; if you are unsure of the approach, the change touches several files or you don’t know the code, have the agent plan. Cursor’s guide likewise finds it fine to go straight to the agent for small tasks you have done many times before. For a big feature, the step beyond a plan is a spec; we covered when it helps in the spec-driven development post.

A rules file. Codex and Cursor recommend the same path: start short, and add a rule when the agent repeats a mistake. Codex’s guide says that when the agent makes the same mistake twice, you should ask it for a retrospective and update AGENTS.md. We covered which tool reads which file in the AGENTS.md and CLAUDE.md post. For a rule that has to hold every time, a file is not enough; according to Claude Code’s guide, an instruction is advisory, while a hook runs every time (hooks post). A prompt you keep repeating can become a skill. The same file helps in review too. Our AI code review tool, diffox, reads the repository’s AGENTS.md (or its CLAUDE.md if there is none) from the branch the pull request merges into when it reviews the pull request. It uses the sentences in it that state an obligation (such as “must”, “never” and “always”) as the rules that decide what counts as a defect.

Reading the change. Cursor’s guide gives the reason in a few words: AI-written code can look right and still be subtly wrong, and the faster the agent works, the more your review matters. Claude Code’s guide recommends doing the review in a fresh context: a subagent that sees only the diff and the criteria isn’t swayed by the reasoning of the session that wrote the change. We covered how a subagent works in the subagents post, and what a person should look at in the post on reviewing AI-generated code.

Parallel work. Two agents working in the same folder can change each other’s files. Codex’s guide counts running parallel tasks on the same files without worktrees as a mistake; Claude Code, Cursor and Copilot also recommend running each session in its own worktree or folder. We covered what a worktree keeps apart and what it doesn’t in the git worktree post.

A clean session. As a conversation grows, the context fills with irrelevant detail and the agent’s performance drops. Claude Code’s guide recommends that if the agent still gets something wrong after you have corrected it twice on the same point, you clear the session and start over with a better prompt that includes what you have learned. We covered what summarising loses on a long job in the auto-compact post.

Where do the guides differ?

The guides don’t say the same thing on everything. They part ways in four places; which side suits you depends on your work.

• How much detail should you give up front? Codex asks for four things in every prompt: the goal, the context, the constraints and when the job counts as done. Copilot’s cloud agent guide asks you to write a clear description, complete acceptance criteria and which files will change, but adds that even without file paths the agent can often find the right code. Claude Code also asks you to name files, constraints and example patterns. Cursor, on the other hand, says to tag the file if you know it and leave it to the agent if you don’t; irrelevant files can confuse the agent.
• Should you fix every review finding? Claude Code’s guide warns that a reviewer asked to find gaps will usually find some, even when the work is sound. Chasing every finding leads to needless layers, defensive code and tests for cases that can’t happen. The guide recommends having the reviewer report only gaps that affect correctness or the stated requirements. Cursor’s and Copilot’s guides describe review tools without this warning.
• When should you automate? Codex’s guide counts scheduling a job that doesn’t yet work reliably by hand as a mistake: turn it into a skill first, and schedule it once it is predictable. This autumn’s new features, though, make scheduling easier; Copilot’s automations and Cursor’s Projects can run jobs without you asking. Before you turn them on, ask Codex’s question: does this job work reliably by hand?
• Which jobs should you keep away from the agent? The only guide that says this outright is Copilot’s. It lists jobs you may want to do yourself rather than hand to the agent: critical issues in production; work that involves security, personal data or authentication; tasks that are poorly defined and topics you want to learn yourself. The other four guides have no such list.

What are the pitfalls of vibe coding?

Two guides also list common mistakes: Claude Code’s has 5 items and Codex’s has 8. Where the two lists overlap: running every job in one long session, not giving the agent a way to check its work, and putting rules in the wrong place (bloating CLAUDE.md, for Claude Code; writing durable rules into every prompt, for Codex). One sentence in Claude Code’s list reads like a summary of this post: “If you can’t verify it, don’t ship it.”

We fell into the five pitfalls below ourselves while working with coding agents in our own repository; after each one, we wrote a rule into our repository’s rules file. They all come from one repository, so they are not a statistic; but each has a real mistake behind it. The questions we ask when the agent says “done”:

• Did the test that passes locally pass in CI too? Our local environment differed from CI in a few places: a .env file read locally, the package installed differently in CI, and a check that runs only in CI. Deleting environment variables didn’t stop the .env file from being read; a missing install option also showed a correct branch as red and led to a wrong diagnosis. Our rule now: a local result is never reported as a CI result, a CI failure is reproduced in a clean clone with no .env, and after a push you look at CI itself.
• Is the result empty because the step ran? In one of our records, a clean run and a run in which some steps had failed looked exactly the same; both left an empty list of findings. Now the record also keeps whether each step ran and how many results it produced, so an empty result and a dead step can be told apart from the record alone. If you see a line in the agent’s code that catches an error and returns an empty list, ask the same question.
• Was a missing value read as 0? One of our reports read a value that was never measured as 0 and wrote “100% saving” next to work that had really been done; the same mistake also silently switched off a check. A value that was not measured should stay None and be read by checking whether the key exists:

# Example: a value that was not measured should be None, not 0
seconds = record.get("seconds") or 0   # wrong: a missing key becomes 0
seconds = record["seconds"] if "seconds" in record else None   # right

or 0 turns both a missing key and None into zero. That zero then goes into an average or a threshold and makes work that was never measured look free or successful.

• Was .env printed to the screen? Once, we printed the .env file masked with sed. Because not every line has the form KEY=value, the mask skipped a line, and the key on it showed unmasked. Now we ask the environment whether a key exists, not the file; the file’s contents are not printed, masked or not. We covered which tools stop the agent from reading secret files in the first place in the sandbox post.
• Does the path, address or package it cites really exist? One of our measurement notes cited as its source a folder that exists on no branch. In a draft that filled in shortened file names, most of the filled-in names were wrong. Now a tool checks that every path in a source line exists on disk; the tool that builds this blog also refuses a source path that can’t be opened. We covered why you should check the packages the agent suggests separately in the review post.

What the five have in common is the gap between “done” and “looks done”. The advice in Claude Code’s guide holds here too: ask the agent for evidence of success, not a claim of it; the command it ran and the output that came back.

Which habits does each kind of job need?

Not every job needs every habit. On a one-sentence fix you can skip the plan; on code that touches user data you can’t skip reading it. Roughly, there are four situations:

Each situation in more detail, plus a few special cases:

• A tool or prototype only you use. As Willison says, if a bug only hurts you, vibe coding is fine. Still, commit often so you can go back, and keep keys in the environment, not in the code.
• A small fix in a real repository. Skip the plan but not the check; the diff is short, so reading it is quick too. If you are fixing a bug, follow the order in Claude Code’s guide: first a test that reproduces the bug and fails, then the fix.
• A multi-file feature or code you don’t know. Plan first, and write a spec for a big job; have the tests written before the code and the change reviewed in a fresh context. We covered when a top-tier model and higher effort make a difference on long, vague jobs in the model selection and effort posts.
• Unattended runs and parallel agents. In auto mode, in a cloud agent or in a scheduled job, there is nobody to ask. Put the check in a hook or in CI, keep permissions narrow, turn the sandbox on, give each agent its own worktree, and at the end ask for evidence, not a claim. We covered permissions and the sandbox in the auto mode and sandbox post.
• User data, logins, payments and secrets. Write the security requirements into the prompt explicitly; in Andročec’s study, adding just that reduced the findings in every app. But the most serious finding was still caught by manual testing: have a person read this code.
• Before you open a vibe-coded app to everyone. The vulnerabilities Deng and colleagues found sit mostly in access control and authentication. Try it yourself: can one user see another user’s data, and can a protected page be reached without logging in?
• A repository you don’t know. Before you open it with an agent, look for files in it that can run on their own; we covered which ones in the workspace trust post.