The Blueprint for the 100x Developer

My agents could edit the checks that judged their work. An outside reviewer found that flaw in my published audit account. I had built checks that read the same repository the agents could write. I wrote then, "I still did not apply it to the machinery itself."

The checks passed. The boundary did not.

That is the failure behind this blueprint. A worker that can change its own judge can make a passing result mean less than I think it means. The finding established an available path, not that an agent had used it.

What did the outside review change?

I gave the outside reviewer a read only audit procedure. I forbid it from modifying files or configuration. I forbid it from running the suite or scripts, because some apparently observational scripts write committed artifacts. The reviewer records the working tree before and after. A separate builder must reproduce a finding before a fix counts. I make the final call on consequential changes.

That arrangement costs me a second full effort review, a reproduction step, and a human decision. It also limits what the auditor can prove by itself. The failure corpus records where instruments failed, but a record written by my system is not independent evidence that the system cannot edit its gates.

I cannot claim the original permission gap is closed from the cited account. It documents the read only auditor and the review process. It does not show a worker trying to rewrite a governing check under a separately enforced boundary and being refused. I have not run that attempt for this article.

That proof is missing.

Until I can show it fail, the restriction on ordinary workers remains unverified here.

I can delegate a change. I cannot let the same worker define the evidence that earns its acceptance.

What does 100x mean here?

I use 100x as a proposition about scope, not a measured multiplier. I have no controlled comparison showing that I deliver a hundred times another developer's output. The number is unproven.

On October 2, 2026, the building in public page was captured at 664K portfolio source lines and 37,623 automated checks, with one human decision maker and twelve agent officer seats. Those figures are dated. The page changes, and this article did not rerun its counts. The source lines include content bearing files and generated source. They span products and supporting systems, not one application.

As I write in October 2026, I have no paying customers or measured customer demand. All three products are on early access waitlists. These counts describe an internal build. Size is not demand. The counts cannot tell me whether the checks are independent or whether another developer would have built more value with less code.

My terminal setup shows how I arrange development work. This article asks a narrower question: what must an assignment carry so I can decide whether to accept it?

What would I hand to an agent?

I would give the operator one bounded outcome, a change boundary, evidence to return, and a case that must fail. "Improve onboarding" is too broad to accept. It leaves the consequential decisions inside the work.

This is a synthetic account setup assignment. I invented every field, time, and outcome below; I have not run it at Orbyt.

I would give the worker room to implement, but I would keep the acceptance condition outside the worker's account of success. The refusal case matters. A change that saves one user's data but exposes it to another has not met the brief. I would reject it.

How would I decide whether that work passes?

The following log is also synthetic. Its times, reviewer actions, results, and costs are invented. It shows a complete decision record, not an observed Orbyt delivery.

For this invented assignment, I would record three hours elapsed, two submissions, two review rounds, and about 50 invented minutes of attention across two review rounds. I would also record agent usage if I had it. The first diff failed. It belongs in the cost of the accepted result. These invented values measure no real model or product.

I do not have a real accepted assignment with a complete cost record for this article. The worked log above is synthetic. It shows the record I would require, not a productivity result. The documented outside audit did catch a real defect, but its account does not give a complete brief to acceptance ledger for one development assignment.

Where can parallel work help?

I would add concurrent workers only after I can divide ownership and review. Nicholas Carlini's compiler account (opens in a new tab) describes agents colliding when they worked on the same problem. His reported progress improved when tasks became independently testable. That is a reason for me to sharpen the assignment before adding workers.

My officer seats hold recurring responsibilities. Temporary development agents take bounded assignments. More workers mean more reviews. I do not count both arrangements as interchangeable employees or turn the number of active sessions into a productivity measure.

Parallel output only helps when accepted work arrives faster than coordination debt.

The review obligation is concrete. I must know which change was accepted against which brief, which checks were repeated independently, and what remained unknown. I cannot infer that from code volume.

What would I measure before claiming a gain?

I would record accepted changes with elapsed time, human attention, agent usage, review rounds, and defects found after acceptance. I would include rejected attempts because they consumed capacity too. I would compare that record with the work I would otherwise have done, including time spent coordinating workers.

METR's February 2026 update (opens in a new tab) explains why concurrent agent use complicates task time measurement. Its follow up experiment could not provide a reliable estimate of the current productivity effect. I have no controlled estimate for Orbyt either.

A smaller product could create more value with less machinery. I have no customer evidence that this larger portfolio has earned its size. Volume is not value. The bottleneck I wrote about is my judgment: holding the system model, draining the decision queue, and owning the merge. More generated code does not remove those jobs.

What to do Next

I would start with one bounded task and write the result I am willing to accept. I would name the files the worker can change, the evidence a separate reviewer must see, and the case that should fail. I would record a rejection as carefully as an acceptance.

Then I would inspect the judge. If the worker can edit the rule or its inputs, I would require a separately enforced boundary and test a forbidden edit against it. A clean report from the worker's own checks would not answer that question.

Related reading:

• My Stack of Terminals, Documented. the actual development setup behind this proposed workflow.
• I Run a Stack of Terminals. The Bottleneck Was Never the Code. where my attention limits delegated work.
• 84 Ways to Tell Me I'm Wrong. how failures become specific checks.
• Building Orbyt, Part 1: Zero to One in 32 Days the earlier account of building the product.

The multiplier I can defend is accepted work with independent evidence; the 100x figure remains unmeasured.