AI Code Review: A UK Development Team's Guide to Using AI Without Introducing Technical Debt in 2026

AI code review has moved from novelty to default in UK development teams inside about eighteen months. Pull requests now arrive pre-annotated by a model, suggestions appear inline in the editor before a human has read the diff, and a meaningful share of the code being merged was drafted by a tool rather than typed by the engineer who owns it. The productivity story is real. The risk is that the same tooling which doubles the volume of code arriving at the review gate does nothing to double the capacity of the people standing at it — and the difference between those two numbers is where technical debt quietly accumulates.

This guide is written for engineering leads, CTOs and owner-managers of UK software teams who have already adopted AI assistance, or are about to, and want it to stay a productivity multiplier rather than becoming a liability that surfaces eighteen months later as a codebase nobody wants to touch. It leads with where AI-assisted development genuinely helps and where it demonstrably does not, then works through the practical machinery: review gates sized by blast radius, test coverage requirements that survive contact with machine-written tests, metrics that detect debt accumulation early, and the governance a UK organisation needs for data protection, intellectual property and auditability. Every recommendation is anchored to what a team of five to fifty developers can actually implement, not to a hypothetical platform organisation with a dedicated tooling group.

What is AI code review, and how does it differ from AI code generation?

The phrase covers two distinct activities that are routinely conflated, and keeping them separate is the first step to governing either of them properly. AI code generation is a model producing code — autocomplete in the editor, a chat-driven implementation of a function, an agent working through a ticket across several files. AI code review is a model reading code that already exists and commenting on it — a bot that posts findings on a pull request, a pre-commit hook that flags a probable null dereference, an agent that summarises a 900-line diff into three paragraphs before a human opens it.

The two have opposite risk profiles, which is why treating them as one thing produces bad policy. Generation increases the quantity of code entering your repository and therefore increases review load; its failure mode is plausible-looking code that is subtly wrong, architecturally inconsistent, or duplicative of something that already exists three directories away. Review decreases the load on human attention by triaging what deserves it; its failure mode is a false sense of completeness — a green checkmark from a bot that read the diff but not the system, reassuring a tired reviewer at 5:40pm on a Friday that everything is fine.

Most teams adopt generation first, because the benefit is immediate and individually felt, and adopt review second, because the benefit is collective and only becomes obvious once the first wave of generated code has started to bite. That ordering is the root of most of the trouble we are called in to unpick. A team that has been generating heavily for a year before instituting any review discipline is not asking for a code review tool; it is asking for a remediation programme. Adopting both together, with the gates described later in this guide in place from the start, is materially cheaper than adopting them eighteen months apart.

It is also worth naming what AI code review is not. It is not static analysis, although it overlaps: a linter, a type checker and a Semgrep rule are deterministic, reproducible and cheap, and a language model is none of those three. It is not a security assessment: a model reading a diff has no view of your threat model, your network boundaries or your data classification. And it is not a substitute for ownership. Someone with a name and a payroll number is accountable for every line that ships, regardless of what typed it.

The numbers that frame the decision

Adoption is no longer the interesting variable — roughly three quarters of professional developers report using or planning to use AI tooling in their workflow, and in UK product teams the practical figure inside any given squad is usually closer to universal. The interesting variables are what happens to the shape of the work downstream: how much bigger pull requests get, how much of the merged code is rewritten within a month, and how much of the review budget is being spent on volume rather than judgement.

Read those four together and the mechanism becomes obvious. Volume roughly doubles. Review capacity does not. The pressure valve is the review itself, which gets shallower, and the consequence shows up as rework — code changed again within days or weeks of being merged, which is the cleanest early signal that something was merged before it was understood. That final figure is not a scare number; it is simply what a fully-loaded senior developer costs for the fraction of the year that a debt-heavy codebase absorbs in unplanned rework, and it is the number that makes the governance work below pay for itself.

The counter-argument we hear is that all of this is a transitional problem, that the models will get better and the debt will evaporate. Model quality is genuinely improving, and the local defect rate is falling with it. But the failure modes that matter for debt are not local. A model that writes a perfect function still has no opinion about whether that function should exist, whether the abstraction it depends on is the one your team standardised on last quarter, or whether the third implementation of the same date-parsing logic is a problem. Those are system-level judgements, and they are the ones that determine whether a codebase remains cheap to change.

