PRD In, Merged Code Out: Deploying a 24/7 Software Factory on GPT-6 Astra

A new flagship model wave has reignited the AGI debate, and this section opens with the loudest version of it: an executive quote declaring that general intelligence has arrived. The host stays skeptical of the slogan, yet reports a genuine shift from hands-on trials — the model grasps intent with less back-and-forth and makes fewer of the strange assumptions that plagued its predecessors.

On paper the two leading models look evenly matched, with public scores pointing in the same direction. The author's week of side-by-side testing tells a different story, with the new arrival coming out ahead in the majority of runs. That split between tied scores and lived experience is worth naming honestly: it is one person's workload, not a replicated measurement, and it should be read that way until someone reruns it.

The core idea has a memorable name: the software factory, also called the dark factory. A product spec or an issue goes in, and reviewed, shippable code comes out, with triage, planning, implementation, validation, and review handled as a pipeline. Earlier this year that promise looked unrealistic; the author's claim is that stronger models plus a sturdier harness have moved it from fantasy to something worth experimenting with — while admitting it is nowhere near fully reliable.

The deployment model matters more than the metaphor. Instead of a laptop experiment, the factory lives on a remote machine that runs around the clock and accepts new work at any hour. The input is always the same — an issue describing what to build — and the output is always the same: a reviewed pull request that either merges itself or escalates to a human. The stated vision is that every individual and every company will eventually keep such a line running in the cloud.

Getting started is deliberately low-ceremony: point a coding agent at the factory repository, paste in the provided setup prompt, and answer its interview questions. The flow covers both directions — a fresh codebase that begins life as a written spec for a minimum viable product, and an existing codebase the factory is layered onto. Testing locally first is the recommended habit; the remote deployment is the destination.

For the live demo the host picks KVM-based virtual hosting and names the mid-tier KVM2 plan as sufficient, while stressing that any Ubuntu machine in the cloud would do. The commercial context belongs in the summary too: the hosting segment is sponsored and comes with a personal discount code, so the specific provider recommendation should be read with that interest in mind.

The setup walkthrough leans on the coding agent for nearly everything. The agent checks local tooling, asks which virtual server is the target, which repository the factory should work in, and which agent should power it — the two tested options being Claude Code and Codex. For the demo the host drives from a familiar local agent while the factory itself runs on Codex paired with the new model, applied over a small prebuilt link-shortener app to keep things fast.

The hosting plugin is the part that makes remote setup feel easy. One install command plus a browser sign-in gives the agent control over the account: it lists instances, takes the VM identifier and public address, and proceeds with SSH access, firewall rules, and application installs. The limits are stated plainly — the plugin cannot create a server by itself, so the machine must already exist before the agent takes over.

Then comes the stretch no agent can cross for you: credentials. The host opens a shell into the fresh server, links it to GitHub with a device code, and signs the remote agent in the same way, after enabling device-code authorization in the chat account's security settings. A one-line greeting command against the new model serves as the smoke test — a reply means the remote side holds working logins for both code hosting and inference.

Installation from that point takes on the order of eight minutes: the factory itself, the Archon workflow engine underneath it, the repository copy, and the configuration. The agent then asks operational questions — host name, port — and proposes a first trial issue drawn from the project's own task list. That issue is filed from the command line, triaged against the factory rules, ranked, and carried through to a validated pull request, with domain settings handled through the same hosting plugin. Once the loop is confirmed, the local session closes and the line stays up, waiting for the next issue — openly labeled early alpha, still being refined.