The Skill-Driven Software Code Factory We Use Now

A coding agent can pass its tests, close the ticket, and still leave the product wrong.

The mobile page may overflow. Keyboard focus may vanish. The deployed build may not match the reviewed commit. A worker process stopping proves only that the worker stopped.

We stopped asking one agent to specify, build, review, and verify the same job. The factory now has two lanes.

Software factory

Type 1: skill-driven

Loom owns the specification handoff. Inside that lane:

• Grill With Docs interrogates the idea and source files.
• Super Spec turns the source packet into a builder-ready product and technical contract.
• To PRD → Linear turns the accepted contract into an execution graph.

Runner owns governed implementation. Its operating profiles are Runner and Runner Low Burn v2.

Geordi QA checks the product surface after implementation: build identity, desktop/mobile behavior, keyboard focus, screenshots, console/network evidence, and the final PASS, PARTIAL, or FAIL decision.

Type 2: deterministic

Runabout handles work whose manifest and acceptance contract are clear enough for a deterministic state machine, explicit budgets, and proof gates.

Each stage removes a different kind of uncertainty. Each stage must leave evidence for the next.

Start with one plain instruction

The input can be as simple as:

Run Loom on this idea using these files.

Loom is our internal intake and specification workflow. It is not the video-recording product.

Its first step, Matt Pocock’s Grill With Docs, interrogates the idea against the supplied material. It looks for:

• product decisions that have not actually been made
• contradictions between the brief and the evidence
• assumptions presented as facts
• missing acceptance criteria
• scope that cannot be traced to a source

That grilling matters because a polished brief can conceal an unresolved decision as easily as a rough note can.

Loom then builds a source packet and calls Super Spec as an explicit stage. Super Spec compiles the evidence, accepted decisions, boundaries, proof gates, rollout, and rollback into a builder-ready contract. That contract feeds an Oracle PRD and critique pass. Finally, Loom prepares the Linear execution graph, its dependencies and acceptance criteria, and the repository context required to do the work.

The useful output is not a stack of documents. It is provenance. A ticket should trace to a product decision, and that decision should trace to supplied evidence. When implementation drifts, we can determine whether the code departed from the specification or the specification was wrong.

We have used Loom on large work graphs:

• An Entity Doc Hub run produced 6 parent issues and 75 child issues, with 69 dependency relations attempted.
• An Entity Provider Registry run produced 9 parents and 90 children, with 99 relevant issues verified.

Those numbers show the scale Loom can prepare. They are not a claim that every run is complete. During the audit behind this article, one document-integration run had a successful Oracle PRD receipt but no newer end-to-end receipt proving the entire Linear load was complete. We treat that as an intermediate result, not a success story.

Linear is the handoff, not the brain

Once loaded into Linear, the work is an issue graph rather than a bag of prompts. Dependencies are visible. Acceptance criteria sit beside the task. Ready work can be separated from blocked work.

Linear is the shared execution surface. It does not choose how the job should run. That choice happens when Runner is invoked.

A real route can look like this:

Run Runner
manager: Sol mid
worker: Luna high
reviewer: Terra medium

The role split is deliberate:

• Sol manages the queue at mid reasoning.
• Luna implements at high reasoning.
• Terra reviews at medium reasoning.

That exact combination is optional. The important part is that model and reasoning choices belong to the execution contract. Queue management, implementation, and review do not need one blanket cost and reasoning setting.

Runner supervises:

• the issue map and dependency-safe queue
• worker prompts and run state
• tests, gates, and review decisions
• proof receipts and git state
• final reconciliation with Linear

It also distinguishes ready work from a transient retry, an authority block, an explicit pause, or genuine global completion. That distinction becomes important when a long run meets an expired credential, a failing gate, or a product choice the system has no authority to make.

Governed and low-burn are operating choices

Runner governed is for work that needs stronger review and authority controls. Runner Low Burn v2 is for well-shaped work where the main avoidable risk is waste from idle polling, duplicate review, full-context replay, and repeated summaries of an unchanged state.