Ungated versus gated adoption — the choice most teams make by accident

Almost every team we work with has made this choice, but few have made it deliberately. Ungated adoption is the default state: licences are purchased, developers are told to use their judgement, and no change is made to the review process, the definition of done, or the metrics anyone looks at. Gated adoption costs perhaps two weeks of setup and changes four specific things — attribution, review tiering, test requirements and a small metrics dashboard. The comparison below is the honest version, including what gating costs you.

The row that decides it for most engineering leads is attribution. Everything else in the gated column can be retrofitted at some cost; attribution cannot. If you do not record which changes were substantially machine-authored at the moment they are merged, that information is gone permanently, and any later attempt to assess where your risk concentrates becomes guesswork across a year of commit history. A single commit trailer — a line in the commit message recording the assistant and the mode of use — costs nothing at the time and is the only mechanism we know of that makes the question answerable afterwards.

Where AI review actually catches things — and where it does not

The most useful thing an engineering lead can hold in their head is a rough hit rate by defect class, because it tells you what the tool is allowed to be trusted for and what it must never be allowed to substitute for. The pattern below reflects what we observe across UK client codebases when an AI reviewer is run against changes where the defects were later confirmed by a human or by production. Treat the figures as indicative shape rather than precision: the ordering is stable across teams and languages, the exact percentages move.

The shape of that chart is the whole argument of this guide in one image. Performance is strong at the top, where the defect is visible inside the diff itself, and collapses at the bottom, where the defect is only visible from outside the diff. A missing null check is a local property of eleven lines of code. Whether a new service should be talking directly to another team’s database is a property of the system, and no amount of context window solves it in the general case, because the relevant information — last quarter’s architectural decision, the migration that is half finished, the fact that this module is being deprecated in March — is not in the repository at all.

Two practical rules follow. First, let the AI reviewer own the top of that chart completely, and stop spending human attention there; a reviewer who is still leaving comments about naming conventions is a reviewer who has been given the wrong job. Second, make the bottom of the chart an explicit human responsibility with a named owner, and never let a clean bot review be the reason a human review was skipped on a change that touches module boundaries, data models, authentication or money.

This mirrors a pattern familiar from other parts of IT governance. Automated tooling is excellent at the checkable and poor at the contextual, which is exactly the distinction that underpins the technical controls in Cyber Essentials certification: the scan tells you the patch is missing, but only a person can tell you whether that host should have existed in the first place.

Risk scoring — where AI-assisted code introduces debt, and how urgently it matters

Not all AI-related risk is worth the same attention, and teams that try to address everything at once usually address nothing. The three cards below are the working triage we use on an engineering assessment: the first covers code-level effects, the second covers process effects, and the third covers the governance obligations that a UK organisation cannot decline. Badges reflect how quickly the issue compounds if left alone, not how severe a single instance is.

Two entries in the third card deserve expanding, because they are the ones that turn an engineering question into a legal one. Pasting client data or personal data into a consumer-tier assistant is a processing activity under UK GDPR, and if the tool’s terms permit training on submitted content, you have made a disclosure you almost certainly cannot justify to the data subject or the ICO. Business and enterprise tiers of the major assistants contractually exclude training on submitted code and offer zero-retention options; consumer tiers frequently do not. The control is not a policy asking people to be careful. It is procurement: buy the tier with the right terms, disable the others at the network or identity layer, and record the decision.

Secrets are the second. Assistants that index a workspace read whatever is in it, including the .env file someone left in the repository root three years ago. The mitigation is the one you should have anyway — secret scanning in CI, pre-commit hooks, and secrets held in a managed store rather than in files — but AI tooling raises the cost of getting it wrong, because a secret that was merely committed is now also transmitted. If your organisation has done the segmentation and access work described in our network segmentation guide for UK SMEs, the blast radius of a leaked credential is smaller, but the disclosure obligation is unchanged.

