Case Study: Adding a Feature

The workflow

You create a branch, share the relevant files and the project guide, and write the acceptance tests (or review ones the assistant drafts). You then ask for the implementation in small steps, running the tests after each. Before merging you read the whole diff using the checklist: do all new functions exist, are edge cases covered, are there string-built queries or leaked secrets, and did anything unrelated change? Finally you write the commit message yourself or edit the draft, and the pull request gets a normal human review.

A full assisted feature

A disciplined workflow combines context, tests, small steps and careful review.

The workflow on one page

Each line maps to a section of this course.

1 git switch -c ai/add-reminders                      (Sec 6: isolate)
2 share files + project guide; state constraints         (Sec 2: context)
3 write / review tests first                             (Sec 2, 4: tests)
4 implement in small steps, run tests each time          (Sec 2, 3: steps)
5 review full diff with the checklist                    (Sec 5: review)
6 secrets / licence / policy check                       (Sec 6)
7 human PR review, then merge                            (Sec 7: teams)

Quick check: In the case study, when are the tests written?

• After merging
• Never
• Before the implementation, so success is checkable
• Only if the build fails