Skip to main content

Operating at N>1 Developers

The methodology was forged by a solo operator driving AI agents; these are the additions that make it survive a second developer (assessment TA-02/TA-05):

  1. The repo is the memory. Personal auto-memory stores are non-authoritative journals; anything a teammate would need (ops runbooks, deploy gotchas, lessons) lives in repo-versioned docs. A repo-versioned ONBOARDING.md is the single entry point: bootstrap commands, ports, the load-bearing rules, test/eval commands, PR flow, access provisioning, and a where-knowledge-lives map.
  2. Org-owned repo with branch protection. A personal free-plan repository cannot enforce required status checks — making every CI gate advisory. Transferring to an organization on a paid plan (~$4/user/month) is the single cheapest risk reduction available: it converts the test suite, lint, and safety-floor evals from suggestions into physics.
  3. Deploy serialization. Deploy scripts take a lock (flock or equivalent) and refuse when another deploy holds it or a long-running job (ingest, migration) is active. The no-deploy-during-active-job rule existed as prose and was violated within minutes of being written — the lock is the version that works.
  4. STATE.md is generated or absent. Hand-maintained current-state files go stale (the flagship's was 16 days and 85 merged PRs behind while marked "read first"); generate it from git/gh data at session close, or delete it — a missing file is safer than a misleading one.
  5. Incident roles are named. The runbook names who is paged, who can roll back, and where forensic artifacts land — before the first incident, not during it.