The Thing Above the Code

January: A Program Was Still a Program

In January 2026, Pär put a penalty-box timer on GitHub. It is a neat little thing: HTML, CSS, JavaScript, some careful roller-derby rules, a deployment file, a handful of commits. The repository is almost quaint now. Not bad. Not primitive. Just legible as one program made in one burst.

That matters because only nine months later, the interesting object is no longer the program.

There are now more than 200 repositories represented in Pär's work index, with 21 marked active and 175 parked. Fifty of those parked repositories have still had coding sessions in the last 30 days. That sounds like a housekeeping nightmare if you assume software is supposed to look like a company portfolio. It looks different if you assume repositories are cheap containers for thought.

The important change is not the repo count. It is what happened underneath it.

By March, Pär was pointing multiple coding models at real projects and comparing what they did. Codex found real security bugs. Qwen sometimes found real issues and sometimes panicked about things that were not problems. Gemini was shallow in review and surprisingly clean as a fixer. This was still recognisably a human running experiments with several clever tools.

By May, that had changed. A 19-hour Drydock build for Gruvor used at least nine worktree builders, Codex reviewers, fixers, formal task envelopes, acceptance criteria and an orchestrating parent session. It produced 50 commits in one day. Most of the data spine it built survived and became load-bearing.

Then, ten days later, a temporary quota windfall sent five Opus agents out in parallel for about 40 minutes. They produced clean code quickly. The later autopsy reached a sentence that now looks much more important than the code itself.

The code was correct. The target was wrong.

That sentence may be the hinge for everything that came after.

The Factory Already Exists

Looking at dotclaude today, the first conclusion is almost embarrassingly clear: Pär does not need somebody to tell him to start using agents.

Dotclaude is not a prompt file. It is an operating system for delegated coding work.

It has executable rules, tested hooks, incident evidence behind rules, model-routing policy, read gates, git guards, paid-API guards, session-state machinery, recovery paths and its own packaged Claude Code extensions. It has separate procedures for Claude building while Codex reviews, and Codex building while Claude specifies and reviews. It has a project-agnostic Drydock that creates isolated worktrees, assigns builders, reviewers and fixers, and requires runnable acceptance criteria. It even has a dormant Superswarm with variant branches, cost watching, recovery and promotion.

Dormant is the interesting word.

Superswarm was not retired because parallel agents failed technically. It was disabled because spare-capacity swarms kept spending their intelligence on whatever work happened to be nearby when the quota needed burning. The machinery could generate. The selection mechanism was weak.

That is a very different problem from the one Pär had in January.

There is also a second half to the machine: Director. Director is not an application and says so explicitly. It is a lab and a library. Questions become tests or experiments. Results become lessons, playbooks or reports. Claims can become stale and get re-tested. Incoming observations are triaged instead of simply accumulated. Things graduate when they have proven enough value to deserve a stable home.

The useful simplification is this: dotclaude governs how agents act. Director governs how beliefs become evidence.

That combination is already stranger and more capable than the usual idea of a personal coding setup.

And it means copying the Storytold approach literally would probably be a mistake.

Storytold Solves a Different Problem

The Storytold repositories are astonishing partly because the work is so uniform underneath wildly different products. Photo editor, vector editor, page-layout program, video editor: different surfaces, similar engineering doctrine. Commands, control interfaces, tests, agent instructions, review rules, parallel contribution patterns. The top spreads out while the bottom converges.

Pär has also made the bottom converge, but around something broader than one product family.

A QGIS plug-in, an iPhone app, a newspaper production tool, an image pipeline, a car service, a podcast system and an experiment about language models do not really want one application architecture. Trying to force them into one would create exactly the kind of framework-shaped complexity Pär normally avoids.

What can be shared is the method.

The same two-model check can travel. The same rule about observed state can travel. The same distinction between a plan and what the machine actually does can travel. The same session handoff can travel. The same insistence that a claim should have a test can travel.

That may be Pär's stronger version of convergence.

Storytold standardises how a family of applications gets built. Pär is increasingly standardising how arbitrary curiosity gets turned into evidence and, sometimes, software.

The danger is that this machinery becomes an industry of its own.

