You ship faster with a model in your editor. You also ship more defects, and the gap is wider than most teams assume: one study put the bug rate increase at 41% after teams adopted AI coding tools, and security flaws turn up roughly 2.74x more often in AI assisted code.
That is not an argument for turning the tools off. Around 95% of code reaching production now contains AI assisted content, so the real question stopped being whether you use them. It became how you stop quality from quietly draining out while you enjoy the speed.
Here is what the data actually says, why it happens, and the five practices that hold the line without putting you back on the slow path.
Vibe coding is the habit of describing what you want, accepting whatever the model writes, and judging the result by whether it runs. Prompt, run, prompt again. No line by line read of the diff.
It feels incredible. A feature that used to eat an afternoon lands in twenty minutes. Cursor, Copilot and Claude Code all got good enough at the same time that the friction of writing code dropped below the friction of reviewing it, and that inversion is the whole story.
Because when writing gets cheap and reviewing stays expensive, people write more and review less. Not out of laziness. Out of arithmetic. A tool that produces 300 lines in one shot does not produce 300 lines of review attention alongside it, and nobody budgeted for the difference.
The number that keeps getting quoted is Uplevel's: teams that adopted AI coding tools saw a 41% increase in bug rates. The mechanism identified was over reliance, developers taking suggestions without enough review behind them.
CodeRabbit's research points the same direction from a different angle. AI assisted codebases carried 1.7x more issues per pull request than human only code. Not per line. Per pull request, which is the unit your team actually reviews, so the extra load lands squarely on whoever is doing the reading.
Sit with that second number for a second, because it explains the first one. If every PR now carries almost twice the issues, and your review process did not change, your review process is now catching a smaller fraction of what is there. The bugs are not appearing out of nowhere. They are walking through a gate that was sized for a different volume.
What makes this hard to notice is that the failures are boring. Not exotic model hallucinations. An error path that swallows the exception. A null check that reads correctly and is placed one branch too late. Code that passes review because it looks like code you would have written, which is exactly what these models are optimised to produce.
Static analysis across enterprise repositories found security vulnerabilities roughly 2.74x more prevalent in AI assisted code than in manually written code. That multiplier is the one worth taking to your lead, because security defects have a cost curve nothing else in this list matches.
Why security specifically? A model writes what is statistically typical for the surrounding context. Typical code on the public internet includes a lot of tutorial grade shortcuts: string concatenation into queries, permissive CORS, secrets read straight from a literal, validation that trusts the shape of an object because the type annotation said so. None of it looks wrong. All of it is a footgun in a real deployment.
The model also has no idea where your trust boundary sits. It cannot know that this particular handler is reachable without auth, or that this input crossed the network two frames ago. That context lives in your head and in your architecture, and it is precisely the context that decides whether a piece of code is fine or a hole.
Type systems do not save you here either. Type safe code can be perfectly type safe and still authorise the wrong user.
Ask a room of engineers whether AI tools make them faster and almost every hand goes up. Ask whether the code is better and the hands drop. Both answers are honest, and they are not in conflict.
The trust holds because the failure mode is delayed. You feel the speed instantly, in the same session. You feel the defect three weeks later, in an incident channel, usually attributed to something else entirely. Nothing in that loop connects the two events, so the feedback that would calibrate your trust never arrives.
Trust breaks in exactly one situation: the first time someone traces a production incident back to a block of code nobody on the team can explain. Not because it is complicated, but because no human ever really read it. That moment lands differently than any statistic, and it is the moment most teams finally add gates.
You do not need to wait for it.
None of these ask you to write less with AI. They move the cost from your future incident channel to your current pipeline, where it is cheaper.
1. Read the diff like it came from a stranger. Not the prompt. Not the explanation the model gave you. The diff. If you would send it back when a contractor you had never met submitted it, send it back now. The strongest version of this rule is a personal one: never merge code you could not defend in an incident review.
2. Make static analysis blocking, not advisory. A SAST tool that posts a comment gets ignored inside a week. One that fails the build gets fixed. Given a 2.74x security multiplier, this is the single highest leverage change on the list.
name: security
on: pull_request
jobs:
sast:
runs-on: ubuntu-latest
container:
image: semgrep/semgrep
steps:
- uses: actions/checkout@v4
- run: semgrep ci --config auto --error
3. Cap the blast radius per pull request. Review quality falls off a cliff past a few hundred changed lines, and AI makes large diffs trivially easy to produce. Put a real limit in front of yourself:
#!/usr/bin/env bash
set -euo pipefail
BASE="${BASE_BRANCH:-origin/main}"
LIMIT="${DIFF_LIMIT:-400}"
changed=$(git diff --numstat "$BASE"...HEAD \
| awk '{ added += $1; removed += $2 } END { print added + removed + 0 }')
if [ "$changed" -gt "$LIMIT" ]; then
echo "Branch changes ${changed} lines, limit is ${LIMIT}."
echo "Split it, or push with DIFF_LIMIT=$((changed + 1)) if you have a reason."
exit 1
fi
4. Test the boundaries the model cannot see. Auth, authorisation, input validation, error paths, resource cleanup. A model writes the happy path beautifully because the happy path is what most public code demonstrates. Write those tests yourself, or at minimum write the test names yourself so the shape of the contract comes from you.
5. Track one quality signal per pull request. Issues found in review, escaped defects, whatever your team already counts. You cannot manage a 41% drift you never measured, and the whole danger of this failure mode is that it is invisible month to month. A single number, tracked over eight weeks, tells you more than any benchmark someone else published.
The pattern underneath all five: the model generates, and a gate that does not get tired verifies. Human attention is the scarce resource now, so spend it on the parts machines cannot check.
semgrep ci --config auto
against your main branch and count the findings. That is your current baseline, whether you knew it or not.git diff --numstat
. If the median is over 400 lines, your review process is already running past its limit.Does AI generated code introduce more bugs?
The available data says yes. One study measured a 41% increase in bug rates after teams adopted AI coding tools, and separate research found 1.7x more issues per pull request in AI assisted codebases. The cause identified in both cases is reduced review depth rather than the model producing nonsense.
What is vibe coding?
Describing what you want to a model, accepting the generated code, and validating it by running it rather than reading it. It works well for prototypes and throwaway scripts. It degrades badly once the code has users, because "it runs" and "it is correct" stop being the same claim.
How do you maintain code quality when using AI tools?
Move verification into automation and keep human attention on judgment. Blocking static analysis, small reviewable diffs, tests you wrote for the boundaries the model cannot see, and one tracked quality metric will cover most of the gap. The tools are not the problem. An unchanged review process running at several times its designed volume is.
If you want a deeper look at how these gates fit into an AI system you actually run in production, I cover it in more detail on my site.
If you want this wired up on your own codebase end to end, that is exactly the kind of work I take on.
Drop a comment if your setup looks different. Curious what gates people are actually running, and which ones survived contact with a deadline.