The pattern is familiar in most engineering organisations by now. Engineers use AI assistants every day. Pull requests are larger and arrive faster. Reviewers are stretched, and occasionally someone merges code that nobody on the team can fully explain. There is usually no policy, just a vague sense that "we should be careful".
A Kubernetes maintainer described the core problem well: AI has made generating code fast, but there has been very little improvement in maintaining codebases1. That asymmetry is exactly what a policy needs to address.
Why write a policy at all
The Kubernetes community's first step was an AI policy. Not because policies are exciting, but because many pull requests had derailed into arguments about AI usage, and a clear stance steered those conversations1. The same happens inside companies: without a shared rule, every review becomes a debate about whether AI-written code is acceptable, instead of whether the code is good.
What the Kubernetes policy says
The project's contributor guidance and the accompanying blog set out a few clear principles12:
| Principle | In practice |
|---|---|
| Transparency | Disclose in the pull request when AI tools assisted |
| Human accountability | The contributor is fully responsible; AI is not listed as a co-author |
| Human engagement | Reviewers engage with people, not AI; if you cannot explain the change, the pull request is closed |
| Verification | Review, test and understand AI-generated changes; working is not enough, you must know why it works |
| Licence checks | Contributor licence agreement checks are enforced for co-authors as well |
The project also documented how new AI review tools are brought in, including finding maintainers willing to trial them on specific repositories before wider use3, and reported using AI reviewers as a quick first-pass quality gate so contributors get feedback without waiting for a maintainer1.
"If you cannot explain it, you cannot merge it" is the single most useful AI rule an engineering team can adopt.
Translating it to a company team
An open source project and a company differ in important ways: employees are already accountable to their employer, and code may touch customer data and contracts. The principles still hold. A practical company policy covers:
- Approved tools and data boundaries. Which assistants are allowed, under which agreements, and what code or data must never be sent to them.
- Ownership. The engineer who opens the pull request owns every line, however it was produced.
- Explainability in review. Reviewers can ask the author to explain any change, and "the assistant wrote it" is not an answer.
- Proportionate scrutiny. Security-sensitive areas, authentication, payments and data handling get stricter review regardless of how the code was written.
- Tests as the contract. AI-assisted changes come with tests that a human has read and agrees with.
- AI reviewers as helpers, not approvers. Automated review can catch issues early; approval stays with a person.
- Supply chain hygiene. Watch for dependencies, snippets and model files introduced without scrutiny, as discussed in AI model supply chain security.
Measure the outcome, not the usage
Google's 2025 DORA research described AI mainly as an amplifier: it magnifies the strengths of high-performing organisations and the dysfunctions of struggling ones4. That is the right lens for leaders. Counting how much code AI produced tells you little. Watching delivery stability, rework and review load tells you whether AI is helping or merely moving work downstream, as covered in DORA metrics for AI-assisted engineering.
Write the policy down, keep it to a page, revisit it quarterly, and pair it with the decision records described in architecture decision records, so the reasoning behind important AI-assisted changes survives the people who made them.
How I can help
As a fractional CTO, I help teams adopt AI assistants with policies, review practices and metrics that improve quality rather than just volume. Or analyse your challenge and bring the result to a call.
- 1Open source maintainership in the age of AIKubernetes blog · 26 Jun 2026
- 2Pull request process: AI guidanceKubernetes contributor guide
- 3AI code review toolsKubernetes community, GitHub
- 4DORA 2025 State of AI-assisted Software Development ReportGoogle DORA · 2025