Sizing the work

About 8 min

Sizing the work

mechabedo has a surface for every size of task. A question goes to the chat, a fix stays in one session, and a port across three repositories becomes an endeavor that runs as a graph of sessions you follow on a board. Most wasted effort comes from the wrong size: a graph for a one-line fix spends minutes on planning nobody needed, and a single session on a 9XL rewrite runs out of context halfway and leaves you a half-finished tree.

This page is the ladder, from XS to 9XL, and what to reach for at each rung.

Size by how much changes

A size measures how much of the code changes and how much else it touches, never how many days it takes. The sizes are the ones the agents use themselves:

Size	What it looks like	Where it runs	Reach for
XS	A question, a lookup, one line	Chat or one turn of a session	The chat, mechabedo fast, the Logbook
S	A small edit in one file or one screen	One session	The session alone
M	A few files in one area, a small CRUD screen	One session	`researcher` for orientation, one check
L	A feature	One session with a plan	A plan file, the staff as reviewers, a mode to finish it
XL	A big feature, several stages	One session, a graph where the order is real	The staff to plan, a graph for jobs that wait on each other
XXL	The scope grows significantly, often a second repository	One session with gates	Gates before every contract
3XL	Several areas, each a session's worth of different work	An endeavor	The staff to plan, a session or a graph per area, the board
5XL	Work that touches much else	An endeavor in its own copies	jj copies per node, a verify node per target
9XL	A large blast radius with a real risk of breaking things	An endeavor in phases	One endeavor per phase, each concluded before the next opens

From 3XL up, the work is an endeavor. A session whose kit offers the Endeavors category opens one on its own at that size. It does not ask you first: opening one costs nothing, and the board is how you follow the work.

The line sits at 3XL rather than at the first graph because the two answer different questions. A graph is for jobs with a real order between them, and it pays only when that order exists. An endeavor is for work that splits into areas. One session researches, another makes a neighbouring change, a third owns a whole subsystem, and none of them has to run at the same time as the others. Below 3XL one session holds all of it, borrowing the staff and maybe a graph, and a board would only be overhead.

XS: a question

"Where is cxwin?", "what context sizes do the models on LM Studio have?", "which session fixed the telemetry crash?". Nothing gets built, so nothing needs a harness. The chat on mechabedo fast answers from the tools it already carries: the archive, the machine, the browser.

Two places are faster than asking a model:

The Logbook finds what an earlier session already said or measured.
Memory holds what earlier sessions settled in that directory. Sessions read it on their own, so a measurement made once is not made again.

S: a small edit

One file, one screen, one bug with an obvious cause. Type it on a session's prompt line and let it work. The session runs the one check that covers the change and reports what it touched.

Adding ceremony costs more than it saves at this size. Skip the plan, the staff and the graph.

M: a few files in one area

A small CRUD screen, a setting with its UI and its route, a refactor inside one module. Still one session, but now orientation matters: the session hands "where is this done, and what already exists" to the researcher (Subagents), which reads the hundred files and returns only the conclusion.

When other agents are editing the same tree, the session can take a jj working copy of its own and land it when it is done, so nobody sees the change half-finished.

L: a feature

A feature with a backend, a frontend and a test. One session can still hold it, if the work is planned before it is built:

The session writes the plan into the project, where you can read it.
eng-manager reviews the plan before anything is written, and designer reviews it when a screen is new.
The session builds, and staff-engineer reviews the diff for the bugs that pass the checks.

To keep it going until it is really finished rather than until the model says so, end the prompt with /nohalt. If you would rather commit each piece and approve what comes next, use /commit /nextup /askuser /forever (Operation modes).

An L that grows a second stage is an XL. It still stays in the session.

XL: a big feature

Several stages, some of which wait on others: a server change the client depends on, a migration the new screen reads from. One session still holds it, because one person's worth of context covers the whole feature.

The staff plan it before it is built, the same as an L.
Where several jobs really do wait on each other, the session hands them to a graph and stays its parent. Jobs that do not wait on each other are simpler as steps in the session itself.
/nohalt on the prompt line keeps it going through a halt or a premature claim of done.

XXL: the scope grows

The work reaches a second repository, a second team's API, or a platform it was not planned for. It is still one session, but a graph now has to stop for you more often.

Put a gate in front of every contract another stage builds against: the API a frontend will call, the packet format a client will speak. A gate costs you one decision. A contract that changes after three stages were built against it costs those three stages.

A graph node runs in the directory it names, so one graph spans the server and the client without anyone changing directory by hand.

3XL: an endeavor

The work splits into areas, each a session's worth of different work. One area is research, another is a neighbouring change that has to happen first, a third is a whole subsystem with its own tests. Nothing forces them to run in parallel, and some run one after another, but no single session can hold them all, and you should not have to keep their state in your head.