What AI code review and assistance actually cost a UK team

Budgeting for this is straightforward once you separate the per-seat licence from the platform and process costs that sit around it. The table below gives indicative UK monthly pricing per developer, converted from published list prices and excluding VAT; negotiated and annual-commitment rates are commonly lower, and the figures move often enough that you should treat them as a planning band rather than a quotation.

For a ten-person team the realistic all-in figure is roughly £4,000 to £8,000 a year in licences plus a few days of engineering time to set the gates up properly. Set against a fully-loaded developer cost, that is a small number, and the licence decision is rarely where teams get this wrong. Where they get it wrong is spending the licence budget and skipping the last row — buying the tooling and none of the process that makes it safe.

One procurement note specific to UK organisations that sell to enterprise or public sector: client security questionnaires now routinely ask which AI tools are used in the development of the delivered software, whether client data or code is transmitted to them, and what the retention terms are. Having the answer written down before the questionnaire arrives is considerably cheaper than assembling it under a bid deadline, and it is the same discipline that makes an outsourced virtual CIO engagement worth its fee: the documentation exists before anyone asks for it.

A readiness benchmark you can score yourself against

Before designing gates, it helps to know where you are starting. The benchmark below is the aggregate score we typically find on first assessment of a UK SME development team that has adopted AI assistance without changing its process — competent engineering, sound intentions, no specific controls. Score yourself on the same ten dimensions listed later in the checklist and compare.

Fifty-eight is a revealing score, because it is not a failing one. Teams at this level almost always have good fundamentals: continuous integration works, tests exist, someone reviews every pull request. The points are lost in a narrow and consistent band — no attribution, no differentiated review depth, coverage measured by line rather than by behaviour, and no written data policy. Those four gaps are worth roughly thirty points between them, and closing them is a fortnight of focused work rather than a programme.

The teams that score below forty are usually distinguished by one specific thing: they have no deterministic quality layer underneath the AI layer. No type checking, no enforced linting, no dependency scanning. AI review sitting directly on top of an unlinted codebase generates enormous comment volume about things a linter should have fixed silently, reviewers learn to dismiss the bot wholesale, and the genuinely useful findings go with them. If that describes your repository, fix the deterministic layer first; it is cheaper, it is permanent, and it makes everything above it work better.

The rollout timeline — what a controlled adoption looks like

A gated rollout is a ten-week arc for a team of five to twenty developers, and it deliberately front-loads the deterministic and documentary work so that the AI layers land on top of something solid. Nothing here requires a dedicated platform team; the work is a few hours a week for one senior engineer plus a decision or two from whoever owns engineering.

The ordering matters more than the durations. Attribution before gates, gates before the AI reviewer, deterministic checks before all of it. Teams that install the AI reviewer in week one and get to the policy work “later” generate a fortnight of noise, burn the team’s tolerance for the tool, and then find the tool disabled by consensus with nobody willing to revisit it.

Maturity benchmarks — the ten dimensions worth scoring

These are the dimensions behind the readiness score above, with the average result we see on first assessment. They are deliberately concrete: each one is either in place or it is not, and each can be verified in an afternoon by looking at the repository rather than by asking people what they do.

The distribution tells a consistent story. The top four rows — the conventional engineering hygiene that predates AI adoption — are mostly healthy. The bottom six, which are precisely the controls that AI assistance makes necessary, are mostly absent. That is not negligence; it is lag. The tooling changed faster than the process around it, and nobody scheduled the fortnight required to catch up.

If you score yourself and find the same shape, the order of attack is by cheapness rather than by score. Attribution is an afternoon. A written data policy is a day. Tiered review is a code owners file and a branch protection rule. Mutation testing on changed files takes the longest and delivers the most, so start it early even though it finishes last.

How much AI review output is actually acted on?

The single most useful operational metric for an AI reviewer is not how many findings it produces but what proportion of them change the code. It is the number that tells you whether the tool is a colleague or a cost, and it is the number almost nobody measures because the platforms report volume by default.

