1.1 Define the “contract” for AI use

Treat AI like a service with a clear interface.

• Allowed work (good fits)

  • Drafting code scaffolds and tests

  • Refactoring suggestions

  • Generating acceptance criteria, edge cases, and test data

  • Explaining unfamiliar code paths

• Disallowed work (requires human ownership)

  • Final security decisions

  • Anything involving secrets, keys, customer data

  • Unreviewed direct commits to main

Deliverable: a short “AI Use Policy” section in your repo README or engineering handbook.

1.2 Create a standard prompt structure (your “prompt template”)

Use the same headings every time so outputs are predictable and comparable.

Prompt Template

1. Goal: what you want (single sentence)

2. Context: relevant code/design constraints, definitions, domain rules

3. Inputs: files/snippets/data (only what’s needed)

4. Constraints: libraries, style guides, performance/security requirements

5. Output format: exact structure (diff, checklist, test plan, ADR, etc.)

6. Quality bar: tests required, linting, complexity limits, edge cases

7. Assumptions & questions: what to do if information is missing

Guardrail rule: If missing info prevents correctness, the AI must list assumptions explicitly instead of guessing.

1.3 Add “reviewability” guardrails

Make every response easy to inspect.

Require the AI to produce:

• A small, bounded change set (no “rewrite everything”)

• Rationale per change (1–2 lines each)

• Risk notes (what might break)

• Test impact (new/updated tests, how to run)

• Checklist for reviewers

Example output formats

• “Provide a unified diff”

• “Return a PR description: Summary / Changes / Tests / Risks”

• “Return an acceptance test plan in Gherkin”

• “Return a table: Edge case | Expected behavior | Test approach”

1.4 Integrate into the normal dev flow (PR-first)

Keep AI outputs inside the same governance you already trust.

Recommended workflow:

1. Create a branch (human-owned)

2. Use AI to draft code/tests/docs

3. Run tests and linters locally

4. Open PR with AI-generated summary + your review notes

5. CI gates + human review

6. Merge

Key principle: AI can propose; humans approve.

1.5 Build your “context pack” (reusable, minimal)

A context pack is the small set of material you feed repeatedly.

Include:

• Architecture summary (1 page)

• Coding standards (lint rules, formatting)

• Domain glossary (terms, invariants)

• Test conventions (naming, fixtures, patterns)

• Security constraints (red lines)

Keep it short enough to paste or reference reliably.

1.6 Step completion checklist

You’re done with Step 1 when you have:

• A written AI use policy (what’s allowed/not allowed)

• A prompt template used by the team

• Standard output formats (diff, PR summary, test plan)

• A PR-first integration workflow

• A reusable context pack

Step 1 “artifact” you can reuse (copy/paste)

Definition of Done for AI outputs

• Must list assumptions explicitly

• Must provide bounded changes (no unscoped rewrites)

• Must include rationale + risks

• Must include tests and how to run them

• Must be suitable for PR review