Code Factory: Organizational Transformation and Practical Validation of AI-Driven Software Development
AI Software Development Enters the Factory Era
This essay is available in three complete language versions
In recent years, breakthroughs by AI Agents in code generation once heralded a leap in software productivity. The FR-01 report predicted that the bottleneck would shift from 'writing code' to 'intent expression and verification,' with Agent proactivity being key. However, the latest practical evidence—three actively running systems—collectively reveals a critical hierarchical misjudgment: what alters the software production function is not the autonomy of individual Agents, but an industrialized 'factory' composed of 'pipelines + worker pools + gatekeeping.' This discovery not only validates the previous assessment of the bottleneck's shift but also institutionalizes it into concrete engineering constraints and organizational forms, forcing us to re-examine the critical variables of AI software production and revealing how channels, gatekeeping, and orchestration security become decisive factors for delivery capability in the new paradigm.
01Reshaping Software Production: From Individual Operations to a Factory System
The core assertion of the FR-01 report—that proactive, replicable execution entities emerge in software production, and the bottleneck shifts from 'writing code' to 'intent expression and verification'—has been validated in practice, but its 'unit of measurement' was proven to be off by one level. Over the past week, three real systems collectively demonstrated that the upgrade of the production function is driven not by the autonomy of individual Agents, but by a factory model comprising 'pipelines + worker pools + gatekeeping.' This implies that the software production function has expanded from the initial `Q = F(I, C, V)` to `Q = min(I, C, V, S, $)` Therein, the newly added `S` represents 'orchestration security' (concurrent exclusion, leases and watchdogs, worktree isolation, strict success criteria), and `$` represents 'budget constraints' (daily circuit breakers). These two variables, entirely absent in FR-01, directly determine whether an AI factory can operate continuously and efficiently, becoming new hard constraints.
Along with the reshaping of the production function, the proactivity threshold has also been upgraded. L3 (long-duration autonomy) is no longer a sufficient condition; the true critical point lies in the triplet `(L3 capability) × (non-interactive channel) × (mechanical gatekeeping)`. With L3 capability but lacking a non-interactive channel, Agents can only run by being 'fed' by humans and cannot be scheduled at scale. Conversely, if L3 and non-interactive channels are present but mechanical gatekeeping is absent, Agent outputs will be difficult to audit, and trustworthiness will be impossible to establish. Practice has also revised the previous understanding of bottlenecks: the verification bottleneck has not disappeared but has been institutionalized into a combined challenge of 'gatekeeping design + trust calibration + acceptance bandwidth,' with cost, for the first time, becoming a primary constraint as important as functionality. These revised mechanisms collectively point to one conclusion: what is reproducible is not free capacity, but isolated and capped capacity; code regeneration must be predicated on traceability, otherwise it will incur 'rescue debt'; and mechanically adjudicable gatekeeping is replacing subjective judgment as the sole standard for measuring product quality.
02Practical Insights: Three Real Systems Drive Paradigm Evolution
The implementation of software factories is the most direct evidence of a paradigm shift. `SOFTWARE_FACTORY.md v1.0` (2026-09-20) [Verified·Local] clearly defines four pipelines, including research cycles and engineering factories, covering various worker Agents (e.g., Codex, dsh, Grok), and sets strict scheduling and gatekeeping checklists. The research cycle has completed 51 tasks, 19 published on the main site, 32 backlogged, with new tasks continuously queued. In VoxSign `scripts/factory/` [Verified·Local], the factory operates with mechanisms such as 15-minute cron scheduling, `flock` single instance, worktree isolation, lease watchdog, and daily circuit breakers, generating 103 commits by September 2026. This not only concretizes FR-01's abstract production function into an organizational form but also, through 'double-loop learning' (each design principle annotated with corresponding real incidents, such as 7-29 lease deadlocks, instance collisions, false positives, budgeting only one vendor), demonstrates that the organization is questioning governance variables themselves, rather than merely accelerating old processes. It also reveals a pattern where automated execution shifts the bottleneck entirely to gatekeeping: generative capacity far exceeds gatekeeping throughput, leading to significant backlogs.
The non-interactive channel of `codex exec` is the critical interface for Agents to upgrade from 'tools' to 'labor force.' The VoxSign engineering factory defines Codex as `codex exec --sandbox danger-full-access` (full-permission sandbox) [Verified·Local], and has set up multi-level review channels, such as `codex review --uncommitted`. The `docs/codex-prompts/` directory contains 6 standard prompt files, covering tasks from board review to release gates. Repository history shows the 'Codex AI Team' author contributed 5,488 commits [Verified·git]. This non-interactivity allows Agents to be programmatically invoked, dispatched by cron jobs, queued, and replayed, thus enabling Agents to be schedulable and measurable. This mechanism also forces 'separation of duties' as an engineering constraint: a full-permission sandbox means Agents can cause irreversible consequences, so the factory must limit the blast radius through one-time worktrees, timeout circuit breakers, process group kills, and independent reviews. Its failure mode also shifted from 'poorly written' to 'ran to completion but untrustworthy,' requiring success criteria to be anchored to external facts.
VoiceSign's voice-driven UI (Dynamic UI / Generative UI L1/L2) [Verified·git] extends the 'intent-centric' axiom from the code layer to the interaction layer. Commit `e0fe5a5f7` (2026-09-16) introduced Dynamic UI patches, with the backend appending `ui_patch` fields to VIDS messages in a backward-compatible manner, and clients rendering them by directory. This demonstrates that UIs are no longer compile-time fixed interfaces but streams of patches dynamically generated by voice intent at runtime, confirming the view that 'UI is also a regenerable product.' Concurrently, this system provides a template for bounded autonomy in 'generative' capabilities: explicitly supporting only L1/L2 (selecting predefined components and filling blanks), rather than generating full screens or arbitrary HTML, which is analogous to 'autonomy level classification' at the software layer, indicating that the industry has spontaneously adopted a 'capability ladder + graceful degradation' strategy on the UI side. Its discipline in backward compatibility (old clients safely ignoring new fields, unknown components reverting to plain text, patch generation errors not blocking the main pipeline) also demonstrates the incremental migration characteristic of paradigm shifts. However, this commit did not include `ui_patch` unit tests, and the MVP uses deterministic rules, thus it supports L1/L2 but is insufficient to support strong claims for L3/L4 [Verified·git].
03Paradigm Leap: The F0 to F5 Factory Process and Paradox
This report introduces an F0-F5 classification for factory maturity, measuring the evolutionary path of software production based on observable facts. F0 is the baseline of manual coding; F1 is AI copilot/completion, requiring human acceptance line by line; F2 is interactive Agent, requiring human confirmation at each step. Currently, the engineering form of the 'L3 threshold' in FR-01 has been concretized as F3 'non-interactive long tasks,' meaning Agents can run headlessly, with sandboxes and timeouts, produce verifiable PRs, where builder≠approver, and final merge rights still belong to humans. Further, the F4 'factory' stage requires at least two heterogeneous Workers, queue-scheduled tasks, multiple independent mechanical gatekeepers, human-independent schedulers, cost accounting and circuit breakers, stale-lease watchdogs, and success criteria anchored to external artifacts rather than exit codes, with human involvement limited to production scheduling, sign-off, and external communications. Both the OPC P1 pipeline and VoxSign factory v1 have reached the F4 stage [Verified·Local], but the low gatekeeping pass rate of the research pipeline (32 backlogged items) reveals insufficient D-axis (gatekeeping adequacy) at the F4 stage.
F5 'adaptive factory' is the ultimate goal, with criteria including task sources automatically generated from 'measured gaps,' gatekeeping failures automatically generating revision subtasks, multi-channel parallelism, cross-AI peer review, and automated collection of factory KPIs driving redistribution. Currently, the F5 stage has not been fully achieved. Although the factory has rudimentary 'auto-queued backlog' and 'orchestrator review rework loop' (weak F5), OPC-102 diagnostics indicate that the research cycle is still a 'consumer rather than producer,' with the Jev empty body defect unfixed; the engineering factory README also self-states that 'cross-AI peer review is not implemented, parallel lanes are a v2 topic' [Verified·Local]. The tasks for this report were also manually entered by humans, not auto-generated based on health, constituting self-referential evidence within F4, confirming the current state of not having reached F5. During this transformation, we discovered the 'Factory Paradox' [Inferred]: If the growth rate of gatekeeping strength G is lower than the growth rate of generative capacity I, factory throughput increases but stability decreases, and backlogs and rework will consume all gains. Therefore, the success of moving from F3 to F4 does not depend on how many workers are added, but on whether gatekeeping can scale synchronously with capacity.
04Core Revisions: OPC-104's In-depth Update to FR-01
The OPC-104 report provides comprehensive and profound updates to FR-01, primarily in dimensions such as analytical units, production functions, critical points, bottlenecks, evidence types, metrics, autonomy variables, human role, L4 cognition, and artifact forms. FR-01 focused on the autonomy of individual Agents (L0–L4), while OPC-104 focuses on the organizational form of the 'factory,' emphasizing the systemic role of pipelines, worker pools, and gatekeeping. The production function expanded from `Q=min(I,C,V)` to `Q=min(I,C,V,S,$)`, incorporating orchestration security and budget as hard constraints. The critical point was also revised from L3 to `L3×non-interactive channel×mechanical gatekeeping`, emphasizing schedulability and auditability. The definition of bottleneck was refined from mere 'verification' to 'gatekeeping design + trust calibration + acceptance bandwidth.' The most fundamental shift lies in the type of evidence: OPC-104 upgrades from FR-01's secondary research reports to first-hand operating system data such as local files, scripts, logs, and git history, achieving a qualitative leap from 'literature inference' to 'operational evidence.
The core reason for these updates is that FR-01, as a 'capability-side' paradigm report, successfully predicted the emergence of machine proactivity and bottleneck shifts, but at the time of its writing, practical implementations like factories, non-interactive channels, and dynamic UIs had not yet materialized. Consequently, FR-01 lacked deep insight into the 'organizational and engineering implementation sides': specifically, how channels make proactivity schedulable, how gatekeeping makes proactivity trustworthy, and how orchestration security and budgets make proactivity sustainable. OPC-104's contribution lies in advancing the paradigm from 'Agents can write code' to 'factories can deliver code,' and in this process, expanding the judgment criteria from two axes to four, upgrading from single variables to dual variables (autonomy L and gatekeeping strength G), more genuinely reflecting the complexities and challenges faced by AI-driven software development in practice. The human role has also been further narrowed from 'off-process approver and responsible party' to 'sole holder of final merge rights,' with the `deny git push origin master` mechanism still preserved even under full-permission sandboxes [Verified·Local].
05Cautious Outlook: Ongoing Challenges and Unanswered Questions
Although significant progress has been made in the practice of AI software factories, numerous challenges and unresolved issues remain on the path forward. Firstly, there is an inconsistency in the reported operational figures: `SOFTWARE_FACTORY.md` records 'cycle 51/51 completed, total tasks 51,' while `RESEARCH_OPC_STATUS.md` (2026-09-20 23:50) shows 'total tasks 57, completed 51, queued 6' [Verified·Local]. Although there is no contradiction between the two, this indicates that status reporting standards are not yet unified, and there is a lack of a single authoritative data source, introducing potential interference for measurement and decision-making. Secondly, gatekeeping pass rates and quality scores are not yet structurally retained; the `dup/value/quality` scores of Jev's three gates have not formed a statistically analyzable `health.json`, as pointed out in the OPC-102 defect [Verified·Local], which hinders quantitative analysis of the gatekeeping system's efficiency and effectiveness.
Furthermore, the engineering factory's cross-AI peer review mechanism has not yet been implemented; `scripts/factory/README.md` explicitly states, 'cross-AI peer review not implemented, single AI closed-loop run first' [Verified·Local]. This implies that current 'multi-agent entities' primarily refer to the ability to choose multiple executors, rather than mandating cross-review by multiple Agents, indicating a distance from ideal trust calibration. Although Dynamic UI has been implemented for L1/L2, it lacks unit tests and its MVP uses deterministic rules, making it insufficient to support strong claims for L3/L4 [Verified·git]; the boundaries of its generative capabilities still require further exploration and validation. Finally, the 'Factory Paradox' and F0-F5 criteria proposed in this report are currently [Inferred/Design Values] and have not yet been collected as actual factory KPIs, thus cannot be cited as verified conclusions. These challenges collectively constitute the weak links in the current development of AI software factories, representing key areas for future research and engineering practice.
The practices of September 2026 have propelled the paradigm shift in AI software production to a new stage, correcting our hierarchical misjudgment of 'core variables.' The true revolution is no longer the autonomous capability of individual Agents, but rather their integration into an industrialized 'factory' system that is schedulable, gate-controlled, measurable, and fault-tolerant. `codex exec` opened up schedulable channels for Agents, software factories provided institutional guarantees and safety constraints, and Dynamic UI demonstrated that the form of artifacts itself is shifting from compile-time fixed to intent-driven runtime generation. Facing this transformation, we must confront four critical questions: How can autonomy L and gatekeeping strength G be efficiently paired? How should the boundaries of orchestration security S be defined? How can budget $ ensure it doesn't stifle gatekeeping? And, when gatekeeping becomes the new bottleneck, how can single-person acceptance bandwidth be amplified through external audits, underwriting, and liability systems? These questions are not only the roadmap for OPC to move from F4 to F5 but also the interface connecting the software layer revolution to organizational and business layer transformations.
This is a living public record. Material revisions will be dated and explained.