Vibe coding: how AI-assisted development works

Vibe coding means describing what you want in plain language and letting an AI tool write the code, judging the result mostly by whether it runs rather than by reading every line. It’s fast and genuinely useful for prototypes and throwaway tools. For software other people depend on, it needs the same review, tests and ownership as any other code.

The term comes from Andrej Karpathy, who used it in February 2025 to describe giving in to the AI and barely looking at the code (background on Wikipedia). Since then it has stretched to cover almost any AI-assisted development, which causes confusion. It helps to separate two things: AI-assisted development, where engineers use AI tools but stay responsible for the code, and vibe coding in the original sense, where nobody really reads it.

How does AI-assisted development actually work?

You give a coding tool a task in plain language, it reads the relevant parts of your codebase, proposes changes across one or more files, and often runs tests or commands to check its work. You review, correct and iterate. The skill shifts from typing code to specifying tasks clearly and judging the output.

A typical loop looks like this:

1. Describe the change, with constraints: language and framework versions, conventions, what not to touch.
2. Let the tool plan, then read the plan before it writes anything substantial.
3. Let it implement, run the tests and fix failures.
4. Review the diff as you would a colleague’s pull request, then commit with a clear message.

Which tools are people using?

The main categories are AI-native editors such as Cursor and Windsurf, terminal and IDE agents such as Claude Code, and assistants built into existing editors such as GitHub Copilot. They overlap more every quarter. The choice matters less than the habits around it: review, tests and clear instructions in the repository.

• AI-native editors suit developers who want suggestions and multi-file edits inside a familiar editor.
• Terminal and IDE agents suit larger tasks: refactors, test writing, dependency upgrades, and anything that involves running commands. Our guide to using Claude Code across the SDLC covers this category in depth.
• Prototype builders generate whole small apps from a prompt. They’re great for demos and poor at long-term maintenance.

Where does vibe coding work well?

Prototypes, internal tools, one-off scripts, spikes to test whether an approach is feasible, and boilerplate such as forms, CRUD screens and test scaffolding. In short: code that’s cheap to throw away, or code where a mistake is visible immediately and harmless.

It’s also good for learning an unfamiliar library: ask for a working example, then read it carefully. The learning happens in the reading, not the generating.

Where does it go wrong?

In code that handles money, personal data, authentication or permissions, in systems with subtle concurrency or performance requirements, and anywhere nobody on the team understands the generated code well enough to fix it at 2am. AI tools write plausible code, and plausible isn’t the same as correct.

The failure patterns are predictable:

• Security holes such as missing authorisation checks or unsafe query construction that look fine at a glance.
• Duplicated logic, because the tool didn’t find the helper that already exists.
• Tests that pass because they test the wrong thing, sometimes written by the same tool that wrote the bug.
• Dependencies added casually, including outdated or unnecessary ones.
• A codebase nobody can explain six months later.

How should a team use AI coding tools on production code?

Keep a human accountable for every change, review AI-written code at least as carefully as human-written code, require tests for new behaviour, and write your conventions down in the repository so the tool follows them. Decide in advance which code must never be written without careful human review, such as authentication and payments.

• Same review bar. Pull requests are reviewed on their merits, regardless of who or what wrote them.
• Repository instructions. A file describing architecture, conventions and forbidden patterns improves output a lot. Most tools now read one automatically.
• Tests and CI. Automated tests, linting and security scanning in the pipeline catch much of what review misses.
• Data rules. Agree which repositories and data may be sent to which AI services, and use business or enterprise plans where training on your code is switched off.
• Client consent. If you work on someone else’s code, as we do, agree with them which tools may be used on it.

Does it make development cheaper?

It makes some tasks much faster, mainly boilerplate, tests, migrations and first drafts, and barely helps with others: unclear requirements, tricky integrations and debugging production issues. Overall savings depend on the mix of work and on how disciplined the review is. Be sceptical of anyone promising a fixed percentage.

For budgeting, assume tools speed up implementation but not discovery, decisions or testing with real users. Our post on MVP development cost explains how we price builds.

Is vibe coding a threat to junior developers?

It changes how juniors learn rather than removing the need for them. Someone who only prompts never builds the judgement to spot bad output. Juniors still need to write and debug code by hand regularly, and to have their AI-assisted work reviewed by someone more experienced.

What’s our view?

AI coding tools are now part of normal engineering work, and refusing them is as odd as refusing an IDE. But the rule that matters hasn’t changed: code goes to production only when someone on the team understands it and it has passed review and tests. On client code, which tools are allowed is the client’s decision. If you want help setting up those practices, or need engineers who already work this way, see our staff augmentation and AI and ML engineering services.

Frequently asked questions