Orbyt Runs on Loops, Not Prompts.

The thesis.

Justin Bartak's claim is that building Orbyt stopped being a prompting activity and became a systems activity. He does not type the product into existence. He runs loops: autonomous agents that take a spec, build the feature and its tests, run the checks, repair their own failures, and write what they learned back into the repo. His stated role moved up a level, to designing the machine and judging its output rather than typing instructions and correcting them one at a time.

What was found.

One loop, as described, runs end to end without the operator typing intermediate instructions. An agent picks up a spec that defines what done means, which paths must fail closed, and what is out of scope. It reads the repo for context, including docs, conventions, and what previous loops left behind. It builds the feature and the tests together, in Claude Code. It runs the checks. On a red result, it reads the failure, fixes its own work, and reruns until green. Only then does the operator review the outcome, not the keystrokes. Multiple loops run in parallel, each in its own terminal, none waiting on the operator to type the next instruction.

Auto-healing is the mechanism by which the loop repairs its own failures. A red test, a type error, or a broken build feeds back to the agent, which diagnoses, fixes, and reruns. The article states most failures never reach the operator, who instead finds out they existed by reading the log. This healing is bounded: it happens against a fixed definition of correct, encoded as 11,372 tests and a 35-dimension audit harness, and the agent does not get to redefine what correct means. Paths that guard money and access are built to fail closed, so an unhealed failure denies rather than permits.

The loop is described as learning through write-back. Every finished loop is said to leave the repo smarter than it found it: updated docs, a new convention, a sharper rule, and new tests. The article states that this is why the learning survives a change of underlying model. Bartak reports swapping frontier models under Orbyt twice, once by choice and once forced by export controls, and states nothing reset because nothing important lived in the model.

The operator's remaining role is described as four things: intent (what gets built and why), taste (choosing among agent-generated options), the bar (defining and holding what green means), and review (reading outcomes fast enough to keep pace).

The evidence.

This is a first-person account by the operator of the system he built, not an independent audit or a third-party benchmark. The evidence offered in the source consists of: a description of the loop's mechanics (spec to build to test to heal to green to review), the existence of a 35-dimension audit harness and fail-closed paths on sensitive functions, the anecdote of two model swaps completed without reported reset, and a set of scale figures for the resulting product: over 425,000 lines, 11,372 tests, built solo in 32 days for about $400, shipped daily since. No external verification, benchmark comparison, or third-party review of these figures or of the harness is cited.

How it was done.

See methodology.

What it implies.

If the described pattern holds, the engineering work shifts from writing implementation to writing specs as checks, building real feedback signals (tests, types, the build) that run on every attempt, and defining which paths must fail closed. The test suite functions less as a one-time artifact and more as an accumulating record of every mistake a loop has made and fixed. Because the write-back targets the repo rather than a model's context or weights, the system's memory is portable across model swaps, which the article treats as a structural property of the design rather than a claim about any particular model's capability.

What it does not establish.

See limitations.