Skip to content
GRPNR.

Executive Summary

Problem shape

  • ~5M active LOC inside an estate that may appear as ~70M LOC once generated, vendored, duplicated, or templated code is counted.
  • TypeScript packages/apps + Go services/libraries in one monorepo.
  • Assumes GitHub Enterprise-style PR workflows, Kubernetes-based ephemeral runners. If GitLab/Bitbucket, architecture holds; platform APIs map to equivalents.
  • Security constraints may require private networking / regional boundaries — data-residency matters in model selection.

Winning pattern

Not 1,000 agents editing code at once. Instead:

  • 1,000 logical agents as durable workflow instances (Temporal-style).
  • Small number of active edit lanes gated by: ownership, path locks, CI capacity, merge-queue throughput.
  • Temporal for durable recoverable workflow execution at scale; Argo/K8s for concurrency, retry, resource controls; GitHub protected branches + CODEOWNERS + Checks + merge queues as merge-safety control points.

Sequence

  1. Inventory-and-graph phase first — before any broad autonomous edits. Minimum viable graph fuses: repo census; generated/vendored/boilerplate classification; manifest+lockfile dependency graphs; build-time dependency submissions; symbol/reference graphs (CodeQL supports Go and TS/JS); runtime evidence (OTel traces, coverage, selective eBPF).
  2. Role-specialized fleet — inventory, planning, code-modification, test/repair, CI/check, PR, review, stakeholder-Q&A triage agents. Each task in an ephemeral sandbox: pinned toolchains, isolated credentials, path-scoped permissions, reproducible repo snapshot.
  3. Observability as a product — OTel spine; dashboards for queue health, path-lock contention, cost/token burn, test pass rate, PR survival rate, rollback rate, stakeholder-question backlog/SLA.
  4. Safety principle — many small reversible PRs. Affected-project builds, dependency review, CodeQL, required checks, code-owner reviews, merge queues, push protection. Canary PRs start in low-blast-radius, high-test-density packages; expand by wave only when metrics stable.

Headline cost numbers (illustrative “full fleet” base case)

Assumptions: 1,000 logical agents; 200 active max; 4,000 task executions/day; 20 min avg sandbox time; ~0.6M input + 0.06M output tokens per completed task pre-caching; ~40% reusable prompt prefix. Implies ~72B input + ~7.2B output tokens/month.

  • LLM spend dominates infra spend. Mixed-model strategy with meaningful prompt reuse ≈ low six figures/month on OpenAI list pricing (~$89k/mo cached-prefix-heavy cheap lane; ~$223k/mo premium lane; ~$130k/mo mixed routing).
  • Runner compute: ~40,000 sandbox hours/month → often low five figures or less (CPU-bound edit/build/test), unless heavy integration suites run continuously.
  • Gemini flash-tier materially cheaper for same token volume; self-hosted (vLLM/KServe/Triton) cuts marginal inference cost at the price of GPU capacity planning + serving ops + eval burden.
  • Batch APIs (OpenAI, Gemini: −50%) fit offline inventory generation, repo summarization, nightly evals.

Budget rule: small prompts + caching + batching + strict model routing → mid-five to low-six figures/month. Huge repo context in every call + premium models for routine work → six figures arrives fast. Critical optimizations: sparse checkout, affected-project context retrieval, prompt caching, batch offline work, strict routing.