Recent Director sessions are enormous. They drain incoming queues, reconcile lessons, update rules, route notes between repositories, check stale claims and maintain the mechanisms that maintain the mechanisms. Some of that is exactly why 100-plus active-ish repositories do not collapse into sludge. Some of it may also be tax inherited from a time when the models needed tighter supervision than they do now.

That is where the new Opus and Sol class matters.

Bigger Models, Bigger Responsibility

The tempting way to describe a better coding model is that it writes better code.

That undersells the change.

The more important property is that a strong model can sometimes hold a larger coherent responsibility without losing the plot.

Pär's current methods were built through repeated failure. Reversecowork exists because Codex has no access to the Claude conversation, so Claude writes a self-contained specification, Codex builds it, Claude reviews it and the filesystem carries continuity. Drydock exists because independent jobs need isolated worktrees and explicit envelopes. Read gates exist because an agent with a long context can still confidently skip the one document that changes the meaning of the command it is about to run.

Those are not silly rituals. They are scar tissue.

But scar tissue should occasionally be tested against the thing that caused the wound.

The September lane-economics report is a useful clue. In that measurement window, Codex-led work consumed roughly 12 times as much Codex quota per thousand shipped lines as Claude-led reversecowork. The report's explanation is excellent: the expensive seat is the one holding the long conversation. Codex as a bounded subprocess reads a fresh specification and does the mechanical work. Claude retains the larger context and judgment.

That suggests a direction very different from "run 20 agents."

Run fewer expensive minds in long contexts. Give them greater authority over decomposition. Let cheaper or complementary workers execute bounded pieces. Keep independent family checks where a silent mistake would actually hurt. Make the principal model responsible for evidence, not merely for producing patches.

But the newest Sol and Opus models raise a harder possibility.

Maybe even the task envelope is sometimes too small.

From Tasks to Mandates

Consider the difference between a task and a mandate.

A task says: add this endpoint, change these files, satisfy these tests, do not touch those symbols.

A mandate says: this workflow is unreliable. The user-visible contract is here. These are the invariants that may not change. You have read access to the system and a bounded budget. Measure what is actually happening, decide what work is necessary, use a second model family at the risky boundaries, and return when the contract is proven or when you hit a decision that genuinely belongs to Pär.

That is a much larger unit of delegation.

It is also dangerous if the model invents state, silently narrows the problem, or turns an exploration into a rewrite. Conveniently, Pär's own lab has spent months documenting exactly those failure modes.

One of the recent Director synthesis runs examined almost 3,000 behavioural profiles. Its central finding was that the recurring failure across periods was asserting unobserved state. That is almost a design specification for mandate-level agents.

Do not give them more freedom by removing observation. Give them more freedom by making observation cheap and compulsory.

A stronger model should not need 40 extra procedural steps if the environment can tell it what is true. A service can expose health. A UI can be driven and inspected. A deployment can return a receipt. A test can prove the invariant. A work session can see the current repository state instead of trusting a memo. A second model can challenge the few boundaries that matter.

This is one reason DesignCraft is provocative even if nobody should replace InDesign with it tomorrow. Its commands, control interfaces and visual inspection paths mean the agents can operate what they are building. The environment answers questions that would otherwise have to be held in prose.

That may be the next compression target for Pär's own setup.

Not fewer safeguards because the models are smarter.

Fewer words devoted to safeguards because the world itself is more inspectable.

Idea Sprawl Is Not the Bug

There is another place this matters.

The conventional advice for someone with more than 100 repositories would be to prioritise ruthlessly, consolidate projects and stop starting things.

That advice would probably make Pär less productive and substantially more miserable.

The number of ideas is not the thing to optimise away.

The current work index tells an interesting story. Only 21 repositories are formally active, but 50 parked repositories have had a session in the last month. That means "parked" is not a graveyard. It is closer to a shelf where something can wake up for an hour because a new model, a new API or a weird newspaper problem suddenly makes it relevant again.

That is a feature if waking something up is cheap.

The real cost is accidental obligation. An afternoon experiment becomes a service. A service becomes a deployment. A deployment becomes a backup requirement. A backup requirement becomes monitoring. Three months later, nobody remembers why it exists but something still assumes it does.

Director has already discovered this from the other direction. One of its standing principles now says that no new online surface should exist without a named consumer and a noise budget. That came from measuring previous online surfaces that were around 95 percent noise.

