Emerging Ideas for AI-Assisted Software EngineeringSeven field guides from Alpha Compose
Alpha ComposeResourcesVisit Alpha Compose ↗

A seven-part collection for software engineers

Emerging ideas for AI-assisted software engineering.

These field guides point towards one engineered agent workflow: resolve what should change, divide the application behind explicit contracts, coordinate bounded workers, automate the predictable mechanics, and learn from the evidence each run leaves.

The full report grew from Jamie's ideas and current practice and was researched and produced by AI in about two hours.

One possible system

From a pile of agent chats to a learning engineering loop.

The model is one component. Pocock resolves intent, Mycelium defines the application contract, FirstMate coordinates delivery, scripts enforce repeatable mechanics, and instrumentation decides whether the system is actually getting better.

  1. 01 / Shape

    Keep modules deep and tasks thin

    Split a project behind strong interfaces, then express change as small vertical slices with explicit acceptance criteria. Pocock's discovery, specification, issue slicing, and TDD keep each agent inside a tractable context without fragmenting the code into trivia.

    See Pocock's workflow →
  2. 02 / Contract

    Make the application graph explicit

    Mycelium divides runtime behavior into small cells with named input and output schemas. The manifest validates how those cells compose, while a projected brief gives an agent only the contract and local context needed to implement one bounded unit.

    See Mycelium's contract layer →
  3. 03 / Coordinate

    Turn intent into durable work

    A liaison records the backlog, writes a bounded task brief, assigns an isolated worker, and routes only decisions back to the human. The filesystem and live worker inventory hold the truth, so a chat can end without losing the project.

    See FirstMate's control plane →
  4. 04 / Execute

    Put scripts around the probabilistic part

    Use ordinary code for setup, file movement, test commands, linting, commits, rollback, and evidence capture. Give fresh agent sessions precise inputs, ask them to write bounded outputs into files, then feed evaluator results back in a structured form.

    See Chen's integrated toolchain →
  5. 05 / Learn

    Instrument the workflow itself

    Capture Pi harness events and project-test evidence: task type, elapsed time, tokens, retries, tool use, pass rates, review effort, escaped defects, and rework. Periodically let an LLM inspect those traces and propose one bounded improvement, then rerun regressions.

    See the observable loop →

Where Mycelium fits

Keep three graphs separate, then pass evidence between them.

Wayfinder's decision graph records why a change is wanted and what remains unresolved. Mycelium's application graph records which runtime cells may connect and what values may cross each boundary. FirstMate's delivery state records who is changing what, in which worktree, and with what result.

They are complementary, not interchangeable. A resolved decision can become a cell-level task; a cell contract can become a worker brief; test and review evidence can update delivery state and expose a new decision. Mycelium supplies the missing middle layer between product intent and agent execution.

Read the Mycelium field guide →

What Kun Chen actually adds

Let the LLM manage the fleet, not make the human imitate a manager.

FirstMate is a persistent liaison over many replaceable agent sessions. It compiles requests into backlog, brief, status, and report files; dispatches isolated workers; and surfaces only the decisions that need judgment. Around it, treehouse supplies reusable worktrees, gnhf runs small fresh-context iterations with notes, commits, and rollback, and No Mistakes turns review, tests, docs, lint, and CI into a guarded delivery pipeline.

The clever part is the boundary: deterministic scripts own repeatable mechanics and durable state. LLMs interpret goals, generate the uncertain artifacts, inspect evidence, and decide what to try next. The workflow is a sequence of versioned inputs and outputs, not one heroic conversation.

The unanswered question

Is the extra engineering really improving performance?

Treat every practice as a hypothesis. Establish a baseline on comparable tasks with the model and reasoning level held steady. Change one workflow variable, repeat enough runs to expose variance, and keep holdout tasks so the harness cannot memorize the benchmark.

Outcome
Completion, escaped defects, acceptance failures
Effort
Elapsed time, tokens, cost, human review and rework
Code health
Change surface, complexity, test strength, next-change cost
Keep a workflow change only when it improves quality-adjusted cycle time. The reflecting LLM proposes; held-out tests and human outcomes decide.

Core workflow

05 core articles

Alongside the engineering loop

Further things I find useful

02 useful extras