Instant software factories: cron-job agents plus a shared board, and a factory that grades itself
Wenxin Jiang and Mikola Lysenko describe factories built from only standing-objective cron agents and a GitHub board. In one CLI factory daily merges rose 15x, agents filed 95% of new issues and wrote 40 of 58 CI-changing PRs, and at least 5.6% of issues marked fixed had wrong fixes.
Source: Instant Software Factories
Wenxin Jiang and Mikola Lysenko's arXiv paper, submitted October 26, asks whether the long tail of work that turns a prototype into a product (fixes, optimizations, tests, releases) needs dedicated orchestration at all. Their answer is a deliberately minimal factory. Start from a tested repository and a coding agent, then add two things: a swarm of cron-job agents, each with a standing objective, and a shared board such as GitHub where the agents coordinate through the issues and pull requests they leave behind. Governance sits on top as a separate layer.
They distilled a bootstrap prompt that sets up both pieces from one round of human input, based on two hand-configured industrial factories they watched for 15 and 17 days. The bootstrap itself has not been evaluated yet. The observations from the GitHub-coordinated CLI factory are the interesting part:
- Daily merges rose 15x during the agent rollout, which the authors are careful to call an observed association.
- Agents filed 95% of new issues.
- Agents wrote 40 of the 58 pull requests that changed CI workflows.
- At least 5.6% of issues marked as fixed were later found to have incorrect fixes.
The authors' point is that a factory isn't like an agent scored on a fixed benchmark. It writes its own workload, edits its own evaluator, and so changes what its own progress numbers mean. They frame factory development as multi-objective optimization under that feedback, and lay out a five-month plan with five falsifiable hypotheses.
Why it matters for code review
An always-on factory that files most of its own issues and edits most of its own CI is also choosing its own exam. A 15x jump in merges says little when the same agents set what "fixed" means, and a known 5.6% wrong-fix floor is what a reviewer is up against. Treat pull requests that touch CI workflows or the issue backlog as changes to the grading system, and review them on that basis rather than as routine maintenance. Steady overnight throughput only compounds if the checks it passes are ones the factory couldn't quietly rewrite.