Git diffs are line-based, which is exactly why markdown and AsciiDoc version beautifully while
Git diffs are line-based, which is exactly why markdown and AsciiDoc version beautifully while
`.docx` and `.pptx` version terribly (Git tracks them, but the diff is useless binary noise and
`.docx` and `.pptx` version terribly (Git tracks them, but the diff is useless binary noise and
merges are impossible). A real argument for moving runbooks, ADRs, and specs out of Word and into
merges are impossible). A real argument for moving runbooks, ADRs, and specs out of Word and into
@@ -81,25 +114,34 @@ repos, so your wiki was version-controlled all along. AI angle: LLMs are native
### Module 4. Getting the AI Out of the Browser
### Module 4. Getting the AI Out of the Browser
The literal answer to Module 1: agentic, editor-integrated AI tools that operate on your files
The literal answer to Module 1: agentic, editor-integrated AI tools that operate on your files
directly (kept tool- and model-agnostic). This works *because* of Module 2: you let the AI edit
directly. Worked example: Claude Code; the criteria for choosing a tool stay vendor-neutral. This
real files only because you can now see and revert exactly what it did.
works *because* of Module 2: you let the AI edit real files only because you can now see and revert
exactly what it did. **This module is the pivot in how git is taught.** From here on, the learner
directs the agent to run git (commit, branch, merge, revert) and verifies the result, instead of
typing the commands by hand.
### Module 5. Commit the AI's Config, Not Just the Code
### Module 5. Commit the AI's Config, Not Just the Code
The instructions you give the model are as worth versioning as the code it writes, and the thesis
The instructions you give the model are as worth versioning as the code it writes, and the thesis
holds here too: the model is swappable, but *your* setup for it is a durable artifact. Most agentic
holds here too: the model is swappable, but *your* setup for it is a durable artifact. Most agentic
coding tools read a committed, repo-level config or instructions file (kept tool-agnostic here; the
coding tools read a committed, repo-level config or instructions file: project conventions, build
principle outlives any one vendor's filename): project conventions, build and test commands, coding
and test commands, coding standards, "don't touch these files," and house style. The principle is
standards, "don't touch these files," and house style. Checking it into the repo means every
tool-agnostic; the worked example uses Claude Code's `CLAUDE.md` so the steps are concrete, and the
teammate (and every automated agent that later operates on the repo) inherits the same setup
filename convention is called out as a stand-in for whatever your tool reads. The motion itself is
instead of each person hand-tuning their own and quietly drifting apart. It also makes AI behavior
now agent-driven: the learner directs the agent to **identify which config files belong in version
*reviewable*: a change to how the AI works on this project arrives as a diff in a PR, like any other
control**, stage them, and commit them. Checking the config into the repo means every teammate
change. (Its full payoff lands once you have a shared remote in Module 8, but the habit starts now.)
(and every automated agent that later operates on the repo) inherits the same setup instead of each
This is the lightweight foundation that Module 21, Skills, later builds into structured, reusable
person hand-tuning their own and quietly drifting apart. It also makes AI behavior *reviewable*: a
playbooks.
change to how the AI works on this project arrives as a diff in a PR, like any other change. (Its
full payoff lands once you have a shared remote in Module 8, but the habit starts now.) This is the
lightweight foundation that Module 21, Skills, later builds into structured, reusable playbooks.
### Module 6. Branches: Sandboxes for Experiments
### Module 6. Branches: Sandboxes for AI Experiments
Branching, merging, and resolving conflicts, positioned as isolation for AI experiments: spin up a
**Not** a re-teach of branch verbs (Module 3 already first-taught `branch` and `merge` on docs).
branch, let the agent try something wild, throw it away or keep it with zero risk to working code.
Module 6 is about **directing the agent to run a risky experiment on a branch**: spin up a branch,
have the agent try something bold on real code, then decide as one call to keep it (merge) or throw
it away (delete the branch) with zero trace on `main`. The learner directs and verifies; the agent
runs the git. Conflicts are covered as something to *recognize and verify*, including the case where
the agent resolved one silently and you never saw a marker.
### Module 7. Worktrees: Running Agents in Parallel
### Module 7. Worktrees: Running Agents in Parallel
Multiple working directories from one repo, genuinely powerful once you're running more than one
Multiple working directories from one repo, genuinely powerful once you're running more than one
@@ -267,9 +309,13 @@ tell you whether the swap was safe.
## Capstone: The Full Loop
## Capstone: The Full Loop
One feature taken end to end: prompt → branch → AI implementation → tests → PR → CI → security scan →
One feature taken end to end: prompt → branch → AI implementation → tests → PR → CI → security scan →
review → merge → containerized deploy, with the committed AI config from Module 5 already in place
review → merge → containerized deploy, with the committed AI config from Module 5 already in place
from the first commit. Everything clicks into a single motion, and learners walk away with a workflow
from the first commit. **Every step is agent-driven**: the agent creates the branch, writes the
rather than a pile of tips. Stretch variant: run the same feature the Unit 5 way (an assistive agent
code and tests, makes the commits, opens the PR, responds to CI and security findings, and runs the
reviewing, an issue-to-PR agent doing the first pass) so the workflow visibly starts running itself.
deploy. The learner *directs* (states intent, sets guardrails, decides what merges) and *verifies*
(reads the diff, reads the CI output, confirms the deployed behavior). Everything clicks into a
single motion, and learners walk away with a workflow rather than a pile of tips. Stretch variant:
run the same feature the Unit 5 way (an assistive agent reviewing, an issue-to-PR agent doing the
first pass) so the workflow visibly starts running itself.
---
---
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.