Article 009: Git as memory, not just version control
Key Message: Git becomes the long-term record of intent. Commits as checkpoints in async work.
Series: B — Reframing the work (Part 4 of 6) Publish Date: Monday 2026-03-16 (TODAY)
Story Outline
Opening: Git as continuity, not just history
Core observation:
- Git was designed for version control: track changes, enable rollback, coordinate teams
- But when work becomes async and agent-driven, Git’s role shifts
- It becomes the continuity layer: the record of what happened while you were away
- Commits aren’t just snapshots of code, they’re checkpoints in ongoing work
- The repository becomes memory, not just history
The shift:
- Synchronous work: Git tracks what you did
- Async work: Git tracks what happened (whether you were there or not)
- The difference matters
The conventional view of Git
Git as version control:
- Track changes over time
- Enable rollback when things break
- Coordinate work across teams
- Resolve conflicts when people edit the same files
- This is what Git was designed for
The workflow we’re used to:
- Make changes locally
- Commit when you reach a stopping point
- Push when you’re ready to share
- Pull to get others’ changes
- Merge when conflicts arise
Commits as checkpoints in your work:
- “Fixed authentication bug”
- “Refactored database layer”
- “Added user permissions”
- Captures what you did, when you did it
What changes with async work
When agents work while you’re away:
- You wake up to commits you didn’t make
- “Generated API endpoints based on spec.md”
- “Added test coverage for payment flow”
- “Refactored to match architectural patterns from plan.md”
- Git is recording work that happened without you
The repository becomes the record of what occurred:
- Not just version control (tracking changes)
- But memory (what happened, why, when)
- The commit history is the story of how the system evolved
- Even when you weren’t present for parts of it
Commits as checkpoints in long-running work:
- Agents don’t work in one session
- They pause, resume, continue across hours or days
- Each commit is a checkpoint: “here’s where we got to”
- When you return, Git tells you what happened since you left
Evidence: How Git’s role expands
Example 1: The overnight implementation
Agent worked overnight implementing the domain API orchestrator (from Article 008).
Morning Git log shows:
23:47- “Initial implementation of orchestrator routing”00:23- “Added parallel enrichment for submission flow”01:15- “Implemented idempotency handling”02:08- “Added error handling with 503 retry hints”03:42- “Final: All acceptance tests passing”
What Git provides:
- Timeline of what happened (you weren’t there)
- Decision points visible (switched from sequential to parallel at 00:23)
- Checkpoints if something needs investigation
- Complete record without your observation
Example 2: The spec-driven development
Article 008’s verified progression workflow depends on Git:
spec.mdcommitted and locked → Git records “requirements approved”plan.mdcommitted and locked → Git records “design approved”- Tests committed and locked → Git records “test suite verified”
- Code committed → Git records “implementation against locked artifacts”
Git isn’t just tracking files changing:
- It’s recording the progression through stages
- It’s locking decisions at each gate
- It’s creating the verified trail
- The commit history proves the process was followed
Example 3: Context for returning
You left Friday with design in progress. Return Monday.
Git log shows:
- Friday: “Draft plan.md with sequential orchestration”
- Saturday: AI review ran, committed feedback doc
- Sunday: Revised plan.md to parallel enrichment
- Sunday: plan.md approved and locked
Git tells you what you need to know:
- What stage the work reached
- What decisions were made (and revised)
- What’s locked and ready for next stage
- No need to ask “what happened while I was away”
Example 4: Agent reading Git as memory
Agent starts work on Tuesday implementing the orchestrator from the locked plan.
First action: Read Git to understand context:
- Checks out latest from main
- Reads plan.md (the locked design artifact)
- Scans commit history: “Why parallel enrichment?”
- Finds Sunday’s commit: “Revised plan.md to parallel enrichment based on AI review feedback re: performance”
- Reads the AI review feedback doc committed Saturday
Agent doesn’t just execute blindly:
- It uses Git to understand prior decisions
- Commit messages explain the “why” behind artifacts
- Context files (review feedback, notes, constraints) all in Git
- Agent reconstructs the decision trail before implementing
Git as bidirectional memory:
- Human commits: requirements, design, approval gates
- Agent reads: understands context, constraints, decisions
- Agent commits: implementation checkpoints, test results
- Human reads: what happened, what was decided, where work got to
This is different from traditional development:
- Traditional: Agent would need you to explain context verbally
- Async: Agent reads Git to understand what happened before it started
- Git becomes the shared memory interface
- Both sides leave breadcrumbs, both sides follow the trail
Implications: Git as the continuity layer
What Git enables in async work:
- Work continues without your presence
- But you never lose the thread
- Commit history is the memory
- Each checkpoint reconstructs the narrative
Git as shared memory interface:
- Humans commit: requirements, designs, approvals, context
- Agents read: understand decisions, constraints, prior work
- Agents commit: implementations, test results, checkpoints
- Humans read: what happened, what changed, what’s ready
This is bidirectional:
- Not just humans supervising agents
- Agents also reading Git to understand context
- Git is how both sides stay synchronized
- The repository is the shared understanding
The shift in how we use Git:
- Commits become more frequent (checkpoint after each stage)
- Commit messages become more descriptive (record intent, not just action)
- Artifacts stored in repo (specs, plans, reviews, context notes)
- Git log becomes your briefing when you return
- Repository is memory, not just storage
Why this matters:
- Async work depends on continuity
- You can’t supervise what you can’t follow
- Agents can’t work intelligently without context
- Git provides the thread connecting yesterday’s work to today’s decisions
- Without it, async work becomes guesswork
What breaks if Git isn’t treated as memory:
- Return to work with no sense of what happened
- Agents start fresh each time, no context from prior work
- Decisions get lost, work gets duplicated
- Supervision becomes impossible
Close: Memory, not just history
The shift:
- Git was version control: track changes, enable rollback, coordinate teams
- Git becomes memory: record what happened, provide context, maintain continuity across time and across async work sessions
- Same tool, different role
- The shift isn’t dramatic, it’s gradual
- But the implications compound
Why it matters:
- Async work needs a memory layer
- Both humans and agents need to understand what happened before
- Git is the shared memory interface
- Commits are checkpoints in work that spans days, not hours
- The repository is where context persists
The pattern I’m observing:
- Teams treating Git as memory succeed at async work
- Teams treating Git as just version control struggle to maintain context
- The difference is recognizing Git’s expanded role
- Adapting workflow to treat commits as formal checkpoints
- Writing messages that document intent and verification, not just action
- Storing artifacts that both sides need (specs, plans, context)
- Using the repository as the source of truth for what happened, not just what changed
The reframe:
- Git isn’t just tracking your changes anymore
- It’s the memory layer that persists when agents work without your presence
- Commits aren’t just snapshots
- They’re the checkpoints that make async supervision possible
- The repository isn’t just storage
- It’s the shared understanding between human and agent
The choice:
- Not whether to use Git (everyone already does)
- But whether to recognize what it became
- And adapt how you use it accordingly
Notes
Threads from earlier articles
| From | Theme | Pick up here |
|---|---|---|
| 002 | Work continues without you | Git records what happened while you were away |
| 005 | Continuity over speed | Commits as checkpoints in long-running work |
| 008 | Verified progression | Git locks verified artifacts at each stage |
Key contrasts to emphasize
- Version control vs memory
- Tracking your changes vs recording what happened
- Snapshots vs checkpoints in ongoing work
- History (what was) vs continuity (connecting past to present)