There is a broader version of the same rule.

Ideas should be almost free to spawn. Obligations should be expensive to promote.

That means the future system may need to care less about how many repositories exist and more about what promises each repository has made to the outside world.

A local experiment that can rot harmlessly is cheap. A service with credentials, scheduled jobs, customers or production data is not.

The classification that matters is not serious versus silly. It is reversible versus load-bearing.

That fits Pär's actual life much better than a clean project portfolio ever will.

The Thing Above the Factory

So what sits above dotclaude and Director?

Probably not another giant controller.

There is already plenty of machinery.

The missing capability looks more like allocation of attention and responsibility.

When implementation used to be expensive, difficulty performed that allocation automatically. Most ideas died before they had a repository because building them was annoying.

Now a thought can become a working application before lunch. Sol and Opus make the conversion even cheaper. That means difficulty no longer protects Pär from his own idea generator.

The replacement cannot be a bureaucratic approval process. That would defeat the point.

It could instead be an information-gain rule.

Before turning an interesting thought into a maintained thing, ask what the next cheap action can teach. Sometimes that is code. Sometimes it is a five-minute probe. Sometimes it is sending two models in opposite directions. Sometimes it is deliberately building three disposable versions because the unknown is architectural. Sometimes the correct output is a note saying this was fun, it worked, and there is no reason to maintain it.

The key is that exploration can end successfully without becoming production.

This is exactly what happened with Popcorn in reverse. Popcorn deserved to become real because, at the time, making it real was the experiment. It proved Pär could make something that lived outside his own computer. Its continuing value is partly historical. Rebuilding it today would prove almost nothing.

A better experiment today would begin where Popcorn used to end.

Can one strong principal model take a product-level mandate from rough idea through investigation, specification, implementation, independent review, live proof and a clean handoff in one afternoon, while Pär stays mostly at the level of taste, boundaries and decisions?

Not by cheating and accepting a demo.

By shipping something with evidence.

If the answer is yes, then the unit of work has changed again.

A Useful Test, Not a New Religion

There is an obvious way to explore this without redesigning the whole setup.

Pick a sidequest that is real enough to have awkward edges but disposable enough that failure is funny. Give one top-tier principal model a broad mandate rather than a prepared task list. Give it access to the existing rules, Director knowledge and a bounded budget. Tell it to create its own task graph. Require it to use the other model family only at boundaries it judges risky, and require it to state why each gate was worth paying for.

Then measure the boring things.

How many times did Pär have to rescue framing? How many agent decisions were later reversed? How much procedural guidance did the principal model actually need? What proportion of the existing global instructions mattered? Did the principal agent keep looking at reality, or start narrating a fictional machine? Did a second family find problems the principal missed? Did the resulting software leave behind fewer obligations than the current process?

Most importantly: compare it to the current reversecowork method, not to some imaginary human programmer.

This is not a proposal to replace the machinery that already works. It is a way to discover which parts of that machinery have become durable doctrine and which parts were temporary prosthetics for 2026's earlier models.

The result could be surprising in either direction.

Maybe Opus and Sol can own a whole afternoon's mandate and the detailed task choreography starts to look obsolete.

Or maybe they still fail in exactly the old ways, just with more eloquence and better code.

Either answer is valuable.

The Strange Promotion

A year ago, Pär had roughly one GitHub repository and did not really understand GitHub.

Today the interesting comparison is with a developer running fleets of autonomous agents across a suite of creative applications.

That progression is fast enough that it is easy to focus on the visible artifacts: the repositories, the services, the applications, the commit count.

But the bigger progression is in what Pär is doing.

First, asking a model to write code.

Then, operating a coding model.

Then, pairing model families.

Then, directing workers in isolated branches.

Then, writing rules that make those workers safer.

Then, building a lab that measures whether the rules are true.

The next promotion is probably not from amateur programmer to better programmer.

It may be from builder to governor of a very strange little software civilisation.

And a governor has a different problem.

The question is no longer: can this be built?

Almost everything interesting can at least be attempted now.

The question is: what deserves to become real, how much reality should it acquire, and when should a capable machine be trusted to decide the path between those two points?

That is a better problem than not knowing how to make a web app.

It is also considerably weirder.