Part III: The User’s Vibe Coding Habits

Burst Development Patterns

The git log reveals a distinctive pattern: periods of intense activity followed by silence, then another burst. This isn’t poor time management—it’s how creative work actually happens.

Phase 1 (Nov 30 - Dec 3, 2024): Initial burst. 310 commits. Project scaffolding, data migration, core architecture. The foundation poured in 4 days.

Phase 2 (Dec 4-16, 2024): Consolidation. 87 commits. Feature development, bug fixes, test coverage. Building on the foundation.

Phase 3 (Dec 17, 2024 - Dec 6, 2025): Dormancy with sporadic activity. 4 commits total. Life happens.

Phase 4 (Dec 7-11, 2025): Revival burst. 140 commits. Major features: Carceral Geography, Observer Layer, Parameter Analysis. The project comes alive again.

This pattern makes sense when you understand vibe coding. The setup cost is high: loading context, remembering where you left off, getting back into flow. Once in flow, staying there is valuable. Traditional development, with its interruption-tolerant workflow, doesn’t require this intensity. Vibe coding does.

The Good Idea Fairy Protocol

One of the hardest challenges in any project is idea management. You’re implementing feature X when suddenly you think of feature Y. Traditional approaches: write it down and forget about it, or get derailed implementing Y when X isn’t done.

The Babylon project uses what’s documented as the “Good Idea Fairy Protocol”:

# From brainstorm/deferred-ideas.md

**Purpose:** This is where good ideas come to WAIT, not die.
Everything here is valuable but NOT part of the current sprint.

**Rule:** If you're tempted to implement something from this list,
ask: "Does it help pass the current failing test?"

## Phase 4+: Control Room & Beyond

### Procedural MIDI Soundtrack
**Source:** Good Idea Fairy 2025-12-08
**What it does:** Programmatically generate music based on game state
**Why wait:** Pure polish, requires working game loop and UI first

The deferred ideas file has 159 lines of structured ideas, each tagged with:

  • Source (where the idea came from)

  • What it does

  • Why we’re waiting

  • Which phase it belongs to

This is idea management that works with vibe coding rather than against it. The flow doesn’t get interrupted because there’s a trusted place for the interrupting thought. You can note “Procedural MIDI Soundtrack” and immediately return to the failing test, knowing the idea is preserved.

Theory-First Implementation

The Babylon project implements MLM-TW (Marxist-Leninist-Maoist Third Worldist) theory as game mechanics. This isn’t retrofitting theory onto code—it’s implementing theory as code. The mathematical formulas exist in academic papers; the code translates them:

# From src/babylon/systems/formulas.py

def calculate_consciousness_drift(
    wage: Currency,
    value_produced: Currency,
    current_consciousness: Ideology,
    k: float = 0.1,
    lambda_decay: float = 0.02,
) -> float:
    """
    Calculate consciousness drift based on material conditions.

    Implements: dΨc/dt = k(1 - Wc/Vc) - λΨc

    Where:
    - Ψc: class consciousness
    - Wc: wages received
    - Vc: value produced
    - k: sensitivity to exploitation
    - λ: decay rate (false consciousness effect)

    Returns positive when W < V (exploited → revolutionary)
    Returns negative when W > V (labor aristocracy → reactionary)
    """

The docstring IS the theory. The code IS the implementation. The tests VERIFY both. This is theory-driven development: you don’t write code and then justify it with theory. You have theory, and the code’s job is to encode it faithfully.

Context Management via claude-mem

One of the biggest challenges in AI-assisted development is context. AI models don’t remember previous sessions. Every conversation starts fresh. This would be crippling for a complex project—except we’ve solved it.

The Babylon project uses claude-mem, a persistent memory system that captures:

  • Session summaries

  • Architectural decisions

  • Bug fixes and their causes

  • Implementation patterns

  • Project state

Over 100+ sessions, the memory has accumulated thousands of observations. When starting a new session, the system provides context about recent work, key decisions, and project state. The AI doesn’t have to rediscover what we learned yesterday—it can read what we documented.

Here’s a sample of what gets captured:

**#6270** 11:58 AM 🟣 **Created Comprehensive Architecture Documentation**
The architecture.rst documentation was created for the Babylon project's
Sphinx documentation system. This file provides a comprehensive overview
of the "Embedded Trinity" architecture consisting of three integrated layers:
The Ledger (SQLite/Pydantic for rigid economic state), The Topology
(NetworkX for fluid relational state), and The Archive (ChromaDB for
semantic memory and AI narrative generation).

This is memory as infrastructure. The AI’s amnesia is compensated by the system’s memory. Each session builds on the previous, not because the AI remembers, but because we’ve built a system that remembers for it.