What Offshore Teams Get Wrong When They Review AI-Generated Code and Who Pays for It

Most offshore buyers have stopped asking whether a vendor's developers use AI. They do. The better question is whether anyone at the vendor can prove the output was flagged, reviewed, tested, and contractually owned by someone.

Usually, nobody can. And under the typical billing model, that's not an accident.

The review gap, and why hourly billing widens it

AI tools compress the time it takes to write code. They don't compress the time it takes to decide whether the code is safe. A developer can generate three implementations of an endpoint before lunch. A qualified reviewer still has to trace data flows, check authorization boundaries, and read what the dependencies actually do.

The numbers on the generation side aren't flattering. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across 80 coding tasks and found that 45% of the time, the output contained a detectable OWASP Top 10 vulnerability. Java fared worst, with a reported 72% security failure rate, against 43% for JavaScript and 38% for Python. In the relevant samples, 86% failed to defend against cross-site scripting and 88% failed on log injection.

Now put that output into a time-and-materials contract. Revenue rises with delivery volume. Slowing down for a deep security review costs the vendor money and earns nothing unless the contract says otherwise. "Human review" then collapses into a quick pull-request approval by someone who is also being measured on throughput. If the vendor can also bill hours to fix defects its own AI workflow introduced, the model quietly rewards speed over prevention.

Five things offshore teams get wrong

They trust code that looks familiar. AI output tends to resemble standard framework patterns, and that resemblance breeds false confidence. Reviewers check that it compiles and behaves, then move on without asking whether it validates untrusted input or enforces authorization. OWASP's secure coding guidance for AI says to treat the output as untrusted and apply normal secure-development controls, including dependency auditing and CI/CD gates for known vulnerabilities.

They review the diff and ignore the context. A diff doesn't show what files, tickets, or documentation fed the model. In agentic workflows, instructions hidden in repository files, issue comments, or pull requests can steer a coding agent into weakening controls or touching unrelated files. OWASP flags indirect prompt injection as a real risk here. If you can't answer which tool generated the change and what context it saw, you can't review it properly.

They assume a green build proves a dependency is legitimate. Models invent package names, APIs, and versions. A hallucinated import might simply fail in testing. Or it might resolve to a similarly named package someone registered on purpose. OWASP recommends running auditing tools such as npm audit, pip-audit, govulncheck, and cargo audit on every AI-generated dependency list before merging. AI tools can also suggest versions that were current at training time but carry known vulnerabilities now.

They treat "AI-assisted" as a policy. Vendor pages love phrases like "responsible use" and "human oversight." None of that defines approved tools, prohibited data, reviewer qualifications, or who pays when something breaks. A policy that creates no observable obligation isn't a policy.

They never settle liability. Contracts written before AI tooling went mainstream are silent on whether a model-introduced defect is the vendor's problem. Silence usually favors the party holding the code.

What a credible governance policy actually contains

Run any vendor's published AI language against this list. Real policies cover four areas, and they name specifics.

• Tools. Named coding assistants, model providers, and account types. No personal consumer accounts touching client code. A clear statement on whether prompts or code can be retained or used for training.
• Data. A classification of what may enter a prompt. Credentials, personal data, regulated data, customer records, and production logs are the usual restricted classes. NIST's guidance on secure development for generative AI (SP 800-218A) calls for careful handling of AI inputs and outputs, including validation, sanitization, and encoding to prevent unauthorized code execution.
• Provenance. AI-touched code identifiable through commit metadata, pull-request labels, or repository records, so you can tell what was generated, what was heavily rewritten, and what was only assisted.
• Review and accountability. Mandatory human review, automated security gates that can block a merge, escalation thresholds, and named responsibility for remediation. Formatting help and generated authentication, cryptography, payment, or data-access code should not get the same treatment.

This is also where Offshore.dev's vendor evaluation framework puts weight: evidence of controls over claims about them. A written policy with an approval date beats a paragraph on a services page every time.

The buyer checklist: five clauses, three controls

Ask for an AI governance addendum before signature. At minimum it should include these clauses.

1. Approved tools and data use. Limit development to named tools and configurations. Bar client code, secrets, personal data, and regulated information from unapproved prompts and training workflows.
2. Provenance and disclosure. The vendor identifies AI-generated or AI-modified code, records the tool and model, and keeps those records available for audit.
3. Mandatory review and security gates. Qualified human review plus SAST, software composition analysis, secret scanning, tests, and license checks before AI-touched code reaches production.
4. Defect ownership and indemnity. The vendor stays responsible for security defects, IP violations, malicious dependencies, and negligent review in AI output. "The model did it" is not an excuse. Also define whether rework on AI-caused defects is billable.
5. Audit, incident, and remediation. Buyer access to policy evidence, review records, and scan results. Notification deadlines. Remediation at the vendor's expense when an AI-related defect reaches staging or production.

Three technical controls back those clauses up, and you can verify them yourself.

• AI-aware CI/CD gates. Every AI-touched pull request runs SAST, SCA, secret scanning, license checks, and tests. The pipeline fails on critical vulnerabilities, exposed secrets, or unapproved dependencies.
• Dependency allowlists. Install only from approved registries, require lockfiles or equivalent integrity records, and verify package identity and maintainers independently of the model.
• Least-privilege agent isolation. Coding agents run with no production credentials, restricted network access, and read-only defaults. File writes, command execution, and package installs need explicit approval.

Price is not the control

It's tempting to assume a higher rate buys better governance. The data doesn't say that. Per Offshore.dev listing data, 6,658 companies advertise rate bounds, 98.3% of those records fall into the four most common bands, and 62% sit in the $25 to $49 per hour band. In Poland (1,324 records), 59% advertise bands with a midpoint of at least $50 per hour, and the median company's band is $50 to $99. In Romania (402 records), it's 50%, with a median band of $30 to $55. Those are advertised ranges from directory records, not verified quotes or contract rates, and the bands are coarse. See the full breakdown in the 2026 offshore development rates report.

What the snapshot can't tell you is whether any of those vendors has a written AI policy. Rate bands say nothing about review capacity. A cheap vendor with strong gates beats an expensive one with a pull-request rubber stamp, and the reverse is just as possible. Ask for the evidence either way.

Questions to put to every vendor

• Can we see the written AI coding policy and its approval date?
• Which tools are allowed, and can the provider retain our prompts or source?
• How is AI-generated code flagged in the repository?
• What share of AI-touched pull requests gets a security review, and by whom?
• Can you share anonymized scan results and remediation records?
• Who pays when an AI-generated defect causes rework, delay, or breach response?
• Can we prohibit AI use in specific repositories?

A vendor that can't answer precisely isn't necessarily unsafe. It just isn't demonstrating controlled use, and you'd be financing the experiment.

Don't ban AI. Buy review capacity, traceability, and liability, not just developer hours. Start with the Offshore.dev directory to shortlist vendors, then make the governance addendum part of every conversation before you sign.