One-hour team session

A ready-to-run hour for a tech lead or manager. Your team practises checking AI-written code on a real repository, then agrees its first rules for using AI. No slides needed: you share your screen, people work in pairs, and you finish with three decisions written down.

What you need

• People: 4 to 12 developers, QA engineers or both, in pairs. It works in a room or on a call with breakout rooms.
• Each pair: a laptop with Git, and either Node 18 or newer, or Python 3.9 or newer. Nothing else to install.
• The practice repository: the Haunted Repo, a small task tracker with planted bugs and three AI-written patches. Download it once from the debugging guide page and share the zip with your team. It is MIT-licensed.
• Printouts or links: the AI code checklist for everyone, and the team AI policy template on your screen.
• Before the day: send the zip and ask everyone to unzip it and run the tests once, so nobody spends the session installing things.

cd haunted-repo/js && npm test
cd haunted-repo/python && python3 -m unittest

The hour

0–5: Why we are here

Say, in your own words:

Then ask for a show of hands. Nobody has to explain their answer.

• Who used an AI tool for code this week?
• Who has merged something they did not fully understand?

5–25: Exercise 1, green tests and wrong code

An assistant wrote a feature and its tests in one go. Every test passes. A user says the feature is wrong. Pairs have 15 minutes to find out why, then 5 minutes to share.

Each pair runs:

git switch -c session lab-11
cd js && node --test test/due-soon.test.js

Python pairs run python3 -m unittest tests.test_due_soon from the python folder instead. All the due-soon tests pass.

The user's report:

The task: read the "Due soon" section of README.md, which is the specification, then read the tests in js/test/due-soon.test.js or python/tests/test_due_soon.py. Find every place where the tests disagree with the specification. Do not read the code until you have.

Questions for the debrief:

• Which test checks for the bug instead of against it?
• How did the tests end up agreeing with the code?
• What would have caught this before it was merged?

25–45: Exercise 2, review three AI patches

Three patches in the patches folder were each written by an assistant from one request. The requests are in patches/README.md. One patch is fine, one needs a small fix, and one should not go in. Give each pair one patch, or two pairs per patch for bigger groups. Pairs have 12 minutes, then 8 minutes to share.

Each pair runs, using their own patch number:

git switch -c review-1 lab-12
git apply --stat patches/ai-patch-1.diff
git apply patches/ai-patch-1.diff
cd js && npm test

Python pairs run python3 -m unittest from the python folder for the last step. One test fails before and after every patch. It belongs to a known bug that has nothing to do with the patches, so leave it alone.

The task: go through the AI code checklist and give a verdict, accept, fix or reject, with the evidence for it. That means a command and its output, or a line of the patch and the sentence of the README it contradicts.

Questions for the debrief:

• What did each pair decide, and what was the evidence?
• Which checklist item found the problem?
• Which item would you have skipped if you were in a hurry?

45–57: Exercise 3, our first rules

Put the team AI policy template on screen. Do not try to fill in all of it. Agree three things and write them into the template as you go:

1. What never goes into an AI tool here. Start from section 3 and add anything specific to your product or customers.
2. Who owns an AI-written change. Section 4 suggests that the person who opens the pull request owns it, whoever wrote it. Agree it or change it.
3. Which changes get extra review. Use the risk table in section 5. Name the parts of your own codebase that count as high risk.

If the team disagrees on something, write down both views and a date to decide. A rule nobody believes in will not be followed.

57–60: Close

Go round the room. Each person names one habit they will keep from today, for example "write my own test before reading the AI's tests" or "read the removed lines first".

Before everyone leaves, agree:

• who finishes the policy draft, and by when
• where the AI code checklist will live, such as the pull request template or the team wiki
• when you will look back, in about a month, at review time and changes that needed fixing after merge

If something goes wrong

• Someone cannot run the code: pair them with someone who can. Exercises 1 and 3 work from reading alone.
• A patch will not apply: check they are on a fresh branch from lab-12 with no other changes. git status should be clean before git apply.
• Running short of time: cut Exercise 2 to one patch, ai-patch-3.diff, reviewed by everyone together on your screen. Never cut Exercise 3; the decisions are the point.
• A remote session: use breakout rooms for the pairs and bring everyone back for each debrief.

Answer key (facilitator only)

Exercise 1. The specification says the list shows open tasks due from today up to and including N days from now. The code includes finished tasks and leaves out the last day. The tests were written to match the code: one expects a task the setup marks as done, and one asserts that the task due in three days is not returned, so it checks for the bug. Lesson: when code and tests come from the same prompt, read the tests against the requirement before trusting either.

Exercise 2.

The full model answers, with commands, are in the repository: run git show solutions:solutions/patches.md and git show solutions:solutions/bug-11.md.

By Ghost in the Repo, ghostintherepo.com. Free to run, adapt and share in your team.