How should you review AI-generated code delivered by an outsourcing vendor?
Review AI-generated code the same way you review any code, but weight your attention differently: assume the syntax is fine and the judgement is not. The failure modes of AI-assisted development are architectural drift, plausible-looking tests that assert nothing, invented or misused dependencies, silently duplicated logic, and confident handling of edge cases the model never actually considered. Your review gates should target those, and your contract should say who is accountable when they slip through.
Nearly every outsourcing vendor now uses AI coding assistants, whether or not it is in the proposal. For a European buyer the question is no longer whether the vendor uses them — it is whether the vendor's review process is strong enough to make that safe, and whether your contract reflects it.
Why does AI-generated code need a different review emphasis?
Traditional code review evolved around a human author who understood the problem, made deliberate trade-offs, and produced code whose weak points correlate with their experience. Junior code is verbose and misses edge cases; senior code is terse and occasionally too clever. Reviewers learned to read those signals.
AI-generated code breaks that correlation. It is uniformly fluent, idiomatic and well-formatted regardless of whether the underlying approach is right. Fluency is no longer evidence of understanding — which means the review has to test understanding directly rather than infer it from the code's surface.
It also changes the volume dynamic. Generation is fast; review is not. If the vendor's throughput rises but its review capacity does not, quality degrades in a way that is invisible until it reaches production. The same pressure exists inside in-house teams, as we discussed in our post on AI pair programming and the limits of vibe coding.
What are the specific failure modes to look for?
| Failure mode | What it looks like | How to catch it |
|---|---|---|
| Architectural drift | A new pattern, library or layering convention appearing without discussion | Architecture decision records; a reviewer who owns the system's shape |
| Hollow tests | High coverage, assertions that only confirm the code ran | Mutation testing; review assertions, not coverage percentages |
| Dependency invention or bloat | Packages added for trivial functionality, or packages that do not do what the code assumes | Dependency review gate; a licence and provenance check in CI |
| Duplicated logic | The same rule re-implemented in three places instead of reused | Duplication detection in CI; reviewers who know the codebase |
| Confident wrong edge cases | Empty collections, time zones, currency rounding, partial failures handled plausibly but incorrectly | Property-based tests; explicit edge-case checklists per domain |
| Security regressions | Inconsistent input validation, permissive defaults, secrets handling copied from a generic pattern | Static analysis and secret scanning as blocking gates |
| Stale idioms | Deprecated APIs or patterns from older framework versions | Linting pinned to your actual framework version |
| Missing context | Code that ignores a business rule documented only in your ticketing system | Require the pull request to reference the requirement and state the trade-off |
What should your review gates look like?
Automate what is mechanical so that human attention goes where it is scarce. A workable gate stack for a vendor engagement:
- Automated, blocking: build, full test suite, linting, type checks, static application security testing, dependency and licence scanning, secret scanning, duplication threshold.
- Vendor-side human review: a named senior engineer on the vendor team approves every change, with substantive comments — not a rubber stamp.
- Buyer-side human review: your architect reviews anything touching data models, authentication, payments, external interfaces or shared libraries.
- Behavioural verification: the change is demonstrated working against a realistic scenario, not just shown green in CI.
Add one non-technical gate that catches more than anything else: ask the author to explain, in the pull request, why this approach and not the obvious alternative. Someone who understands the change answers in two sentences. Someone who accepted a generated suggestion without reading it cannot.
What should the contract say about AI use?
Silence is the worst option, because it leaves both the accountability and the IP position undefined. Address these points explicitly:
- Disclosure. The vendor states which assistants and models are used, and on what parts of the work.
- Accountability is unchanged. The vendor warrants the delivered code as its own work product regardless of how it was produced. AI use is never a defence for a defect.
- IP and provenance. Full assignment of the delivered code, plus a warranty that it does not knowingly incorporate third-party code under incompatible licences, backed by scanning.
- Confidentiality of your code and data. Which tools may see your repository, whether prompts and code are retained or used for training, and where processing takes place. This is a data-protection question as much as a commercial one.
- Review obligations. Every change is reviewed by a named human engineer at the vendor before it reaches you.
- Quality metrics. Defect escape rate, change failure rate and rework rate — measured on outcomes, not on how the code was written.
Measuring outcomes rather than inputs also protects you commercially, which is the same logic behind the shift toward outcome-based contracting described in our post on outcome-based AI outsourcing deals.
Should you pay less because the vendor uses AI?
Not directly, and asking for a discount on that basis usually backfires. What you should expect is more delivered value per unit of spend — more throughput, faster turnaround on well-specified work, and a smaller share of the budget going to boilerplate. Price the outcome, not the keystrokes.
The rate that should worry you is the one that has fallen far enough to imply that review capacity was cut along with generation cost. Generation is now cheap for everyone; disciplined review is what you are actually paying for, and it has not become cheaper.
How do you verify all this in practice?
- Ask to see the vendor's own pull request history on your project and read the review comments, not just the approvals.
- Check the ratio of review comments to merged changes — near zero means review is not happening.
- Run mutation testing once on the delivered test suite and look at the survival rate.
- Track defect escape rate month over month; a rising trend alongside rising throughput is the clearest warning sign.
- Include an AI-assisted change in your pilot scope and review it deliberately before signing anything long-term. Our guide to code quality SLAs for offshore teams shows how to write the resulting thresholds into the contract.
Where to go from here
AI assistance is now a normal part of how software gets built, including by good vendors. The differentiator is the discipline around it — review, testing, provenance and honest metrics. If you want an engineering partner whose delivery process is built for that, our AI application engineering service covers how we build and review AI-assisted software for European clients.