Roughly one in four is what an untuned reviewer achieves on a typical codebase, and the three quarters that lead nowhere are not harmless. Every dismissed comment trains the team to scroll past the bot, and the cost of that habit is paid on the day the tool is right about something serious. Tuning — suppressing categories your linter already owns, silencing the “consider adding a comment” genre entirely, restricting the reviewer to changed lines rather than whole files — commonly moves the figure into the forty to fifty per cent range, at which point engineers start reading it voluntarily.

Set a floor and defend it. If acceptance sits below one in five after two rounds of tuning, the honest conclusion is that the tool is not earning its place in your pipeline on this codebase, and continuing to run it is worse than not running it. This is the same discipline that separates a monitored system from an alerted-on one, and it applies wherever automation meets human attention — the alert nobody acts on is a liability, not a control.

What this looks like in practice — an anonymised example

A 34-person software company in Bristol, building a scheduling platform sold to UK healthcare providers, adopted in-editor AI assistance across its four squads in the space of a month. The immediate effect was exactly as advertised: throughput rose, the backlog of small feature requests that had sat untouched for a year cleared in a quarter, and developer satisfaction in the internal survey went up. Nobody changed the review process, because nothing appeared to be wrong with it.

Eleven months later, three signals arrived within a fortnight of one another. A routine dependency upgrade took nine days instead of the usual one, because the same HTTP client had been wrapped four separate times with four sets of retry semantics. A production incident traced back to a timezone bug in a booking window — the test suite covered the affected function at 96% line coverage, and every one of those tests had been generated from the implementation, so all of them asserted the wrong behaviour confidently. And a healthcare client’s security questionnaire asked which AI tools were used in development and whether patient-adjacent data had been transmitted to them. Nobody could answer the third question without reading eleven months of commits, because there was no attribution.

The remediation took a quarter and cost roughly what two weeks of gating would have cost at the start. The team consolidated the four HTTP wrappers into one, introduced mutation testing on changed files — which immediately revealed that a mutation score of 31% sat underneath that 96% line coverage — adopted a commit trailer, and wrote a two-page tool and data policy that has since answered four client questionnaires without further work. Throughput did not fall. The dependency upgrade that had taken nine days took two the following quarter.

The tools were never the problem. We had simply doubled how much code we produced without changing anything about how we decided what deserved to exist — and the coverage number told us we were fine right up until the morning it did not.

The detail worth carrying away is the coverage figure. Ninety-six per cent line coverage with a 31% mutation score is not an unusual result in an AI-assisted codebase; it is close to the expected one, because generating a test from finished code produces something that executes every line and detects no defects. Line coverage was always a weak proxy for test quality. In an AI-assisted team it stops being a proxy at all.

The 12-point AI code review checklist

This is the working checklist we take into an engineering assessment. Each item is binary, verifiable from the repository, and independently useful — there is no requirement to do them in order, though the earlier ones are cheaper.

1. Deterministic checks run first and block. Formatting, linting, type checking, secret scanning and dependency alerts fail the build. Nothing that a machine can decide with certainty should ever reach a human reviewer as an opinion.
2. Every merged change has a named human owner. Not an approver — an owner, who is expected to be able to explain the change without opening the assistant that helped write it. If they cannot explain it, it is not ready.
3. AI authorship is attributed at commit time. A trailer in the commit message recording the assistant and the mode of use. Free at the time, impossible to reconstruct afterwards, and the basis of every later question about where risk concentrates.
4. Review depth is tiered by blast radius. Authentication, authorisation, payments, personal data handling, schema migrations and infrastructure require two human approvals. Ordinary feature work requires one. Copy, docs and test-only changes may proceed with the owner plus the bot.
5. Pull request size is capped or warned on. A CI warning above roughly 400 changed lines, with an explicit override reason recorded. Review depth degrades sharply past that point, and AI-assisted work reaches it far more often.
6. Test quality is measured by mutation score, not line coverage. Run mutation testing on changed files in every pull request, or nightly on the whole suite if that is too slow. Set a floor on changed lines and hold it.
7. Tests for new behaviour are written from the specification. Write the test from the ticket, the acceptance criterion or the API contract — before the implementation exists, or at minimum without showing the implementation to the model. Tests generated from finished code encode the bug alongside the feature.
8. The AI reviewer is advisory, never blocking. It cannot approve, it cannot merge, and its clean run is never a documented reason a human review was skipped. Its findings are input to a person, not a gate.
9. New dependencies require explicit justification. One line in the pull request description saying why it is needed and what was considered instead. This is where hallucinated and typosquatted packages are caught, and where the accidental addition of a 400KB library for one date helper gets questioned.
10. Approved tools and tiers are written down and technically enforced. Which assistants, at which subscription tier, for which repositories, with the training-exclusion and retention terms recorded. Enforced at the identity or network layer rather than by request.
11. Duplication and rework are tracked as trends. Duplicated-code share and the proportion of merged lines rewritten within three weeks, plotted monthly. These two numbers detect accumulating debt months before it becomes an incident or a stalled upgrade.
12. The whole arrangement is reviewed quarterly. Half a day, named owner, in the calendar. Tools, tiers, terms, thresholds and trends. Model capability changes faster than most annual policy cycles can absorb.

