From the SLED-wide archive edition of August 27, 2026
Public-sector developers report strong utility from coding assistants
UK Government Digital Service · Digital service delivery · United Kingdom
- Publisher
- AI coding assistant trial: UK public sector findings
- Original publication
- September 12, 2025
- Source retrieved
- Not recorded in the historical archive
What happened
A cross-government GitHub Copilot trial examined adoption, code acceptance, developer sentiment, and reported time savings across a large license cohort.
Why it matters
Government technology teams can test assistants against delivery bottlenecks while monitoring actual usage, code acceptance, security, and developer experience.
Evidence and measured results
Among 1,100 activated licenses, an average 418 users were active daily and participants averaged 2,298 chats. The code-line acceptance rate was 15.8%, and 58% said they would not return to working without an assistant.
Limitations and uncertainty
Time savings were survey-reported, and code acceptance is not a direct measure of code quality or service outcomes.
Put this evidence to work
Lighthouse Advisory interpretation, grounded in this source as summarized in the preserved archive. Enriched 2026-09-05; this does not change the original publication date. Labels below come from the analysis itself.
Sales
Role takeaway
- Customer problem
- public-sector engineering teams need to identify whether coding assistance addresses a delivery bottleneck worth funding.
- Stakeholders
- CIO, application and platform leaders, application security, procurement, and developers.
- Discovery
- where do developers lose time; which repositories and languages are eligible; and how are review defects and delivery time measured?
- Value hypothesis
- assistance may help selected development tasks if gains survive human review.
- Potential engagement
- repository readiness and a representative developer pilot. The reported active use, 15.8% code-line acceptance, and favorable sentiment support exploration.
- Unsupported claims
- accepted code is not proven good code, survey savings are not measured delivery acceleration, and the trial does not establish security or service-quality gains for a particular team.
Pre-sales engineering
Role takeaway
- Fit
- treat the assistant as part of the existing engineering platform for supported IDEs, languages, and permitted repositories.
- Architecture and integration
- retain normal review, CI, dependency scanning, and delivery telemetry around generated suggestions.
- Prerequisites
- repository classification, approved vendor retention/training-use terms, a baseline, and developers able to review the relevant code.
- Constraints
- suggestions may be accepted without being correct, and usage differs across developers and tasks.
- Security
- prevent secrets and sensitive source from reaching unapproved models; test policy enforcement and scan accepted changes. Proposed proof: use representative work to compare cycle time, review effort, defects, and security findings against the current process, while reporting suggestion acceptance and sentiment as separate measures.
Delivery
Role takeaway
- Work
- select eligible repositories, configure access, train developers on prohibited inputs and output review, and retain the team's release gates.
- Dependencies
- IDE compatibility, procurement terms, security approval, and existing delivery/quality data.
- Ownership
- platform engineering operates access and telemetry; application owners accept changes; application security owns exceptions and incident handling.
- Skills and adoption
- coach developers in verifying generated code and interpreting tool limitations, then review sustained use by task.
- Governance checkpoints
- repository eligibility, pilot review, and license expansion.
- Proposed acceptance
- a documented comparison of delivery time and review quality, no unresolved critical findings from agreed security tests, and normal human approvals on pilot releases. Risks include measuring popularity instead of value and shifting saved coding time into additional review work.
Implementation considerations
Lighthouse Advisory interpretation across the operating dimensions a public-sector buyer must settle before this evidence becomes a design. Each note answers the question under its heading for this specific source.
Architecture and integration
What must connect, and where does the AI sit in the workflow?
Treat approved coding assistants as part of the engineering platform, with repository boundaries, supported IDEs, code review, dependency scanning, and delivery telemetry.
Governance
Who approves, reviews and stays accountable for outcomes?
Define permitted repositories and languages, require human review, and compare delivery and quality baselines before expanding access.
Security and privacy
What data, permissions and controls need testing?
Prevent sensitive source or secrets from entering unapproved models; validate data retention, prompt handling, and vendor training-use terms.
The preserved archive analysis covered architecture, governance and security. Not assessed for this record: accessibility and workforce, procurement, operating model.
Publication history
- 2026-08-27SLED-wide archive · Issue 0110 resources
Stable resource ID: uk-coding-assistants