What vibe coding is
In February 2025, AI researcher Andrej Karpathy described a new way of building software: you describe what you want in plain language, an AI model writes the code, and you steer by trying the result rather than reading every line. He called it vibe coding. By November, Collins Dictionary had made it its word of the year.
The name sounds casual, and for a while it was used as an insult: code nobody understands, built by people who aren't engineers. We think that misses what's actually happening. Vibe coding is the fastest way yet to turn an idea into something a person can click, and that is enormously valuable, as long as everyone is clear about what it produces.
It's already how software gets made
AI-written code isn't a fringe experiment any more. The numbers from the last eighteen months are hard to argue with:
- 84% of developers use or plan to use AI tools in their work, up from 76% a year earlier, in Stack Overflow's 2025 survey of more than 49,000 developers.
- 75% of new code at Google is now generated by AI and then reviewed by its engineers, the company said in April 2026, up from about half the previous autumn.
- About a quarter of Y Combinator's Winter 2025 startups had codebases roughly 95% written by AI, according to YC's CEO.
- GitHub Copilot passed 20 million users in July 2025.
- By 2028, 40% of new enterprise production software will be created with vibe coding techniques and tools, Gartner predicts.
Notice the second line. Google isn't shipping unreviewed AI code: an engineer approves it. Hold on to that, because it's the whole argument of this article.
Where the value really comes from
The obvious win is speed: a working screen in an afternoon instead of a sprint. The bigger win is less obvious. Most of the time lost on a software project isn't spent typing code. It's spent going back and forth: a stakeholder describes what they need, product writes it up, engineering builds its reading of it, the stakeholder sees it and says that's not quite it, and the loop starts again.
Vibe coding short-circuits that loop. The person who knows the problem best can show what they mean instead of describing it. A sales lead can mock up the quoting screen they've wanted for years. An operations manager can build the dashboard they keep asking for. What used to be three meetings and a requirements document becomes a working example everyone can react to the same day.
That's why it has spread so quickly through businesses of every size. It puts building in the hands of the people closest to the problem, and it lets engineers start from something real instead of a guess.
Why some engineers push back, and why we disagree
Plenty of engineers are skeptical, and some of the skepticism is earned. In the same Stack Overflow survey, 46% of developers said they distrust the accuracy of AI tools, and the top frustration, named by 66%, was AI answers that are almost right, but not quite. In Veracode's 2025 tests of more than 100 models across 80 coding tasks, the AI chose an insecure way of writing the code 45% of the time when a secure one was available.
Those are real risks. But look at what they're risks of: AI code going into production without anyone checking it. That's not an argument against vibe coding. It's an argument for review, the same review we'd give any code before it touches customers or company data.
Part of the pushback is also about the job itself, and that's understandable: the work is changing. We don't think vibe coding takes the engineer's job away. It moves engineers to where they matter most: architecture, security, data, testing and running systems reliably. The typing was never the valuable part. Judgment is, and AI hasn't replaced it.
Vibe coding and engineering do different jobs
| Vibe coding | Engineering | |
|---|---|---|
| Best for | Prototypes, internal tools, trying an idea | Systems customers and the business depend on |
| Speed to first version | Hours or days | Weeks |
| Who can do it | Anyone who knows the problem | Engineers |
| Security and access control | Whatever the AI happened to choose | Designed, tested and reviewed |
| Infrastructure | Often a single hosted demo | Environments, backups, monitoring, scaling |
| Maintenance | Hard to change safely | Tested, documented, handed over |
The mistake isn't using vibe coding. It's treating its output as finished. The best teams use both: vibe coding to discover what to build, engineering to make it production-grade.
How we take vibe-coded work to production
We encourage vibe coding, inside our own team and on our clients' teams. Our rule is simple: anything vibe coded is hardened and reviewed by an engineer before it goes to production. If it meets the requirements and criteria the business set, it doesn't matter who or what typed it. In practice that review covers:
- Requirements and acceptance criteria. We write down what the prototype is meant to do, so there is something concrete to test it against.
- Security. Sign-in and permissions, secrets kept out of the code, every input validated, dependencies scanned for known vulnerabilities. Our security work starts here.
- Infrastructure. Proper environments for development, testing and production, backups, logging and monitoring, so problems are seen before customers see them.
- Code quality. An engineer reads the code, simplifies it, removes what isn't needed and brings it in line with good practice, so it can be changed safely later.
- Tests. Automated tests around the parts that matter, so the next change doesn't quietly break the last one.
- Data and integrations. Connections to the systems the business already runs, built to handle errors and retries instead of assuming everything works.
- Handoff. Documentation, so your team can run and change what we built.
Sometimes the prototype's code survives almost intact. Sometimes we keep the design and rebuild what's underneath. Either way, the stakeholder's prototype has done its most important job: everyone agreed on what to build before the expensive work started.
What this means for your team
If someone on your team has built something with an AI tool and you're wondering whether it can go live, it probably can, with the right review first. Bring it to a free discovery call (opens in a new tab). We'll look at what it does, what it would take to make it production-ready, and give you a written recommendation. If you'd rather have that engineering on your own team, we can embed a senior engineer who hardens and reviews this work as it's built.