The Government Digital Service Says UK Government Developers Are Fully Responsible for AI-Assisted Code

The UK's Government Digital Service publishes guidance on AI coding assistants for developers in the UK government. It was updated on August 3, 2026. It uses the principles of the government's AI Playbook to frame its recommendations for these tools.

The guidance says it was developed with senior stakeholders, technologists and assurance teams. It says it can be used by individuals and organizations in both the public and the private sector. Parts of it follow, not the whole.

What the Tool Is, and Who Answers for Its Code

The guidance asks developers to treat an AI coding assistant as if it were a programmer who lacks experience. It also lacks the ability to see the big picture in terms of business logic and the overall algorithm, it says. It does have perfect recall of programming languages and exceptional lookup skills.

All AI models commonly in use in these assistants are in effect "sophisticated text predictors," the guidance says. They do not have inherent logical capabilities. Providing more context can dramatically improve their performance.

Responsible use requires the developer to understand the resulting code, the guidance says, and to take sole responsibility for any changes. Under its principle of meaningful human control, it says developers should only commit code changes they understand. They are fully responsible for the code they produce, whether it is AI assisted or not.

The assistants will not actively recognize or flag bias, the guidance says. So it remains up to the developer to make sure the code does not contain bias.

Good Practice Around the Tool

The guidance says developers can greatly reduce the risks of these assistants by working in the open and protecting the main branch. Strictly separating and auditing access to production secrets helps too. So do multi-stage deployment, and sufficient test coverage and vulnerability scanning in the deployment pipelines.

Where a production service is developed, maintained and deployed from a single environment, these assistants may introduce unacceptable risks, it says. Its example is an assistant regularly communicating production secrets with its provider.

A plugin in an integrated development environment may provide all the data open or present in a workspace to the assistant's backend. Any secrets present there will potentially be uploaded, the guidance says. Sensitive production data or secrets should never be handled in development environments.

The makers of these assistants advertise their awareness of vulnerabilities and their capacity to mitigate most of them automatically, the guidance says. For that reason, it says, a multi-layered approach to vulnerability scanning is important. In traditional best practice, additional third-party tools or language-specific static analysis tools should be used to complement the assistants.

Developers should monitor versions of all assistant software and tooling, including plugin and model versions, it says. They should read the changelogs for breaking changes and for license or privilege changes.

Dependencies the Tool Brings In

Several reports have noted that language models may hallucinate version numbers of library dependencies, the guidance says. If malicious actors become aware of these, they can provide made-up dependency versions that include malicious code.

Developers should always double-check the version requirements of dependencies introduced by a coding assistant against trusted sources, it says.

Human Control and Reliance on the Tool

The guidance also asks for meaningful human control at the right stages. Merges to the main branch need human peer review by one or more peers, it says. They must also follow the organization's policies. Human peer review is best combined with branch protection on the main branch. Keeping each commit small and specific is good practice, to better track changes and reduce overload for reviewers.

The models underpinning these assistants are non-deterministic, the guidance says. So code and build pipelines should never rely on a specific response to a prompt. The exception is a team willing to test those responses extensively and accept the risk of frequent breakage. Appropriate use should introduce no end product, code or documentation dependencies on the tool.

The guidance does not take the tool's word for its own work.

Could a team show, for each dependency an assistant brought in, that someone checked its version requirements against a trusted source?