Vibe coding is the phrase of the year and the practice almost nobody admits to. In the Stack Overflow 2025 Developer Survey, 72% of respondents said vibe coding is not part of their professional work, and another 5% rejected it emphatically. The headline trend is real, but it lives on social feeds more than in commits.
That gap matters because adoption of AI tooling itself is not in doubt. The same survey found 84% of developers use or plan to use AI tools, up from 76% a year earlier, and 51% of professionals reach for them daily. The disagreement is not about whether to use AI. It is about how much to trust it.
The trust gap is widening
Sentiment actually fell as usage rose. Favourable views of AI tools dropped from above 70% in 2023 and 2024 to about 60% in 2025. More developers now distrust the accuracy of AI output (46%) than trust it (33%), and only 3% say they highly trust it. Experienced developers are the most sceptical, which fits people who carry accountability for what ships.
Almost right is the expensive part
The single most cited frustration, shown in the chart above, is "AI solutions that are almost right, but not quite," reported by 66% of developers. The knock-on effect lands second: 45% say debugging AI-generated code costs them more time than writing it themselves would have.
| Frustration with AI tools | Share of developers |
|---|---|
| Almost right, but not quite | 66% |
| Debugging AI code takes longer | 45% |
| Do not use AI tools regularly | 24% |
| Less confident in my own problem solving | 20% |
| Hard to understand how the code works | 16% |
What developers still want a human for
Asked what they would do in a future where AI handles most coding, 75% said they would still ask a person "when I don't trust AI's answers." Human review is not a nostalgia item. It is the control that makes fast generation safe to merge, the same pattern we saw in agents that need a hard stop.
The takeaway is narrow and practical. Vibe coding is a fine way to explore. It is a poor way to ship without a reviewer who reads every line. For the full breakdown, see the Stack Overflow 2025 survey.
Why professionals draw the line at production
Professional developers are paid for the behavior of the system after the pull request merges. That accountability changes how AI-generated code feels. A demo can tolerate a missing edge case. A production service has users, data, security boundaries, uptime targets, and future maintainers. Code that is almost right can still create an incident.
This is why experienced developers are often more skeptical than beginners. They have seen bugs hide in migrations, retries, permission checks, date handling, and error paths. AI tools are good at producing plausible main paths. They are less reliable at knowing which local constraint makes the main path unsafe.
Vibe coding also weakens shared understanding if the author cannot explain the change. A team can maintain code it understands. It struggles with code that arrived as a large generated patch and no clear design rationale. The cost shows up later, when someone has to debug or extend it.
Where AI coding does work
The survey should not be read as a rejection of AI coding tools. Developers use them because they help. They are useful for boilerplate, test scaffolds, small refactors, translation between APIs, documentation drafts, regular expressions, and first-pass explanations of unfamiliar code. Those tasks are bounded and easy to verify.
The success pattern is human-led. The developer decides the design, constrains the task, inspects the diff, runs the tests, and owns the result. AI shortens the path through known work. It becomes risky when it is asked to choose the path, write the change, and prove the change without enough context.
That distinction explains the adoption data. Daily AI use can rise while vibe coding remains rare because many developers have found a middle ground. They use AI as an assistant, not as an unchecked author of production behavior.
How teams can make generated code reviewable
Teams that want AI coding benefits should design for review. Keep generated changes small. Require a clear problem statement, a list of touched files, and a validation command. Ask the tool to preserve local conventions and avoid broad refactors unless the task explicitly requires them. Those rules make the output look more like normal engineering work.
Reviewers should focus on boundaries: inputs, permissions, errors, migrations, concurrency, observability, and rollback. These are the places where plausible code often fails. Unit tests help, but production confidence usually needs a slice of integration coverage or a focused manual check as well.
Organizations can also track whether AI-generated changes take longer to review or produce more follow-up fixes. That data is more useful than counting lines generated. The goal is not to maximize AI output. The goal is to reduce time to safe, understandable, maintainable code.
The cultural signal
Vibe coding became loud because it captures a real feeling: software can now be produced by describing intent. The professional backlash is also real because software engineering has never been only production of text. It is the work of making systems reliable under constraints.
The interesting future is not a binary choice between hand-written code and fully delegated code. It is a workflow where generation is cheap, review is explicit, and accountability remains clear. That is less viral than the phrase, but it is much closer to how production teams adopt tools that last.
