QA for AI-Generated Code: Risk Governance

In April 2026, a financial firm reportedly disbanded a twelve-person QA team to save around $1.2 million a year, replacing it with automated testing. A faulty discount code then set product prices to zero and cost roughly $6 million — as reported by QA Financial and summarised by Resultsense. The firm was not named, so treat the figures as a reported cautionary case rather than a verified ledger. The lesson, though, is hard to argue with: when you remove the people who understood the system, the savings can unwind in a single release.

The industry consensus that has formed around incidents like this is short: augmentation, not automation. AI belongs in QA — aggressively, on repetitive and data-heavy work — but not as the signatory of production risk.

Here is the shift in one sentence: with assistants like GitHub Copilot, Cursor, Claude Code and OpenAI Codex, your developers now produce far more code, far faster, than any manual QA process can keep up with. That does not make QA optional. It changes what QA is for.

Where QA sits: Developer, CI, QA, Production, Monitoring, with a feedback loop back to Developer

QA’s job is shifting from finding bugs to governing risk

AI lowered the cost of producing code. It did not lower the cost of deciding whether that code is correct, safe and compliant. So QA moves up the value chain: from running test cases toward owning test strategy, risk classification, the evaluation of AI behaviour, and the evidence a regulator or customer will ask for.

This post is the QA half of a pair. The developer-side checklist — local gates, tests from requirements, treating generated code as untrusted — lives in Testing AI-Generated Code: A Developer’s Checklist.

What QA sees that code review can’t

Code review looks at implementation. QA looks at behaviour. A reviewer can confirm a Flutter widget or a C# service is reasonable; a tester asks what the assistant never optimised for:

What happens after the user taps twice?
What happens when the network drops mid-request?
What happens when the OS kills the app in the background?
What happens to old local data after an upgrade?
What happens when the API returns an unexpected value?
What happens when two users edit the same object?
What happens when permissions change during the workflow?

AI optimises for the requested happy path. Real users do not stay on it.

Mobile multiplies the risk

Shared code reduces duplication; it does not remove platform-specific behaviour. The same AI-generated implementation can be correct on Android and wrong on iOS.

Risk area	Where AI-generated code tends to break	QA focus
Lifecycle	Background termination, restore-from-state timing	Interrupt and resume on real devices
Permissions	Different Android/iOS models, runtime revocation	Denial and revocation paths
Connectivity	Optimistic success, missing retry, no offline path	Flaky-network and offline simulation
Platform APIs	Filesystem, notifications, BLE, camera, plugins	Per-platform validation, not shared-code assumptions
Upgrades	Data migrations, schema changes between versions	Install-then-upgrade regression on prior releases

Run regression on critical workflows even when the assistant claims a change is unrelated, and reserve time for exploratory testing — a human deliberately trying unexpected sequences, invalid data and interruptions.

Testing the AI feature itself

If the app ships an AI feature — an assistant that generates instructions, summaries or replies — you also have to test the model’s output, not just the code around it. A probabilistic component cannot be covered by static pass/fail tests alone.

This is genuinely new. Traditional software is deterministic: the same input produces the same output, so a test can assert an exact result. An LLM can return a different — and often equally valid — answer to the identical prompt every time it runs. Exact-match assertions break against that, which is why evaluation moves from string comparison to semantic scoring and thresholds.

A practical pattern is an automated evaluator, often called LLM-as-a-judge: a separate model scores each response for coherence and safety, and anything below a threshold is flagged for human review.

# Score assistant responses before release; fail the build on regressions
python evaluate_responses.py --suite golden_prompts.yaml \
  --judge-threshold 0.8 --compare-baseline baseline_scores.json

Keep a small “golden set” of real and adversarial prompts in version control, and grow it every time production surfaces a new failure. This blend of AI generation, human curation and automated evaluation is how a small QA team scales coverage without pretending the output is deterministic.

We saw why this matters on a lead-capture feature: an OCR step read business cards and an LLM enriched the contact before it reached the CRM. In testing, the model would occasionally invent a plausible job title that appeared nowhere on the card, and now and then return JSON that broke the import. Neither failure lived in the code — both were in the model’s output, and we only caught them by scoring responses against a golden set, not by reading the implementation.

