Skip to content
DMDQP AI Capability Hub

Roche AI Manifesto in Practice: DOs and DON'Ts

Roche AI Manifesto in Practice: DOs and DON’Ts

Overview

The Roche AI Manifesto sets out ten principles for responsible AI-assisted work. This article translates those principles into practical daily guidance — specific DOs and DON’Ts for using build-cli and other AI tools in DMDQP projects. It is written for anyone on the team who uses AI tools, regardless of technical background.

Background

The Manifesto

The ten principles we hold as we build software with AI at Roche:

  1. The human is accountable for the change. Agents may author, sometimes even decide; but people stay accountable.
  2. Product Requirements define what the system must do, not what the agent happened to build. Functional and non-functional requirements remain explicit, achievable, and testable.
  3. We place human approval where it adds assurance, not at every keystroke. Gates exist to protect what matters; excessive ceremony invites rubber-stamping, and rubber-stamping protects nothing.
  4. Evidence is a byproduct of doing the work, captured continuously. Evidence is gathered during the process, not assembled afterwards to satisfy an audit.
  5. Every agent execution generates enough evidence to investigate further. We record the mode configuration, the prompt, the tools, and the context — enough to re-execute when something demands explanation.
  6. The agent that authored a change never approves it. Independent review is a property of the workflow, not a preference of the reviewer.
  7. Policies are enforced by deterministic, auditable controls, not only by SOPs. We codify the rules so that they become part of the process, not a human habit.
  8. Any development framework that can show its value in the process is welcome. No framework is sacred; no framework is prescribed; the test is whether it can emit the evidence we need.
  9. During development, we measure deviations and rejections at quality gates. We do not measure the quality of work by the sheer number of code commits per week.
  10. We treat data privacy, security, and compliance with utmost respect. Data privacy, security, and compliance is not an afterthought — it’s part of solution design from the very beginning.
  11. We maintain a central list of solutions using AI, with clear ownership and responsibility.

Main Content

DOs

DO own what the AI produces. You are accountable for every change, regardless of who — or what — wrote it. Review AI output the same way you would review a junior colleague’s work. (Principle 1)

DO write requirements before you prompt. Describe what the system must do before asking the AI to build it. A vague prompt produces a vague result. If you can’t write the requirement, you’re not ready to prompt. (Principle 2)

DO set review gates at the right places. Put human approval where it prevents real risk — before merging to main, before deploying, before sending to a stakeholder. Don’t add ceremony everywhere just to feel safe. (Principle 3)

DO capture context as you work. Save your prompts. Keep meaningful session context. If a decision needs to be explained in three months, the prompt and configuration should still be findable. (Principles 4 and 5)

DO route AI-generated changes to a peer for review. If you used build-cli to write or substantially modify something, someone else must approve it. This is not optional. (Principle 6)

DO put rules into tooling, not just into documents. A CLAUDE.md, a linting rule, a CI check — these enforce behaviour reliably. A SOP that people read once and forget does not. (Principle 7)

DO raise a privacy or compliance concern before building, not after. If a task involves personal data, sensitive data classifications, or regulated outputs, flag it at the design stage. Ask the AI to help you think through compliance implications, but have a human verify. (Principle 10)

DO register your AI-assisted solution or tool with the team’s central list (see your team lead for the current registry). (Principle 11)

DON’Ts

DON’T let the AI define the requirements. If you prompt the AI and then treat whatever it builds as the requirement, you have reversed the process. The AI is an author, not an architect of intent. (Principle 2)

DON’T approve changes you authored with AI assistance. This includes “I just touched it up a little.” If AI wrote the substance of it, route it for independent review. (Principle 6)

DON’T assemble your audit trail after the fact. Reconstructing what you did — from memory, from vague commit messages — is not evidence. Evidence is what was captured during the work. (Principles 4 and 5)

DON’T measure your productivity by output volume. More commits, more lines generated, faster cycles — none of these are quality signals. What matters is passing quality gates and not creating incidents downstream. (Principle 9)

DON’T ignore security and privacy because the AI generated the code. AI-generated code can introduce the same vulnerabilities as human-written code — sometimes more subtly. Review for secrets, access patterns, and data handling regardless of the source. (Principle 10)

DON’T rubber-stamp reviews. A review that always approves is not a review. If you don’t understand what the change does, say so and ask for an explanation before approving. (Principle 3)

DON’T paste sensitive data into prompts. Patient data, PII, confidential business data, credentials — none of these belong in a prompt. Work with anonymized or synthetic data when developing and testing. (Principle 10)

Practical Tips

Start sessions with context. A CLAUDE.md in your project tells build-cli about the codebase, conventions, and constraints — so you don’t have to repeat yourself every session. See the CLAUDE.md example templates in this hub.

Use /compact for long sessions. When a session grows very long, use /compact to summarize context and keep responses focused.

Prefer small, reviewable changes. Ask the AI to make one focused change at a time. Large AI-generated diffs are hard to review meaningfully. (Principle 6)

When in doubt, ask the AI to explain. If you don’t understand why the AI made a particular choice, ask it. “Why did you do it this way, and what are the trade-offs?” is a valid and useful prompt.

Summary

The Roche AI Manifesto is not a constraint on productivity — it is a framework for building trust in AI-assisted work. The DOs and DON’Ts above are practical expressions of that framework. The key pattern: write requirements first, capture context continuously, route AI output for independent review, and codify your standards in tooling rather than leaving them in documents.

If you are unsure whether a particular use of AI is in the spirit of the manifesto, ask yourself: “Can I explain what I did, why I did it, and what evidence I captured — to a reviewer who was not in the session?” If the answer is no, adjust your approach before proceeding.