Common mistakes UK development teams make with AI code review

These are the failure patterns we encounter most often, roughly in order of how much they cost to unpick. None of them involve a team doing something obviously foolish; each is a reasonable decision that compounds badly.

• Treating a clean bot review as a completed review. The most expensive mistake on this list, and the easiest to make at the end of a sprint. An AI reviewer reads a diff; it does not read your system, your roadmap or last quarter’s architectural decision. A clean run means nothing local is obviously wrong, which is a genuinely useful thing to know and a completely different thing from “this change is correct”.
• Chasing line coverage on machine-written tests. Coverage rises effortlessly when a model writes tests against finished code, and the number reassures everyone while the safety net develops holes. Measure whether your tests fail when the behaviour changes — that is the only property of a test that matters.
• Letting pull requests grow because they are cheaper to produce. A 1,200-line change that took forty minutes to generate still takes ninety minutes to review honestly, and it will not get them. Review quality falls off a cliff with diff size, and AI assistance pushes teams over that cliff without anyone deciding to jump.
• Deploying the AI reviewer before the linter. Comment volume explodes, engineers learn to dismiss the bot wholesale, and the useful findings are discarded along with the noise. The deterministic layer must come first, always.
• Allowing consumer-tier assistants on client work. The tiers differ on exactly the terms that matter — training on submitted content, retention period, regional processing. This is a procurement control, not a training issue, and asking people to be careful is not a control at all.
• Accepting new dependencies without question. Models suggest packages that sound plausible, including ones that do not exist — a gap attackers have learned to fill by registering the hallucinated names. One sentence of justification per new dependency catches this at negligible cost.
• Letting junior engineers merge code they cannot explain. The productivity gain is real for juniors and the learning loss is equally real. The requirement that the owner can explain the change without the assistant open is not bureaucracy; it is how the next generation of reviewers gets built.
• Assuming the model knows your architecture. It knows what is in the context window. Your deprecation plan, your half-finished migration and the module boundary you agreed in March are not in it, and no amount of prompt engineering puts them there reliably.

The UK governance layer — data protection, IP and client assurance

Most of this guide is engineering practice, but three obligations sit outside engineering’s gift and are worth handling explicitly, because they are the ones that turn a technical decision into a board-level one.

Data protection. Source code frequently contains personal data — in fixtures, in test data, in a stack trace pasted into a chat window, in a migration script full of real customer rows someone copied down from production to debug a defect. Sending that to a third-party model is a processing operation under UK GDPR, and the lawful basis, the transfer mechanism and the retention terms all have to hold up. The practical controls are unglamorous: business or enterprise tiers with contractual training exclusion, zero or short retention where offered, synthetic rather than production data in fixtures, and a written record of which tools are approved for which repositories. The NCSC’s guidelines for secure AI system development and the UK Government’s AI Cyber Security Code of Practice are both reasonable reference points when you write that record, and neither is long.

