---
type: "post"
id: "orchestrating-a-one-person-software-factory-run-many-5705c0"
slug: "orchestrating-a-one-person-software-factory-run-many-5705c0"
title: "Orchestrating a One-Person Software Factory: run many coding agents without becoming their PM"
description: "Oskar Groth describes how he coordinates coding agents across a one-person software company: lane-level orchestrators delegate to agents that own discrete outcomes, while GitHub issues and pull requests provide the shared record and review gate."
retrieval_nugget: "Oskar Groth describes how he coordinates coding agents across a one-person software company: lane-level orchestrators delegate to agents that own discrete outcomes, while GitHub issues and pull requests provide the shared record and review gate. He reports 5,001 commits across his company’s repositories in two weeks, but the account is a single operator’s experience, not a controlled productivity study."
published_at: "2026-11-11"
updated_at: "2026-11-11"
record_date: "2026-11-11"
date_kind: "published_at"
topics: ["coding-agents","github","claude"]
entities: ["Oskar Groth","Cindori","Claude Code","Codex","Backdrop","Sensei","GitHub"]
related_patterns: ["ai-native-orgs-move-to-review-and-orchestration"]
novelty_label: "new_fact"
what_changed: null
prior_refs: []
source_url: "https://oskargroth.com/blog/orchestrating-agents"
source_urls: ["https://oskargroth.com/blog/orchestrating-agents"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:orchestrating-a-one-person-software-factory-run-many-5705c0"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/orchestrating-a-one-person-software-factory-run-many-5705c0/","markdown":"https://newruntime.com/posts/orchestrating-a-one-person-software-factory-run-many-5705c0.md","json":"https://newruntime.com/posts/orchestrating-a-one-person-software-factory-run-many-5705c0.json"}
markdown_url: "https://newruntime.com/posts/orchestrating-a-one-person-software-factory-run-many-5705c0.md"
---

# Orchestrating a One-Person Software Factory: run many coding agents without becoming their PM

## Retrieval answer

Oskar Groth describes how he coordinates coding agents across a one-person software company: lane-level orchestrators delegate to agents that own discrete outcomes, while GitHub issues and pull requests provide the shared record and review gate. He reports 5,001 commits across his company’s repositories in two weeks, but the account is a single operator’s experience, not a controlled productivity study.

## Summary

Oskar Groth describes how he coordinates coding agents across a one-person software company: lane-level orchestrators delegate to agents that own discrete outcomes, while GitHub issues and pull requests provide the shared record and review gate. He reports 5,001 commits across his company’s repositories in two weeks, but the account is a single operator’s experience, not a controlled productivity study.

## What happened

In an essay dated October 28, 2026, Groth explains that running Claude Code and Codex had initially multiplied his conversations without removing his role as the connection between them. He copied work between threads, tracked which agent was editing which area, and handled context loss himself. The coordination problem, rather than the agents’ ability to produce code, became the bottleneck.

His system divides work into lanes such as Backdrop, Sensei, marketing, customer support, and a platform lane spanning several repositories. Each lane has an orchestrator that receives ideas and questions, delegates work, tracks progress, and escalates decisions. A company-level orchestrator routes cross-lane work and sends a daily digest. The orchestrators do not build: each distinct outcome has one visible owner, working in its own Git worktree and branch. Recurring tasks, including checking analytics and crash reports, run as scheduled routines and report summaries to the relevant orchestrator.

GitHub acts as the shared source of truth. Each piece of work has an issue recording its mandate, owner, pull requests, and next action; a company board tracks larger goals and their sub-issues. Every change goes through a pull request, with review by at least one agent that did not write it. Before a merge, the orchestrator checks that the change stays within an approved outcome, clears checks, and does not conflict with other work. The independent reviewer checks the code; the orchestrator’s clearance is a separate scope and coordination gate. Groth says people retain decisions over customer-facing changes, releases, spending, credentials, irreversible actions, and product direction.