Security, privacy and the evidence an audit needs

QA increasingly owns the proof that AI behaviour is controllable:

Traceability for debugging. When you consume a hosted LLM through an API, you can’t crack it open to see why it answered the way it did. Explainability comes from tracing instead: log the full prompt, any retrieved context, the model and its version, and the evaluator’s rationale, so a bad answer can be explained rather than guessed at. (Feature-attribution tools like SHAP or LIME help understand a model’s decisions — useful when you train or fine-tune your own model, not when you only call a hosted one.)
Compliance evidence. Link each test result to the specific model version and dataset, and keep auditable logs.
Data privacy. Avoid sending personally identifiable information to third-party models; pseudonymise test data where you can.
Bias and fallback. Test AI features for harmful or biased output and accessibility barriers, and define a safe fallback when the model misbehaves.

This is becoming a dated obligation, not just good practice. As of June 2026, the EU AI Act has been in force since August 2024, with most obligations and transparency rules applying from 2 August 2026; under the May 2026 “Digital Omnibus” agreement, several high-risk timelines were deferred toward late 2027. The direction is clear — AI behaviour will need to be documented, explainable and auditable. (Regulatory dates change; confirm the current text before acting on compliance.)

Risk-based QA when capacity is limited

Few teams have unlimited testers, so spend the hours where failure hurts most:

Protect the critical paths — authentication, payments, permissions, data sync, account deletion, subscriptions, BLE or device commands. Test these first and often.
Classify by impact. A text-alignment change does not need the same process as a payment flow or a database migration.
Require test evidence in every pull request, so QA reviews the analysis instead of recreating it.

Will AI replace QA?

AI is a co-pilot, not a replacement. Adoption of AI in testing still lags adoption in development, which creates a testing gap — and the more code is automated, the more oversight each change needs. The job description is changing, not disappearing: QA engineers curate prompts and golden sets, monitor probabilistic behaviour, interpret metrics and own the quality and compliance bar.

Even at the largest banks, the message is that human oversight stays essential so teams can intervene when something is off. AI can generate an answer; QA decides whether it is the right one. That is quality architecture, and it is the question every business should be able to answer: who signed off the last change to a critical user journey?

How MaboaSoft helps

MaboaSoft builds and modernises production mobile apps in Flutter, native iOS, native Android, Xamarin and .NET MAUI. Our QA work includes mobile application QA, Flutter and .NET MAUI test strategy, regression test planning, API and integration validation, Bluetooth and connected-device testing, AI-generated code review and pre-release technical review.

The same discipline anchors our Code-to-Spec (C2S) approach to legacy modernization — using AI to recover the actual behaviour of an undocumented system, locking that behaviour into automated tests, and only then re-platforming; more on our AI engineering and C2S page.

If your developers are shipping AI-assisted code faster than your current process can test it, we can help you put the right gates and evaluations in place before incidents reach production. Start with a 20-minute call. For the developer-side companion, see Testing AI-Generated Code: A Developer’s Checklist.

FAQ

Will AI replace QA engineers? No. AI automates repetitive testing and helps generate test cases, but it cannot independently decide whether a product meets business, user and regulatory expectations. The role shifts from running scripts to designing test strategy, judging risk and validating that AI behaviour is trustworthy in production.

What does QA find that code review misses? Code review examines implementation quality. QA validates behaviour across workflows, devices, permission states, network conditions, upgrades and edge cases — which is exactly where AI-generated code, optimised for the happy path, tends to break.

How do you test an AI feature that does not give the same answer twice? Add an automated evaluator, often called LLM-as-a-judge, that scores each response for coherence and safety against a versioned set of real and adversarial prompts, and routes anything below a threshold to a human. Static pass/fail tests cannot cover a probabilistic component on their own.

How does QA support AI compliance? By producing auditable evidence: linking test results to specific model versions and datasets, keeping logs, testing for bias and unsafe output, and being able to name who signed off the last change to a critical user journey.

QA in the Age of AI-Generated Code: From Bug-Hunting to Risk Governance