There is a version of the story about AI and software development that goes like this: AI writes the code, humans review the output, everything ships faster, everyone wins. Quality is not compromised — it is enhanced, because AI does not make the tired human errors.
This version is attractive. It is also dangerously incomplete.
AI coding tools are genuinely transformative. The speed gains are real. The accessibility — enabling people with limited engineering backgrounds to build working software — is real. But the risks that come with AI-assisted development are also real, and they are different in kind from the risks that existed before.
The teams that use AI coding tools well are not the ones that trust the output and ship it. They are the ones that have invested in the QA processes and review disciplines that catch what AI reliably gets wrong — and what humans reviewing AI output systematically miss.
What Has Changed
To understand why QA and auditing matter more in an AI-assisted development environment, it helps to understand what specifically has changed.
The Volume Problem
AI tools generate code significantly faster than humans write it. A task that used to take a developer a day might now take two hours. This is the headline benefit. The less-discussed consequence is that the volume of code entering review, entering testing, and entering production has increased — without a proportional increase in the human capacity to validate it.
When one engineer produces twice as much code, the review process does not automatically become twice as thorough. It typically becomes faster per unit of code, which means less scrutiny per line, which means more slips through.
The Confidence Problem
AI-generated code looks authoritative. It is syntactically clean. It follows recognisable patterns. It compiles. It often passes surface-level tests. This creates a confidence that the output is correct that is not always warranted.
The subtle bugs in AI-generated code — the off-by-one in a financial calculation, the missing edge case in an authentication flow, the race condition in a concurrent operation — are not visible in the code's appearance. They require deliberate, rigorous testing to find. But the clean appearance of the code reduces the reviewer's alertness to look.
⚠️Watch Out
Code that looks correct and code that is correct are not the same thing. AI tools optimise heavily for the former. The latter requires human verification — and the cleaner the code looks, the less natural it feels to question it.
The Understanding Gap
The most dangerous aspect of AI-assisted development is not bad code — it is code that works but that the engineer does not fully understand.
When an engineer writes code themselves, they have a mental model of how it works, why each piece is there, and what could go wrong. When an engineer takes AI-generated code and ships it without fully understanding it, they have working software but no model of its failure modes.
This matters when something goes wrong in production. Debugging code you do not understand is dramatically harder than debugging code you wrote. It matters when requirements change — modifying code whose logic you cannot fully trace is risky. And it accumulates silently: a codebase where large portions were generated and accepted without deep understanding is a fragile asset.
The Systemic Consistency Problem
AI tools generate code in response to prompts. They do not have full context of the rest of the system, the team's architectural decisions, the security model, the performance constraints, or the business rules that have been encoded elsewhere.
Each AI-generated piece can be individually reasonable while being inconsistent with the rest of the system. Error handling that works differently in different parts of the codebase. Authentication checks that are present in some flows and absent in others. Data validation that is inconsistent between the API layer and the database layer.
These inconsistencies are the kind of vulnerability that manual code review and systematic audit find — not automated tests, which test that the code does what it appears to do, not that it is consistent with what the rest of the system expects.
What Vibe Coding Is and Why It Matters
"Vibe coding" is the informal term for an approach to software development where the engineer describes what they want, accepts the AI output largely as-is, and iterates by feel — adjusting until the visible behaviour seems right, without deeply engaging with the underlying implementation.
For certain contexts — personal projects, rapid prototypes, internal tools with limited scope — this is genuinely fine. The risk is proportional to the stakes.
For production software that handles user data, financial transactions, or business-critical operations, vibe coding creates a category of risk that the team typically does not know it is carrying. The code appears to work. Users can interact with it. The developer believes it does what they intended. And somewhere in the generated implementation is an assumption, a missing check, or an edge case that will eventually manifest as an incident, a vulnerability, or a data integrity failure.
💡Key Insight
The gap between "the software does what I demonstrated to myself in testing" and "the software correctly handles every realistic condition it will encounter in production" is exactly where QA lives. AI tools have narrowed the former and widened the latter — by accelerating code generation while leaving unchanged the discipline required to close that gap.
The Specific Risks to Test For
AI coding tools have characteristic failure patterns. Testing and auditing disciplines that are aware of these patterns catch far more than generic review processes.
Security Vulnerabilities in Generated Code
AI tools are trained on public code repositories. Public code contains insecure patterns — SQL injection vulnerabilities, improper input validation, insecure cryptographic implementations, hardcoded credentials, insufficient access control checks. AI tools reproduce these patterns, sometimes in code that looks completely reasonable.
The OWASP Top 10 — injection attacks, broken authentication, sensitive data exposure, broken access control, security misconfiguration — are all categories where AI-generated code has known failure modes. Automated static analysis tools (SAST), dependency vulnerability scanning, and deliberate security-focused code review are not optional hygiene in an AI-assisted codebase. They are the primary defence.
Business Logic Errors
AI tools are excellent at implementing patterns they have seen. They are poor at implementing business logic that is specific to your context and has no training corpus to draw from.
"Apply our tiered discount logic, which is described in this document" produces code that looks right and handles the obvious cases. It reliably misses the edge cases in the business rule — the interactions between discount types, the rounding behaviour at tier boundaries, the special cases that accumulated over years of business operation.
This category of error is caught by integration testing against real business scenarios, not by unit tests that verify the code's implementation of the AI's interpretation of the requirement.
Concurrency and Race Conditions
Concurrent operations — multiple users modifying shared state simultaneously, background jobs that interact with user-facing operations, event-driven flows with interleaved execution — are one of the hardest categories of bugs to produce correctly, and one of the categories where AI-generated code most commonly introduces subtle defects.
Race conditions do not appear in unit tests. They appear in production under load, in ways that are extremely difficult to reproduce and debug. Deliberate concurrency testing and code review specifically focused on shared state and locking behaviour are the defences.
Data Integrity Issues
AI-generated database interaction code frequently has subtle data integrity gaps: missing transactions around operations that should be atomic, optimistic locking that does not handle the conflict case correctly, cascade behaviour that was not considered when writing the query.
These produce data corruption that is often not immediately visible — it accumulates quietly and is discovered when a user reports incorrect data, an audit finds inconsistencies, or a backup is needed and turns out to be corrupt.
★Remember This
The categories of bugs that AI coding tools most reliably introduce are the same categories that conventional automated testing most reliably misses — because those tests verify that the code does what the developer intended, and the developer's intention was informed by the AI output they accepted.
What QA Looks Like in an AI-Assisted Team
Effective QA in an AI-assisted development environment is not just more of the same QA practices — it is QA specifically designed for the characteristic risks of the environment.
Mandatory Security Scanning in CI
Every commit, every pull request: automated security scanning. SAST tools (Semgrep, CodeQL, Snyk Code) that flag known vulnerability patterns. Dependency scanning that catches known-vulnerable packages. Secret detection that catches credentials in code.
These tools are not perfect. They produce false positives. But the false positives are a tractable problem — a few minutes of triage per run. The false negatives from not running them are not tractable — they are production incidents and security breaches.
Review for What AI Does Not Know
Code review in an AI-assisted team needs a specific additional focus: is this implementation consistent with the rest of the system? Does it follow the security model? Does it handle errors in the same way as adjacent code? Are there business rules encoded elsewhere that this code needs to be aware of?
This is qualitatively different from reviewing whether the code is correct in isolation. It requires reviewers who have enough context of the broader system to spot inconsistencies — which is an argument for not having the same person who prompted and accepted the AI output also be the sole reviewer.
Integration Testing on Real Business Scenarios
Unit tests that verify the AI-generated code behaves as the developer expects are necessary but insufficient. Integration tests that run against realistic business scenarios — including the edge cases in business rules, the concurrent user patterns, the volume levels that expose performance issues — are where the characteristic AI errors surface.
Write integration tests for the business scenarios that matter most: the core transaction flows, the permission boundaries, the data consistency invariants that underpin trust in the system.
→Practical Tip
For each significant feature built with AI assistance, ask: what are the three ways this could silently corrupt data or expose user information? Write a test for each one. Not "does the happy path work" — "does the unhappy path fail correctly, and does it fail safely?"
Periodic Code Audits
A one-time review at launch is not sufficient for a codebase that continues to evolve with AI assistance. Periodic audits — quarterly for high-risk systems, semi-annually for lower-risk ones — catch the drift: inconsistencies that accumulate over time, security posture that degrades as new code is added without reference to existing security patterns, technical debt that AI assistance has accelerated.
An external audit is particularly valuable because it brings reviewers who have not been shaped by the same prompt patterns and acceptance biases as the internal team. Fresh eyes catch what familiarity misses.
The Business Case for Investing in QA
For businesses using AI tools to accelerate development, there is sometimes a temptation to treat the time saved as pure margin — spend less time on testing, on review, on quality processes, because the AI has already done the careful work.
This framing has the causality backwards. AI assistance reduces the time cost of writing code. It does not reduce the consequence of shipping broken code. The cost of a security breach, a data loss incident, or a production failure that corrupts financial records is entirely unchanged by how the code that caused it was written.
If anything, AI-assisted teams should invest proportionally more in QA — because they are shipping more code, faster, with a higher probability of characteristic AI failure modes in each unit.
💡Key Insight
The productivity gain from AI assistance is a resource to be allocated. One legitimate allocation is "ship more features." Another is "ship the same features with meaningfully better quality assurance." The right allocation depends on where you are in your product lifecycle — but do not assume that faster shipping and adequate quality are automatically compatible without deliberate investment in the latter.
Building a QA Culture That Fits AI-Assisted Development
Tools and processes catch bugs. Culture determines whether those tools and processes are actually used under deadline pressure, when the code looks fine, when everyone is tired.
The cultural norms that matter most in an AI-assisted team:
AI output is a draft, not a decision. The engineer who accepts generated code owns that code — its correctness, its security, its fitness for the production system. Framing AI output as a draft that requires human judgment and responsibility avoids the diffusion of accountability that produces incidents.
Understanding is not optional. An engineer should be able to explain every significant piece of code they ship. If they cannot explain it, they should not ship it until they can. This norm needs to be explicit, enforced in code review, and backed by a culture that does not penalise the time spent on understanding.
Test the failure modes, not just the happy path. Review culture that asks "does this code do what we want?" is necessary. Review culture that also asks "how does this code fail, and is the failure safe?" is sufficient. Build the second question into review templates, on-call runbooks, and incident retrospectives.
Quality gates are not optional under pressure. Security scanning, code review, and integration tests that are skipped when deadlines loom do not meaningfully improve quality. The value of quality gates is precisely their consistency — a gate that is bypassed when it is most inconvenient is a gate that fails at the moments of highest risk.
★The Principle
AI coding tools change the economics of writing software. They do not change the economics of running software. The consequences of production failures — customer trust, financial liability, regulatory exposure — are entirely unchanged. The investment in QA should reflect the consequences of shipping, not the ease of building.
Practical Starting Points
If your team is using AI coding tools without a corresponding QA investment, these are the highest-leverage starting points:
This week: Enable Semgrep or CodeQL in your CI pipeline. Most are free for open-source and reasonably priced for private repositories. Any pull request that introduces a known vulnerability pattern will be flagged automatically.
This month: Establish a code review norm that explicitly asks: "Do you fully understand this code?" For AI-assisted PRs, add a checklist item: security implications considered, error handling consistent with codebase, business logic edge cases tested.
This quarter: Write integration tests for your three most business-critical flows — the paths where data corruption, security failure, or downtime would cause the most harm. These are the tests that catch what unit tests miss.
This half: Commission an external code audit focused on security and data integrity. Particularly if your product handles financial transactions, user personal data, or health information, an external review by engineers who are specifically looking for AI characteristic failure modes provides assurance that internal review cannot fully replicate.
The speed that AI coding tools unlock is genuinely valuable. Protecting that value — ensuring what ships is as reliable and secure as the speed it was built with — is what QA and code audits exist to do.
If you want help setting up a QA process that fits an AI-assisted team, or want an independent audit of a codebase built with significant AI assistance, let's talk.