The 5 Ways We Work With AI

Single source of truth. This file holds the five “ways of working” that anchor the whole Innovation Day. Both sessions teach the same five; each practises the relevant ones hands-on. Every other document references this file - do not restate the Ways elsewhere, link here instead.

Opening line for facilitators: “AI doesn’t change the standards - it changes how fast we hit them. Same destination, faster road. Here are the five rules of the road.”

These five are a plain-language distillation of the company’s corporate standards (engineering + quality principles). Each cites the real data-cite ID it comes from, so the standards owners can validate it and nothing drifts.

The five

1. Describe before you generate

Say what “good” looks like before you ask. A clear spec beats a clever prompt. Write the goal, the inputs, and the shape of the output first - then let the AI fill it in. If you can’t describe the result, you’re not ready to generate it.

• Standards anchor: ENG-PRIN-DOC-STMT (Document Decisions, Not Code - decisions must outlive the conversation they were made in) and QUAL-PRINC-SHIFT-LEFT (prevent defects at inception, not after).
• In the room: the Skill template puts the Output section above the prompt; the Build session forbids feature code before the contract is written.

2. A human always signs the work

AI drafts; a person reviews and owns it. Nothing ships unread. The AI is a fast pair, not the approver - you remain accountable for what goes out under your name.

• Standards anchor: ENG-PRIN-REVIEW-STMT (no change reaches trunk without review by another human; no self-merge) and ENG-PRIN-OWN-STMT (You Build It, You Own It).
• In the room: the Skill session’s “find one thing the AI got wrong” beat; the Build session’s mandatory human review gate (AI may assist the review, but a human approves).

3. Mind what you feed it

Treat every prompt like a public postcard, not a sealed envelope. No secrets, no client data, no PII, no confidential figures. Anonymise first - swap real names for “Person A”, vendors for “Vendor 1”. When in doubt, leave it out.

• Standards anchor: the standards’ security & data-classification posture (least-privilege, protect sensitive information, maintain trust and compliance).
• In the room: the Skill template’s “PRIVACY CHECK” line inside Inputs; the optional “run the script yourself” path so real data never leaves your machine; synthetic-data-only rule for both sessions.

4. Small steps, not big leaps

One change at a time - easy to check, easy to undo. Don’t ask AI for a giant deliverable in one shot. Build in reviewable increments; verify each before the next.

• Standards anchor: ENG-PRIN-INCR-STMT (many small commits over large batches; easier to review and revert) and ENG-PRIN-TRUNK-STMT (short-lived branches, frequent integration).
• In the room: the Build session’s “stub + failing test first, then implement”; the Skill session’s iterate-one-instruction-at-a-time guided build.

5. Keep it simple, write down the why

The simplest thing that works, and a note on why you chose it. Don’t accept speculative complexity from the AI (YAGNI). Record the decision so the next person - and future you - isn’t guessing.

• Standards anchor: ENG-PRIN-SIMPLE-STMT (KISS, YAGNI, don’t reinvent the wheel) and ENG-PRIN-DOC-STMT (capture the decision in a durable artifact).
• In the room: the Skill’s “Reuse notes” section; the Build session’s one-page ADR capturing a real trade-off.

The take-away card (front / back)

FRONT - the five imperatives:

1. Describe before you generate.
2. A human always signs the work.
3. Mind what you feed it.
4. Small steps, not big leaps.
5. Keep it simple, write down the why.

BACK - good vs. not-yet:

Printable version lives in assets/. The cheatsheet and both session cards pull their wording from this file.