Judgment stays put, execution scales out
A question keeps coming up. How do you use a strong model to plan the work and a cheaper model to write the code? It is a reasonable instinct. Planning feels like the expensive, careful part. Typing out an implementation feels mechanical. So the split people reach for is planning on the strong model, implementation on the cheap one.
That split is off in a way that matters. The real fault line is not planning versus implementation. It is judgment versus execution. Judgment is deciding whether a plan is sound and whether a finished diff is safe to ship. Execution is everything in between: turning an agreed spec into code, running the tests, checking the mechanical details. Draw the line there instead, and a lot falls into place.
Storybloq 1.5.0 is three features that each express the same idea from a different angle. Waves let one strong model orchestrate a whole backlog while cheaper models do the work. Team mode lets several people and their agents share one project ledger without stepping on each other. And the multi-lens review engine was rebuilt from the ground up so the gate that catches mistakes is faster and more honest about what it actually saw. This post walks through the idea first, then each of the three.
01 / The split that actually matters
If you watch where an experienced reviewer spends their attention, it clusters in two places. The first is before any code exists, when the plan is on the table: is the approach right, does it account for the edge cases, is the scope correct. The second is at the very end, when the exact diff is in front of them: does this change do what the plan said, does it introduce anything unsafe, is it ready to ship. Everything in the middle, the actual writing of the code, is where the plan gets carried out.
Storybloq treats those two moments as gates. A plan is reviewed before implementation starts. The exact diff is reviewed again before it ships, a pass we call byte-review because it looks at the bytes that are actually going to land, not a summary of them. Both gates are held by the strongest model in the setup. Nothing moves past them without judgment applied.
The consequence is what makes the rest of the release possible. If the plan is checked before code exists, and the diff is re-derived and checked before it ships, then the execution in between can safely run on a cheaper model. A mistake made during implementation has to survive the byte-review gate to reach production, and that gate is watched by the model best equipped to catch it. So the honest answer to the question everyone asks is: yes, use a stronger model for the careful part and a cheaper one for the rest. Just draw the line at judgment versus execution, not planning versus implementation. The planning gate is only half of the judgment. The other half is at the end.
Judgment stays on the strongest model and holds two gates: the plan before code exists, and the exact diff before it ships. Execution scales out to cheaper models in between. The gates are what make pushing execution down a tier safe.
02 / Waves
Autonomous mode, which we wrote about before, drives one item from plan to commit. The wave working style, run with /story orchestrate, drives a whole backlog, or a multi-repo federation, in one continuous pass. It is the largest piece of this release and the part we have been asked about the most.
A wave runs on two planes. The durable plane is the .story/ ledger: tickets, issues, notes, the single source of truth that survives every session. The ephemeral plane is a set of background agents that execute a piece of work and then discard their context. The rule between the planes is simple. Agents report; the orchestrator files. Nothing an agent discovers is real until it lands in the ledger. That keeps the durable record clean even though the agents doing the work are short-lived and disposable.
Work is tiered by model strength, and we give the tiers plain names so the roles stay clear. The pen is the session model, the strongest one. It owns the two gates, it enriches each item into a full spec, and it is the only tier that writes to the ledger. There is one pen per repo. The hands are one tier below the pen; they implement the specs the pen hands them. The inspector is the cheapest tier, the session floor; it does mechanical verification and the checks that do not need judgment.
So a single item flows like this. The pen enriches it into a spec and reviews the plan. A hands agent implements the spec and runs the tests. An inspector agent handles mechanical verification. The pen byte-reviews the exact diff, and if it passes, the item ships and the pen files the result. The strong model touches every item twice, at the two moments that need it, and the cheaper tiers carry the load in between.
03 / Enrichment is the prerequisite
There is a catch that the tiering forces into the open. If a weaker model is going to implement an item, the item cannot be a one-line note. A terse ledger entry that a strong model would quietly fill in from context becomes a guessing game for a cheaper one, and the guess becomes a defect that the review gate then has to catch. So the pen does not dispatch an item until it has been enriched into a spec that a junior could execute without asking questions.
In practice that means each item carries its own context (why this work exists and what it touches), its scope (what is in and what is explicitly out), its acceptance criteria (how you know it is done), and its known pitfalls (the traps someone will otherwise fall into). Enrichment is not busywork. It is where the ambiguity gets removed, deliberately, up front, by the model most able to see it, before it can turn into a downstream defect. If you have ever handed a vague ticket to someone and gotten back something plausible but wrong, you already know why this step is not optional.
Because weaker tiers execute, an item must be an unambiguous spec before it is dispatched. Enrichment is the price of admission to the wave, paid once, up front, by the strongest model.
04 / The model is chosen at spawn
One detail makes the whole thing calm to operate. Each agent is assigned its model at the moment it is spawned, not read from a shared setting while it runs. That means you can change which model the orchestrator uses without disturbing any work already in flight. Agents that are mid-implementation keep the model they started with; only the next ones spawned pick up the change. Swapping tiers is a decision about future work, never a rug pulled out from under current work.
05 / What it did to our spending
We have been running waves across several of our own repos, including the work that produced this release. The honest result is not a dramatic cost headline. What changed is the shape of the spending. The strong tier stopped carrying almost all of the work, and usage rebalanced so the tier that holds the gates and the tier that does the execution each take the share that fits them. That is the point of tiering. It is not a trick to make a given task cheaper. It is a way to stop paying strong-tier rates for work that does not need strong-tier judgment, so the expensive model spends its budget on the two gates instead of on the typing.
We want to be careful about that number. It is what we saw in our own repos, not a benchmark we are claiming will reproduce everywhere. Your codebase, your test suite, and how much enrichment your items need will all move it. The mechanism is the durable part: when the expensive model only spends tokens on judgment and the cheap models carry execution, the average cost of an hour of work falls, and it falls without loosening the gates, because the gates never moved off the strong model.
That is the reason we are comfortable pushing execution down a tier at all. It is not optimism about the cheaper models. It is that the plan is checked before a line of code exists, and the diff is checked again before it ships, both times by the model best equipped to say no. The savings come from execution; the safety comes from the gates; the two do not trade against each other.
06 / Team mode
The second feature answers a different question: what happens when it is not one person and their agent, but several people and several agents, all working the same project. Team mode, turned on with storybloq team init, lets a group share one .story/ ledger through git the same way they already share code.
The hard part of sharing a ledger through git is what happens when two people edit the same ticket on different branches. Left to plain text merging, that produces conflict markers in the middle of a JSON file, which is both ugly and easy to resolve wrongly. Team mode installs a three-way JSON merge driver instead. When two branches change different fields of the same ticket, the driver merges them field by field and the result is a clean, valid file. No markers, no hand surgery on JSON.
When two branches genuinely change the same field to different values, that is a real conflict, and the driver does not paper over it. It records the conflict on the item and blocks further writes to that item until a person settles it with storybloq resolve. The important property is that a genuine disagreement is never silently dropped in favor of one side. It is held, visibly, until someone decides.
Two more pieces round it out. Claims record who is actively working an item, so two agents do not unknowingly drive the same ticket at the same time. And under the friendly display ids you already read (T-001, ISS-013) each item also carries a canonical id, so concurrent work on divergent branches can be reconciled without collisions. Together these let a team and its agents move in parallel on one ledger without corrupting it.
Team mode is opt-in. Nothing about a solo project changes until you run team init. The merge driver, claims, and canonical ids only come into play once you have decided you want to share the ledger.
07 / Review, rebuilt
The third feature is the least visible and, for us, the most consequential. The multi-lens code review engine, the gate that byte-review runs through, was rebuilt end to end on the @storybloq/lenses package. There used to be a second copy of the review logic living inside the main tree, about 5,500 lines of it. We deleted that copy. There is now one implementation of the review engine to maintain instead of two that could drift apart.
The engine reviews a diff through specialized lenses, each looking for one class of problem. There are nine of them now. New in this release is a data-safety lens that looks specifically at SQL, migrations, and schema changes, the kind of change where a small mistake is expensive to undo. Concurrency, which used to be an optional lens, is now a core lens that always runs, because concurrency bugs are exactly the sort that slip past a review that was not looking for them.
How the lenses combine into a verdict also changed. Previously an extra model call read the lens findings and decided the outcome. Now the verdict is computed programmatically by a merge pipeline. That is fewer model calls per review, which makes reviews faster and cheaper, and it makes the outcome deterministic rather than a judgment call layered on top of judgment calls.
The verdict itself is a clean three-value result. Approve means ship it. The middle value means approve with a recommended fix round, small things worth doing but not worth blocking on. The third means revise or reject, the change is not ready. And because a review that keeps re-flagging the same diff wastes everyone's time, the pipeline includes convergence damping so it settles instead of thrashing on the same code across rounds.
The last change is the one we are most glad we made. A review is only useful if its findings are real. Every finding now quotes the evidence it is based on, and the server checks that quoted evidence against the actual reviewed diff. If the quoted line is not genuinely in the diff, the finding is deferred rather than surfaced. In plain terms, the review will not hand you a confident line reference to code that was never there. It has to be able to point at the bytes it saw.
One review implementation, nine lenses with concurrency always on, a deterministic three-value verdict computed without an extra model call, and server-side byte-verification so findings cannot cite lines that are not in the diff.
08 / Built with the machinery it ships
One factual note, because it is the most direct evidence we can offer. This release was built with the wave machinery it ships. The items were enriched into specs, dispatched to tiered agents, held at the plan gate, byte-reviewed before each ship, and landed per item. The rebuilt review engine reviewed its own diffs on the way in. We did not build the feature and then start using it; we used it to build it, which is the main reason we trust the two-gate claim enough to write it down.
Taken together, the three features are one idea seen from three sides. Waves keep judgment on the strongest model and scale execution out across cheaper ones. Team mode lets many hands work one ledger without the judgment about conflicts ever being lost. The rebuilt review engine makes the gate that holds the line faster and honest about what it actually saw. Judgment stays put. Execution scales out. The gates hold. If that is the way you already think about handing work to models, 1.5.0 is the release that lets you run it.