Skip to main content

Operating at N>1 Developers

In one line: What makes a solo-operator methodology survive a second developer — repo-as-memory, branch protection, deploy locks, generated STATE.md, named incident roles.

The methodology was forged by a solo operator driving AI agents; these are the additions that let it survive a second developer:

  1. Shared knowledge has an authoritative home. Personal auto-memory is not team authority. Keep technical records in approved versioned repositories and business decisions in their governed workspace; link exact revisions rather than creating competing masters. An onboarding entry point maps controls, commands, access and knowledge locations. Respect audience boundaries instead of copying confidential material into every repository.
  2. Repository controls supported by the selected plan and visibility. Public repositories can have protections on free plans; private-repository capabilities depend on plan. Verify GitHub eligibility and effective settings. Do not prescribe organization migration on a false universal premise.
  3. Deploy serialization. Coordinate releases with active jobs through the actual deployment controller and shared resource boundary. A local file lock coordinates only participants that use it; it does not stop an independent host, credential or worker. Verify concurrency and recovery before claiming protection.
  4. State reports disclose their source. Use a supported generated report where helpful, with observed revision/time and unknown states. Git activity does not prove deployment or active priorities. Preserve authored material; do not delete a teammate's report merely because it is stale. Correct or supersede it through the agreed process (§11).
  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.