An endeavor is a record that holds it. The session that opens it is its lead:

Drawing the diagram…

Step	What happens
Open	`endeavor_open` with a title, the goal in your words and every directory the work reads from or writes to. The Endeavors board opens beside your work, and the companion follows it
Measure	Anything that decides the architecture is measured before anyone argues about it: does the engine run fast enough, does the hook exist, how long a build takes
Plan	The staff plan it in order. The `researcher` maps what exists, `product-lead` argues the scope and what to leave out, `eng-manager` locks the architecture, the contracts and the test plan, and `designer` joins when a screen is rebuilt. The plan and the stages go into the record
Ask	Every decision only you can take goes on one card. Whether to open the endeavor or to plan with the staff is not one of them
Run	A graph with one node per area or stage, each in the project it works on. Dependencies go only where the order is real, a gate sits before each contract is frozen, and a last node runs the real checks in every target
Conclude	The outcome and the lessons, one sentence each, then a learning pass for the kit that did the work, so the next endeavor starts ahead

Every session the lead opens below it, whether a graph node, a delegate or a task, counts toward the endeavor without being told. The board shows its stage line, 2 of 5 stages · now: Backend contract, and the sessions doing the work.

On a loadout whose kit has Autonomous drive on, mechabedo answers the questions the sessions below the lead ask. On any other kit they wait for you, so the lead decides what it can before it dispatches.

A real one: bots for a battle royale

A user asked a session to build a reinforcement learning gym for Suroi, an open-source surviv.io revival, so that lobbies could be filled with trained bots. That is a 3XL: a headless simulation core in the game server, a Python training package in a repository of its own, a scripted baseline bot, and a server plugin that runs the trained policy in live lobbies. The session sized it as an endeavor in its first thought, and then did the part that separates a good endeavor from a long one: it measured before it planned.

It read the server's game loop and found that the game already supports players without a socket. Bots could therefore run inside the server rather than as fake network clients.
It wrote a probe that stepped a full 80-player game on a faked clock, with every bot firing guns. A normal tick took 3.1 ms. With network serialization skipped it took 0.96 ms, 26 times faster than real time on one core. Those numbers settled the architecture: training runs in the server, and Python talks to batches of headless games.
It saved the numbers to memory, so no later session in the endeavor runs the probe again.
It put four decisions on one card: the branch, the training stack, the first milestone, and how to run the work.

The fourth question should not have been on the card. The session could not tell whether opening an endeavor was its call, so it asked. The endeavor recipe every session carries now begins with this ladder and says that 3XL and above is opened without asking. The card is left for the decisions that really are yours: which branch, which stack, and where the first milestone ends.

5XL: it touches much else

A migration across the codebase, a framework upgrade, a change to something every module imports. Nodes running at once now edit files the others read.

Turn graph Isolation to Offer or Force on Enhance, so each node works in a jj copy of its own and lands back into your tree before anything that depends on it starts.
Give every target its own verify node, depending on the stages that change it, so a break is found next to the stage that caused it.
Write what every node must keep to into the graph's shared constraints once, rather than repeating it in each prompt.

9XL: a large blast radius

A rewrite of the storage layer, a protocol change every installation in a fleet has to survive, a port of a whole product. Something will break, and the question is how much and how far it reaches before anyone notices.

Do not run it as one graph. Split it into phases that each leave the system working, and run each phase as an endeavor of its own:

The first endeavor builds the seam: the interface the old and new halves both speak, with the old half still behind it.
Each later endeavor moves one part across the seam, concludes, and records its lessons.
The learning pass after each one teaches the kit what the phase taught, so the next phase starts from it rather than from the plan you wrote at the start.

Between phases, read what was learned. The Refinery can review the sessions of a phase that went badly before the next one opens.

When the size was wrong

Sign	Size it really was	What to do
The session compacts twice and still has whole areas left	3XL	Ask it to open an endeavor from where it stands; what it finished becomes the first stage
A graph's nodes never wait on each other, but each owns an area	3XL	Open an endeavor over the same nodes, so the board and the lessons keep them together
A graph's nodes each change one line	S or M	Cancel it and give the session the whole change
Two nodes keep breaking each other's files	5XL	Turn on isolation and retry the failed nodes
A card asks whether to plan, or whether to track the work	3XL	Answer it, then tell the session that its recipe already settles this
Every stage is waiting for a decision from you	XXL with too few gates	Move the decisions to the front, on one card or a gate before the first build

Graph runs: the nodes, gates and isolation an endeavor runs on.
Subagents: the staff, and the loadout each one runs on.
Operation modes: keeping one session going until an L is done.
Workflows: Graph Shot and its siblings, which write a graph from one prompt without the session planning it.