Superscalar

Quickly looking around unfamiliar code

Triage scan of an unfamiliar codebase

Use this when someone has just handed you an unfamiliar code project.

Use this when handed an unfamiliar codebase and the goal is a fast structural map, not verified findings.

You want about an hour of rough overview.

~1h wall-clock budget; output is a prioritised attention list.

You do not need carefully checked findings yet — just a list of what to look at first.

Cross-lane consistency is out of scope; retire is deliberately omitted because its cost is not earned back at the exploratory tier.

How:

Dispatch shape:

1. Split into a few main areas.
2. Send several AI agents in parallel, one per area, with no extra rules (Way A).
3. Each agent records its own findings.
4. Combine the notes and sort priorities together.

1. Partition the codebase into N coarse-grained areas (one per component or risk surface).
2. Fan out N inspector sub-agents via the Agent tool — no foundation, no coordination, no retire (Way A regime).
3. Each lane emits findings independently; no shared schema enforced.
4. Operator merges raw notes into a single triage list and ranks by inspection (not by gate).

A 9-area scan finishes in 8–10 minutes. Fast, but contradictions slip through.

9-lane scan in 8-10 min wall-clock. Cross-lane contradictions leak unfiltered — the priced-in trade-off of the exploratory tier.

Checking a payment or login system for security holes

Security audit of a payment or auth backend

Use this when checking payment or login systems, where design-vs-code mismatches become security holes.

Use this when auditing a payment / auth backend where spec-vs-implementation divergence is itself the threat vector.

Quality is non-negotiable here.

Ship-gate tolerates zero hidden contradictions; retire is non-optional before sign-off.

How:

Dispatch shape:

1. Turn the rules on (Way B).
2. Have foundation agents agree on the shape of the data and lock it.
3. Dispatch inspectors in parallel; each ties findings back to specific code lines.
4. Pair contradicting observations and resolve them explicitly.
5. Produce a gap map for the next round.

1. Activate Way-B regime: foundation prelude + parallel issue + in-order retire all on.
2. Foundation prelude: sub-agents read the spec, agree on schema + invariants, lock the shared model before any inspector starts.
3. Parallel issue: fan out 5 inspector sub-agents (Entry 06 n=5). Each finding must ground to a file:line citation; ungrounded claims rejected upstream.
4. Retire — consistency gate: a serial pass pairs cross-lane contradictions ('spec says BCrypt' vs 'impl uses SHA-256') and resolves them explicitly.
5. Retire — completeness critic: emits a gap map (inspected vs skipped) that seeds the next iteration's dispatch plan.

24 minutes elapsed, +118% grounded citations, −40% guesswork, zero hidden contradictions.

Entry 06 A/B (n=8): 24 min wall-clock. +118% grounded refs, −40% speculative claims, 0 hidden contradictions. Wall-clock delta = prelude + retire cost, not parallelism loss.

Reading a lot of files at once (no writing)

Read-only sweep above the issue_width cap

Use this when you need more parallel agents than usual — and every agent is only reading, not writing.

Use this when you want to dispatch above the issue_width cap and can statically prove every lane is read-only.

Read-only means no clash to worry about.

Read-only lanes are write-disjoint by construction; the WAW / WAR hazard class the issue_width cap bounds does not exist here.

How:

Dispatch shape:

1. Check the recommended cap (say, 6 agents).
2. Confirm the host can handle one more (say, 7).
3. Dispatch all 7 read-only agents in parallel.

1. Compute the issue_width cap from §2's formula for the read-only workload class (e.g., w=6).
2. Verify host headroom: host can sustain w+1 concurrent lanes without thrash (memory, FDs, rate-limit).
3. Statically prove every lane is read-only (no Edit / Write / side-effecting Bash); dispatch all w+1 lanes under §2's read-only admission exception.

Wider coverage in the same time, with no quality drop.

Wider coverage at the same wall-clock, no quality regression. issue_width cap bounds write-hazard probability; under proven read-only semantics that probability is zero, so the cap is safely relaxed.

Several small fixes in different files, shipped together

Batched independent edits with planned-order retire

Use this when you have 4-5 small edits in different files that need to ship together.

Use this when 4-5 independent edits ship together and touch disjoint files.

Parallel for speed, but clean history in planned order.

Goal: parallel issue for throughput + in-order retire so the merge log reads in planned order regardless of completion order.

How:

Dispatch shape:

1. Write the desired merge order in the work list.
2. Give each edit its own private working folder (worktree).
3. Run all edits at once.
4. Merge in planned order, not completion order.

1. Record the intended merge order in the work list — the retire-stage ordering invariant, fixed at issue time.
2. Provision a dedicated git worktree per edit lane (§3). Each lane writes exclusively to its own worktree → write-disjoint at file granularity.
3. Dispatch all edit sub-agents concurrently via Workflow.parallel or Agent fan-out; lanes need no coordination because write sets are disjoint.
4. In-order retire: merge completed worktrees back into main in planned order — never in completion order. Reorder buffer holds early-finishers until predecessor retires.

Edits run in parallel, history reads in planned order. Example: 3 edits merged in 5 minutes.

Parallel issue throughput + planned-order merge log + zero file collisions by construction. Reference run: 3 edits merged in planned order in ~5 min wall-clock.

Reshaping a shared piece that many other pieces depend on

Reshaping a shared dependency with many callers

Use this when reshaping a shared piece many other parts depend on.

Use this when reshaping a shared dependency (function signature, type, API contract) that many callers depend on.

Lock the shape first, or the changes collide.

If caller-site lanes start before the lock, they target stale signatures and retire must discard their work. Lock first, fan out second.

How:

Dispatch shape:

1. One foundation agent reshapes the piece and locks the new shape.
2. Do not start dependent edits until the lock is in place.
3. Then send all dependent agents in parallel to update their callers.

1. Foundation prelude: one foundation sub-agent reshapes the piece, writes the new signature / type / contract to a lockable artefact, and commits the lock.
2. Admission barrier: no dependent-edit lane admitted until the foundation lock is in place (§3 admission-gate precondition preventing stale-target dispatch).
3. Post-lock fan-out: dispatch all caller-site sub-agents in parallel against the locked shape, each updating its own caller code. All lanes read the same locked design → cross-lane consistency at the shared boundary is invariant by construction.

No collisions at the shared boundary. Example: 3 agents, 3 files, zero collisions.

Zero collisions at the shared boundary by construction (not by reconciliation). Reference: 3 sub-agents updated 3 separate caller files in parallel post-lock, 0 shared-boundary collisions.