Low-burn does not remove proof. It keeps active work and review gates while reducing waste around them. If a supervisor repeatedly asks an unchanged queue whether anything happened, swapping in a cheaper model does not fix the loop.

Both modes use the same completion rule. The following must agree:

• tests and required gates
• reviewer decision
• proof receipts
• repository and commit state
• live Linear readback

A process exit is not completion. A ticket moved to Done is not completion. If the evidence disagrees, the run is still open or honestly blocked.

Runabout is a different harness

Runabout is not another Runner profile. It is a deterministic control-plane harness for work whose manifest and acceptance contract are already clear.

It accepts approved work manifests from Loom, Linear, or the command line. It validates admission, drives workers through a finite-state machine, applies budgets, and enforces deterministic proof gates. The locally verified release at the time of the audit was runabout v0.4.0.

The routing rule is simple:

• Use Runner for fuzzy, evolving work that depends on repository context and judgment.
• Use Runabout when the contract is clear enough for explicit states, budgets, and proof requirements.

A rigid state machine gives ambiguous product work false certainty. A fuzzy supervisor gives repetitive, well-specified work extra cost and variance. The contract should choose the harness.

Geordi checks the thing a user can touch

Runner’s gates do not replace Geordi QA. They cover different surfaces.

After implementation, the next instruction is:

Run Geordi QA

The Geordi QA skill makes that a product-evidence gate rather than a vibes pass.

Geordi first verifies build identity. The commit under test must be the commit we intended to test. It then checks:

• desktop and mobile viewports
• keyboard navigation and visible focus
• accessibility behavior
• screenshots and, when useful, video
• browser console output
• network activity
• the final PASS, PARTIAL, or FAIL decision

This layer catches defects that code gates miss. On Waypost, ordinary gates passed before Geordi found two P2 problems: mobile overflow and an invisible keyboard stop. The repair queue fixed both. The follow-up then:

• passed 6 canonical gates at the exact Git HEAD
• produced browser proof across 16 of 16 routes
• left no actionable P0 to P2 findings

Other runs did not get a clean PASS. An Entity roadmap run received PARTIAL PASS because external failures and public-URL drift prevented promotion, even though expected and observed commits matched. An Entity Doc Hub pull request received PASS_WITH_OBSERVATION, with seven screenshots and mobile interactions exercised through native computer use.

Those outcomes need to remain real. A QA system rewarded for green reports becomes a marketing system.

Receipts make the factory auditable

The code is the deliverable. The receipts are what make its history believable. The installable workflows referenced here are Grill With Docs, Loom, Super Spec, Runner, Runner Low Burn v2, and Geordi QA.

A useful proof package can identify:

• the source specification and accepted ticket
• the tested commit
• the gates that ran
• the browser routes and viewports exercised
• screenshots or video captured
• the review and QA decisions
• the final Linear state

Receipts also make failure actionable. An authority boundary needs a decision, not another retry. A matching build with a drifting public URL points to promotion. Passing unit tests with broken keyboard navigation shows that the code gate and product gate are reporting different truths.

This is why the factory is skill-driven. The skills are not prompt wrappers. Loom reduces uncertainty in intent. Runner governs evolving implementation. Runabout executes clear contracts. Geordi QA tests the visible product. The boundaries matter as much as the models.

What remains imperfect

This system is not fully autonomous, and we do not present it that way.

Current gaps include:

• Loom runs that stop before complete Linear readback
• external services that fail during an otherwise valid run
• public URLs that drift from the tested build
• partial QA outcomes that require human judgment
• authority boundaries where an agent must stop and ask

We are tightening the reconciliation between generated issues, dependencies, git state, browser evidence, and final ticket state. We also want lower supervisory token use without weaker review.

The practical lesson is straightforward: do not give one coding agent ownership of specification, implementation, review, and QA. Define the contracts between those jobs. Require each stage to produce evidence the next stage can check.

Then, when an agent says it is done, you can ask whether the product agrees.