Putting Grok Above Claude: How a One-Person Company Splits Strategy, Construction and Shipping
Table of Contents
In one line: the upper layer decides whether to do it and what it should look like, the lower layer decides how to write it, and only a person ships. Strategy and veto sit with Grok, code changes sit with Claude, day-to-day pass and reject is handled by the construction line, and a human is called only to ship or when the spec looks wrong.
I started out running everything through one model. Working out what to build, same model. Writing the code, same model. That held up for a while, and the problem was never capability. It was round trips.
There were two causes. Every time I changed my mind I had to re-explain the background, and past a certain context length the model started dropping constraints I had stated earlier. The worse one: a model that both proposes and builds will not veto itself. I would ask whether an approach was right, and it would usually tell me why it was, then start writing.
So it is two layers now. The upper layer decides whether to do it and what it should look like. The lower layer decides how to write it. Grok is above, Claude is below.
The upper layer exists to say no
Its job is strategy, spec and veto. The first two are obvious. The third is the point.
I need somewhere whose task is not to help me get the thing done, but to judge first whether the thing should be done and whether the spec is right. That role conflicts with building, because the reward for building is completion, and the shortest path to completion is accepting whatever premise you were handed. Give it a wrong premise and it will build the wrong premise thoroughly.
Putting the veto outside the build is what makes "do not do this" a normal output instead of a failure.
The lower layer finishes, and proves it finished
The lower layer does one thing: turn the agreed spec into something that runs, and show that it actually runs. The proving part takes up more room than you would expect, usually more than the change itself.
Nobody gets called day to day
Pass and reject are handled by the construction line. It finishes, sends the work up through the Grok CLI, and either continues or fixes. No person in that loop.
Two things trigger a call. Shipping. Or the construction line believing the spec is wrong.
The second matters. Finding a problem with the spec halfway through the build is normal in software. The allowed move is to say so. The forbidden move is to rewrite the spec and carry on.
An example from today
While cleaning up the outward-facing copy on our own site, I found this: adding a preview-only parameter to the main site's URL swapped the entire homepage over to a partner's brand, and the state was remembered in the browser, so a clean URL afterwards still returned the partner version.
Three roles, three jobs. Judging that this was a seam that had to be fixed rather than an optimization for the next round was the upper layer. Making the production domain trust only the domain, with the parameter and the browser memory restricted to preview, was the lower layer. Deciding to push it now was the person.
None of the three could complete the loop alone, which is exactly what I want.
What it saves, and what it does not
It saves round trips. A change used to mean repeated pushing inside one window, plus guarding against forgotten constraints. Now direction is settled above before anything goes down, and the construction layer receives a spec that has already survived a round of veto.
It does not save judgment. The upper layer is not the boss; it is a colleague who will say no. It catches obvious errors. It does not catch errors both layers agree on. When the upper and lower layers accept the same wrong premise, the split provides no protection whatsoever and instead builds the wrong thing very efficiently.
That is why a person stays on the shipping gate. Not because people are more accurate, but because irreversible actions need someone who can regret them.
Product direction
Where this is heading is people and AI running a community together, and that being governable. That is the goal, not a feature that is live today. What is live today is scheduling, publishing, replies, monitoring, and someone finding out when those break.
This is a lab weeknote, not a product promise.
FAQ
Why not use the same model for both the spec and the build?
Because the reward for building is completion, and the shortest path to completion is accepting the premise you were given. A model that both proposes and builds will not veto itself: ask it whether an approach is right and it will usually explain why it is, then start writing. Moving the veto outside the build is what makes 'do not do this' a normal output rather than a failure.
When does a person actually need to step in?
Two cases. Shipping, because it is an irreversible outward action: code rolls back, what people already saw does not. And when the construction layer believes the spec is wrong, where the allowed move is to say so and the forbidden move is to rewrite the spec and carry on. Everything else, pass and reject, the construction line handles on its own.
What does this split fail to protect against?
Errors both layers agree on. When the spec layer and the construction layer accept the same wrong premise, the split offers no protection at all and simply builds the wrong thing efficiently. That is why a person stays on the shipping gate: not because people are more accurate, but because irreversible actions need someone who can regret them.
What does it actually save?
Round trips. Previously a single change meant arguing inside one window and guarding against the model forgetting constraints stated earlier. Now direction is settled above before anything goes down, so the construction layer receives a spec that has already survived one round of veto. It does not save judgment; judgment stays with a person.