Intellectual property. Two questions arise and they have different answers. On inbound risk — whether suggested code reproduces licensed material — the major business and enterprise assistants now offer filters for public code matches and, in some cases, contractual indemnity; read what you have actually bought rather than what the marketing page implies, and keep the public-code filter enabled. On outbound ownership — whether you own what the model produced — the position under UK law is more settled than the debate suggests for ordinary commercial work, but your client contracts may contain warranties about the provenance and originality of delivered code that predate any of this. Have someone read them once. It is a two-hour job that occasionally changes what you are allowed to do.

Client assurance. If you sell software or development services to UK enterprises or the public sector, questions about AI use in your delivery process are now standard in security questionnaires and increasingly appear in framework agreements. The answer set is small and stable: the tools you approve, the tiers you buy, whether client data or code is transmitted, what the retention terms are, how AI-assisted changes are reviewed, and how you would evidence any of it. Write it once as a two-page annex, keep it current at the quarterly review, and it stops being a bid-week emergency. Teams that already run this discipline for infrastructure and support — the same instinct behind a documented approach to in-house versus outsourced IT support — find the AI annex takes an afternoon rather than a fortnight.

One final note on scope. If you place software on the EU market, the EU AI Act may apply to your product; it does not, however, regulate your internal use of a coding assistant to build ordinary business software. Keep the two questions separate. Conflating “we use AI to write code” with “we ship an AI system” produces compliance work that is disproportionate to any real obligation and distracts from the controls that genuinely matter.

At a glance — AI code review for UK development teams

How Cloudswitched supports AI-assisted development teams

Our AI software development practice works with UK teams on both halves of this problem: building AI capability into products, and putting the engineering governance around AI-assisted delivery so that the speed is kept and the debt is not. In practice that means an assessment against the twelve-point checklist above, help standing up the deterministic layer and the review gates, mutation testing configured on the paths that matter, and a two-page tool and data policy your sales team can put in front of a client without escalating to engineering. We work alongside your developers rather than replacing them — the point is that your team owns the arrangement afterwards.

Frequently Asked Questions

Does AI code review actually reduce bugs, or just move the work around?

It reduces a specific class of bugs and moves the rest. On defects that are visible inside the diff — unhandled nulls, missing error paths, obvious injection, convention drift — a tuned AI reviewer catches a substantial majority before a human looks, and that is genuine reduction in both defects and reviewer effort. On defects that require knowledge of the wider system, it contributes very little, and the work moves rather than disappearing. The practical gain comes from redirecting the human attention it frees towards architecture, data modelling and edge-case reasoning, rather than treating it as capacity to review more code.

Should AI code review replace human review for small changes?

For genuinely low-consequence changes — copy edits, documentation, test-only additions, configuration in non-production environments — an owner plus a bot is a defensible standard, and insisting on two senior reviewers for a typo fix wastes the attention you need elsewhere. For anything touching authentication, authorisation, payments, personal data, schema migrations or infrastructure, no. The distinction should be encoded in a code owners file so it enforces itself, rather than being left to whoever is on review duty at 5pm on a Friday.

How do I tell whether AI assistance is creating technical debt in my codebase?

Track two numbers monthly. The first is duplicated-code share, which most static analysis platforms report directly; a steady upward trend means the team is writing new implementations of things that already exist. The second is the proportion of merged lines rewritten within three weeks, which you can derive from repository history; a rising figure means code is being merged before it is properly understood. Both are trends rather than thresholds — the absolute values vary enormously by codebase and language, but the direction is unambiguous and shows up months before the debt becomes an incident or a stalled upgrade.

Is line coverage still a useful metric when tests are AI-generated?

Not on its own, and relying on it is actively misleading. A model generating tests against a finished implementation will produce something that executes almost every line and detects almost no defects, because it has encoded the current behaviour as the expected behaviour — bugs included. Coverage of 90% or higher sitting on a mutation score in the low thirties is a common pattern in AI-assisted codebases. Mutation testing, which changes the code and checks whether any test notices, is the metric that survives. Run it on changed files in each pull request to keep pipeline time reasonable.

What should our AI usage policy actually contain?

