Where the value is real

The previous dive named the pairing: the agent supplies speed, the workflow supplies direction, and the value is the product of the two. That product is positive only where the direction is held positive — and the place that holds it positive is a slice that is thin, well-specified, and gated.

Thin means two-to-six files of change, not a system. Well-specified means every branch already decided — the success render, the empty state, the error render — so the agent implements rather than chooses. Gated means one command and one runnable check close it, so “done” is a closure over a check, not an opinion.

When all three hold, the slice's direction is fixed at +1 and the agent's speed is a clean multiplier: each unit of speed is a unit of progress. The smaller and more specified the slice, the cleaner that multiplier — a larger slice leaves more surface where an unspecified branch can creep back in.

f6.1.llms.md is the Portal's web-bootstrap brief, and it carries the evidence verbatim. Its “Execution plan — first two stories” walks two user stories end to end as story → agent story → tasks → files → command → gate.

Plan A serves the Portal as a Phoenix app (F6.1-US1 via F6.1-AS1): tasks T1 → T2 → T3, ten files of foundation, endpoint, and supervision, one command (mix deps.get && mix compile && mix phx.server then a curl of /health), and one gate — a 200 ok with the :portal tree booting before the :portal_web tree. Plan B renders a user's courses (F6.1-US2 via F6.1-AS2): tasks T4 → T5 → T6, five files (router, controller, view, two templates), one command, and one gate — a known user renders their courses, an unknown id renders an empty state, and the 422 path is unit-verified via an injected %Portal.Error{}. The path the ordered build assembles is the request lifecycle the companion course works through at the Phoenix request path.

The brief closes with the line that makes the thesis evidence rather than assertion — quoted verbatim:

# f6.1.llms.md — the efficiency check that closes the execution plan
#
Efficiency check: each story is two-to-six files behind one command and
one gate, and every branch (empty state, injected-error render) is already
specified — so the agent implements rather than decides.

Two-to-six files, one command, one gate, every branch specified. That is the shape of a slice where the agent's speed is pure progress.

Hold the direction positive and the question is no longer whether speed helps but how much of it converts. With direction fixed at +1, net progress is speed times specification — and the more completely a slice's branches are pinned, the more of the agent's speed converts to progress.

The meter below holds the agent's speed high and fixed across every setting; the variable is the slice, not the agent. A thin slice pins every branch (specification 100%), so all of the speed converts. A broad slice leaves surface unspecified, so part of the speed is spent on guesses that the workflow must then reverse. Vary the slice and read net progress, with direction held at +1.

The pairing made the value a product; this dive located where the product is positive. It is a thin, well-specified, gated slice: two-to-six files behind one command and one gate, every branch already decided, so the agent implements rather than decides. There the direction is fixed at +1 and the agent's speed is a clean multiplier. The next dive turns the lens around — what happens on an under-specified slice, where the same speed runs the wrong way.

Primary sources for pinning every decision so the value of speed is never spent on a guess, and where the pairing this dive sharpens and the spec a thin slice is specified against are defined in the course.