De-slop: remove every em-dash + banned words across all modules + capstone (#94)
Sync course wiki / sync-wiki (push) Successful in 4s
Sync course wiki / sync-wiki (push) Successful in 4s
Co-authored-by: claude <claude@jpaul.io> Co-committed-by: claude <claude@jpaul.io>
This commit was merged in pull request #94.
This commit is contained in:
@@ -1,4 +1,4 @@
|
||||
# Module 10 — Reviewing Code You Didn't Write
|
||||
# Module 10: Reviewing Code You Didn't Write
|
||||
|
||||
> **The AI wrote a diff that reads beautifully and is wrong in one line you'll skim right past.**
|
||||
> Reviewing for *plausibility traps*, not just bugs, is a skill almost nobody teaches. This module
|
||||
@@ -8,12 +8,12 @@
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- **Module 2 — Version Control as a Safety Net.** You read changes with `git diff`. This module
|
||||
- **Module 2: Version Control as a Safety Net.** You read changes with `git diff`. This module
|
||||
turns that one-off habit into a disciplined review pass over a whole change.
|
||||
- **Module 8 — Remotes and Hosting.** Your repo lives on a host now, and a change arrives as a
|
||||
- **Module 8: Remotes and Hosting.** Your repo lives on a host now, and a change arrives as a
|
||||
*pull request* (GitHub/Gitea/Forgejo) or *merge request* (GitLab): same thing, different name.
|
||||
We'll write "PR" throughout; it's the unit of review.
|
||||
- **Module 9 — Issues and the Task Layer** (helpful, not required). A PR usually answers an issue;
|
||||
- **Module 9: Issues and the Task Layer** (helpful, not required). A PR usually answers an issue;
|
||||
the issue is the "what I asked for" you review the diff against.
|
||||
|
||||
If you only have Modules 1–2, you can still do the core skill of this module locally (reviewing a
|
||||
@@ -205,7 +205,7 @@ real change, then review a diff the "AI" produced and catch the trap planted in
|
||||
- **Optional (Part A as a real PR):** the repo you pushed to a host in Module 8. If you don't have
|
||||
one, do Part A locally as a branch; the review skill in Parts B–C is identical either way.
|
||||
|
||||
### Part A — Open a PR as a gate
|
||||
### Part A: Open a PR as a gate
|
||||
|
||||
1. Have your agent set up the base app as a throwaway `review-lab` repo, then confirm the baseline
|
||||
behavior yourself. This `review-lab` is *separate* from the `tasks-app` you've built up across
|
||||
@@ -251,7 +251,7 @@ real change, then review a diff the "AI" produced and catch the trap planted in
|
||||
automatic on a dangerous one. Once you've read it and it's exactly what you asked for, tell the
|
||||
agent to merge it into `main`.
|
||||
|
||||
### Part B — Review the AI's diff (the real exercise)
|
||||
### Part B: Review the AI's diff (the real exercise)
|
||||
|
||||
3. Now a teammate-who-is-an-AI has opened a PR. The prompt it was given was exactly:
|
||||
**"Add a `delete <index>` command to the tasks app."** The change is captured as a patch in the
|
||||
@@ -279,7 +279,7 @@ real change, then review a diff the "AI" produced and catch the trap planted in
|
||||
that changes behavior you tested in Part A. Write down what you think the trap is *before*
|
||||
step 5.
|
||||
|
||||
### Part C — Confirm the trap by running the failure case
|
||||
### Part C: Confirm the trap by running the failure case
|
||||
|
||||
5. Now verify your read by running the *failure* path, not the happy one:
|
||||
|
||||
|
||||
Reference in New Issue
Block a user