Two pages is enough for most UK SMEs. Which assistants are approved and at which subscription tier; which repositories or classes of work they may be used on; confirmation that the tier excludes training on submitted content and what the retention terms are; the rule that no production or personal data goes into a prompt; the attribution requirement; the review tiering; and a named owner with a quarterly review date. Anything longer will not be read. Anything that only says “use good judgement” cannot be enforced at the pull request or evidenced to a client.

Can we use AI code review on client work under a confidentiality agreement?

Usually yes, but check three things before you do. First, whether the client contract restricts disclosure to sub-processors and whether your assistant vendor is on any agreed list — some agreements require notification or consent. Second, whether the tier you have bought contractually excludes training on submitted content, which business and enterprise tiers generally do and consumer tiers frequently do not. Third, where processing occurs, if the contract specifies a region. Sorting this once per client, at contract stage, is far less painful than discovering the constraint mid-project.

How do we stop AI assistance from harming our junior developers?

Enforce one rule: the owner of a change must be able to explain it without the assistant open. That single requirement preserves the learning loop, because it forces the engineer to understand the code rather than merely to have obtained it. Beyond that, pair juniors on review rather than on writing — reading and critiquing code with a senior is where judgement develops fastest, and it is exactly the skill AI assistance makes more valuable rather than less. Some teams also reserve one ticket per sprint as assistant-free, which is less about the code produced and more about keeping the muscle in use.

What is the risk with AI-suggested dependencies?

Models suggest packages that sound plausible, and a fraction of those do not exist. Attackers monitor for the names that get suggested repeatedly and register them, so the hallucinated package becomes a real one containing whatever they chose to put in it. The second, more mundane risk is dependency bloat — a substantial library pulled in for a single helper function that could have been six lines. Both are handled by the same lightweight control: one sentence in the pull request explaining why a new dependency is needed and what was considered instead, plus dependency scanning that flags packages below an age or download threshold.

Should the AI reviewer be a required status check in CI?

No. Making it required has a predictable psychological effect: once a bot’s approval is mechanically necessary to merge, it starts to feel sufficient, and the distinction between “nothing obviously wrong in this diff” and “this change is correct” quietly disappears from your process. Keep it advisory and keep the human approval explicit. Required status checks should be reserved for deterministic gates — tests, types, linting, secret scanning — where a failure means something definite and reproducible.

How long does it take to put proper gates around AI-assisted development?

For a team of five to twenty developers, about ten to twelve weeks elapsed, but only a few hours a week of actual work, and most of it front-loaded. The deterministic layer and the written policy take the first fortnight, attribution and pull request hygiene another two weeks, review tiering two more, and the test-strategy change is the longest single item. If you need a minimum viable version faster, attribution, tiered review and mutation score on changed files can be in place inside a fortnight and deliver most of the protection.

Does any of this slow the team down?

The gates add measurable overhead in two places — the pull request size cap, which forces work to be split, and mutation testing, which adds pipeline time. Both are modest and both are visible. What they buy is that the second-order costs stay off the balance sheet: the dependency upgrade that takes two days rather than nine, the incident that does not happen because the test suite genuinely detects behaviour change, the client questionnaire answered from a document rather than from a fortnight of archaeology. Whether that trade is worth it is a judgement for your engineering leadership, but it should at least be made deliberately rather than by default.

Which comes first if we can only do one thing this quarter?

Attribution, because it is the only item on the list that loses value permanently if delayed. A commit trailer recording assistant use costs an afternoon to introduce and nothing to maintain, and it is the sole mechanism that lets you answer, in six months, which parts of your codebase were substantially machine-authored. Every other control on the checklist can be retrofitted at roughly the same cost later. Attribution cannot be retrofitted at all.

Related reading

These guides cover the adjacent decisions that AI-assisted development touches — the security baseline your development process sits inside, the technical leadership that owns the policy, the code quality that shows up in production performance, and the delivery model behind it all.

• Cyber Essentials certification for UK business — a step-by-step guide
• When does a UK SME need a virtual CIO?
• Core Web Vitals, website speed and conversion for UK business
• Network segmentation for UK SMEs
• In-house versus outsourced IT support — the UK SME decision