Groth first ran the approach in Codex for about a month, then moved it to Claude Code. He says every Backdrop pull request was coming from a Claude Code branch within about a week of the move. From the end of September to mid-October, Cindori’s repositories recorded 5,001 commits; Backdrop alone had 2,028 commits and merged 478 pull requests in two weeks, while Sensei merged 662 in five days. He describes the company as a one-person operation. The setup runs on a Mac Studio, with remote control allowing him to follow work away from the desk. Groth also identifies rough edges: session messaging limits, unreliable completion notifications, and orchestrators’ inability to start new sessions without a person.

## What the archive adds

New Runtime’s earlier coverage described software factories as systems that route engineering work through agents, verification, and human review. [SuperPlane 1.0 launches as an open-source, model-agnostic software factory around coding agents](https://newruntime.com/posts/superplane-1-0-launches-as-an-open-source-14c409/) (November 2, 2026) covered a shared product workflow; Groth’s account is a new practitioner case, not a restatement, and adds detailed operating rules and reported output from a one-person company.

## Trend signal

This case supports [AI-native organizations move toward review and orchestration](https://newruntime.com/patterns/ai-native-orgs-move-to-review-and-orchestration/): Groth shifts his role from coordinating individual production to setting mandates, routing work, and making a smaller set of consequential decisions. It also illustrates why verification capacity and ownership rules matter when agents produce work in parallel. The reported commit volume is not, by itself, evidence that throughput translates into verified user value.

## Why now

Groth connects the workflow’s feasibility to agent sessions that can message other threads, a capability he says arrived in the Codex app during the summer. He then moved the setup to Claude Code after trying it with Opus 5.5, which he says handled delegation and follow-up more effectively. The sequence is his account of why the system changed at that point, not a general comparison of the tools.

## Connections to other events

New Runtime’s earlier coverage on September 1, 2026, described coordination layers around coding agents becoming a distinct product surface in [Local Coding Agents Are Becoming Shared Workspaces](https://newruntime.com/posts/local-coding-agents-are-becoming-shared-workspaces/). Groth’s approach reaches a related problem through personal operating rules rather than a shared-workspace product: distinct owners, a common record, and bounded human decisions.

## Why it matters

The useful lesson for teams is not to maximize the number of concurrent agents. It is to define who owns each result, where the durable state lives, what counts as evidence of completion, and which decisions remain human-owned. Groth’s division between independent review and merge clearance is particularly important: one agent checks the change itself, while another coordination step checks scope and collisions. That separation can make parallel work easier to inspect than a collection of loosely connected chat threads.

The case also sets a caution against treating activity as impact. Commits and merged pull requests measure repository throughput, not defect rates, customer value, or the time Groth spent designing and maintaining the workflow. Teams adapting the pattern should track review findings, rework, deployment outcomes, and human decision load alongside output volume. The orchestration layer can reduce routine supervision while making approval queues and interface design the next bottlenecks.

## Limits and uncertainty

The numbers are Groth’s own measurements for Cindori’s repositories over specific periods. The essay does not establish how much of the increase came from orchestration, model changes, task mix, or other factors, and it does not compare the workflow with a control group. Commit and pull-request counts do not show whether quality, customer outcomes, or total labor improved. The essay also reports continuing operational limits, including message caps and unreliable completion notices; independent replication of the system’s results is not established.

## Skill to build now

This week, take one recurring coding task and write a one-page mandate that names a single owner, the expected user-visible outcome, the repository record, the required independent review, and the decisions that must be escalated. Keep orchestration separate from implementation. The source’s concrete model is to let the owner carry work through testing and its pull request, while a reviewer who did not write it checks the actual diff and evidence.

## Reader takeaway

A one-person software factory is less about autonomous agents than about explicit ownership and gates: one orchestrator routes work, one agent owns each outcome, GitHub records the state, and independent review precedes merge. Groth’s striking output figures are a useful case to study, not a transferable guarantee. Measure verified outcomes and human oversight—not commits alone—when testing the pattern.

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Coding Agents](https://newruntime.com/topics/coding-agents.md): Explore the coding-agents topic hub.
- topic hub: [Github](https://newruntime.com/topics/github.md): Explore the github topic hub.
- topic hub: [Claude](https://newruntime.com/topics/claude.md): Explore the claude topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Sources](https://newruntime.com/sources/): See the original sources this archive cites.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)