Techcle Wiki

Social

4 min read

Article 009: Social Media

URL: https://thelongrun.work/articles/009-git-as-memory

Medium

Tags (5 max)

  1. Technology
  2. Software Development
  3. Git
  4. Programming
  5. Software Engineering

Subtitle

“Git becomes the long-term record of intent. Commits as checkpoints in async work.”

LinkedIn Posts

Post 1: Publish-day (2026-03-16)

Git was version control. Now it’s something different.

I wake to commits I didn’t make. “Generated API endpoints based on spec.md.” “Added test coverage for payment flow.” Work happened overnight. Git recorded it.

But here’s what changed: the agent reads Git too.

Tuesday morning. Agent starts implementing the orchestrator. First action: reads the locked plan.md. Scans commit history. “Why parallel enrichment?” Finds Sunday’s commit explaining the decision. Reads the AI review feedback committed Saturday. Reconstructs the decision trail before implementing.

This is bidirectional. I commit requirements, designs, approvals. Agent reads to understand context, constraints, prior decisions. Agent commits implementations, checkpoints. I read to understand what happened while I was away.

Git isn’t just tracking changes anymore. It’s the shared memory interface. Both sides leave breadcrumbs. Both sides follow the trail.

Async work needs a persistence layer for context. Git became it.

New article: Git as memory, not just version control https://thelongrun.work/articles/009-git-as-memory

Visual idea: Split timeline showing bidirectional flow:

  • Top: Human commits (spec.md → plan.md → approval) with timestamps Friday/Saturday/Sunday
  • Middle: Git repository as the center/memory layer
  • Bottom: Agent reads (scans commits, reads artifacts) then commits (implementation, tests) Tuesday morning Arrows showing both sides reading and writing, with Git as the persistent shared memory between async sessions.

Post 2: Insight (2026-03-23)

Monday morning. I check the Git log for what happened over the weekend.

Friday 16:00: “Draft plan.md with sequential orchestration” Saturday 10:00: AI review ran, committed feedback doc Sunday 14:00: “Revised plan.md to parallel enrichment based on AI review feedback” Sunday 18:00: “plan.md approved and locked”

This tells me everything. What stage the work reached. What decisions were made and revised. What’s ready for the next stage.

The repository answers “what happened while I was away” without me having to ask.

This is different from traditional Git use. Traditional: “what changed?” Now: “what happened?” The shift matters.

Commit messages become more descriptive. Recording intent and context, not just action. “Revised to parallel enrichment based on AI review feedback re: performance” tells a story. “Updated plan.md” doesn’t.

Artifacts get stored in the repo. Specs. Plans. Review feedback. Context notes. Everything both human and agent need to understand decisions.

The Git log is my briefing when I return. Not just a diff viewer. A narrative of what occurred.

How are you using Git differently now?

https://thelongrun.work/articles/009-git-as-memory

Visual: Git log view showing the chronological commits Friday→Saturday→Sunday with descriptive messages telling a story. Contrast with a traditional log showing terse messages that don’t explain decisions.

Post 3: Reflection (2026-04-13)

“Just use better commit messages” misses the point.

Git as memory isn’t about message quality. It’s about what gets committed.

Traditional Git: code, configuration, maybe some docs.

Git as memory: requirements (spec.md), design artifacts (plan.md), AI review feedback, approval gates, context notes, constraints documentation, decision rationale.

The repository becomes the shared understanding between human and agent. Not just what changed, but why it changed, what was verified, what alternatives were considered.

Without this, async work becomes guesswork. Agent starts fresh each time, no context from prior work. Human returns with no sense of what happened. Decisions get lost, work gets duplicated.

Teams treating Git as memory succeed at async work. Teams treating Git as just version control struggle to maintain context.

The difference isn’t tool configuration. It’s recognizing what the tool became.

Same repository. Different role. The shift is gradual but the implications compound.

https://thelongrun.work/articles/009-git-as-memory

Visual: Two repo structures side by side:

  • Left (traditional): src/, tests/, docs/, config/
  • Right (memory): src/, tests/, specs/, plans/, reviews/, context/ — showing the additional artifacts that create shared memory

Or: Timeline showing how repository usage evolved from “track code changes” to “persistence layer for context and decisions”

Graph View