The Lean AiSE Model

In a previous essay, I explored how building software is analogous to walking a tree-shaped design space, and how vibe coding amounts to flipping coins at every branch. The conclusion: we need to pair intuition with guard rails. For the lean AiSE model we propose a lightweight set of guards that keep the entire process agile enough not to collapse to boring local minima too fast. The process is organized into two parallel tracks: a planning track that shapes what to build, and an execution track that does the work story by story. The two tracks are independent. Planning can run weeks ahead of execution.

Planning Track: From Idea to Backlog

The planning track creates and structures work. It produces a product brief, creates epics and stories in a project management tool, and sets up the knowledge infrastructure. It never touches implementation artifacts (specs, decisions, learnings).

The Product Brief

At the top layer is the product brief: a high-level description of what the product is, who it is for, what problems it solves, what makes it different, and the strategic phasing of how it will be built. This document may seem trivial at first but already has tremendous pruning power. For example, specifying simply “a mobile-first web game for kids aged 6-12 where they can learn elementary math through adventure-style gameplay” already takes away a significant number of sub-trees: mobile-first, target age 6-12, elementary math, etc. all act as signals for decision-making later on. This document captures human intuition at the “product owner” level.

The agent’s job is to help product owners think clearly, not to think for them. It does this by reflecting back what it heard in structured form, surfacing implicit assumptions, and asking the questions that would most narrow the product space. The goal here is to surface all implicit assumptions: for example, the user said “kids,” but does that mean 6-year-olds or 12-year-olds? These age groups need entirely different products. The agent asks questions in pruning-power order: big questions first, details later.

PM Provider Setup

AiSE separates planning from knowledge. The PM tool owns the planning graph: ordering, dependencies, status, naming, assignments. The repo owns the knowledge artifacts: specs, decisions, learnings, ADRs, patterns. The issue ID is the join key between the two.

AiSE is PM-tool-agnostic. It ships provider profiles for common tools (Exponential, GitHub Issues, Linear) and supports working without any PM tool at all. Each provider profile is a markdown document that teaches the agent how to translate abstract operations (“create an epic”, “update status to DOING”) into concrete MCP tool calls or CLI commands for that provider. Adding a new provider means writing one markdown file. No code, no adapters, no shell scripts. The agent reads the profile and bridges the gap.

This design leverages a unique property of LLM-powered systems: the consumer of the PM tool’s API is an LLM, not a program. Traditional software needs explicit adapter interfaces with concrete implementations per provider. An LLM can work with semantic intent (“create a story under this epic”) and self-describing MCP tools to figure out the right call. The “adapter” is the LLM’s ability to reason over available tools.

Epics and Stories

With a product brief and PM provider configured, the planning track creates the backlog:

Epics are the high-level groupings of work. Each epic becomes an issue in the PM tool and gets a knowledge artifact (.aise/specs/{EPIC-ID}/spec.md) capturing its intent, scope, and design decisions. These epic-level design decisions constrain all stories within the epic. This captures human intuition at the “product designer” level.

Stories are the decomposition of each epic into units that can be implemented by an agent in one shot. They live as child issues of the epic in the PM tool. The planning track creates the issues (title, description, labels, estimates, dependency links) but does not write specs, decisions, or learnings files. Those are the execution track’s responsibility.

The agent proposes a complete breakdown: stories with titles, descriptions, size estimates, build order rationale, and dependency links. The developer adjusts, reordering, splitting, merging, adding, removing. The agent explains its sequencing rationale and flags stories that look too large or have external dependencies.

Execution Track: Spec, Build, Review, Retro

The execution track picks up a single story from the backlog and works it through a repeating cycle. It reads from and annotates PM issues (comments, status updates) but never creates them.

The cycle:

spec → build → review ←→ build → retro

Specification

The agent reads the story’s PM issue for context: title, description, parent epic, linked issues, comments. It reads the epic’s knowledge artifact for design constraints. It searches ADRs and patterns for relevant prior decisions. Then it co-authors a detailed spec with the developer.

The collaborative specification process consists of four steps, each with a clear pruning target:

Problem Framing. The agent acts as an interviewer. It reflects the story intent back as a concrete “What” statement, flags assumptions, and asks targeted questions only when the answer would prune a significant branch.

Solution Design. The agent acts as a technical co-designer. It proposes concrete implementation steps and explicitly flags where it made assumptions, so the developer can resolve only the meaningful branch points.

Decision Capture. The agent acts as a software archaeologist. It reads through the existing knowledge corpus (ADRs, patterns, past decisions), surfaces what already applies, and frames new decisions as concrete proposals with tradeoffs.

Edge Case Triage. The agent acts as an adversary. It identifies edge cases from the implementation paths it foresees and triages them by risk: HIGH (developer decides), MEDIUM (agent handles + flags), LOW (agent handles silently).

When the spec is finalized, the agent comments a summary on the PM issue so the story’s narrative is visible without digging into .aise/ files.

Build

The agent implements from the spec, constrained by the decisions, edge case handling, and ADR/pattern rules it helped create. It updates the PM issue status to DOING.

When the agent encounters a decision not covered by the spec, it makes a choice and logs it with context, rationale, and alternatives considered to .aise/decisions/{STORY-ID}/. Equally important: the agent logs learnings (pitfalls hit, dead ends tried, patterns discovered) to .aise/learnings/{STORY-ID}/ so the next agent can build from where this one stopped, not repeat the same dead ends.

If the agent realizes the spec has a significant gap or is wrong, it stops and surfaces the issue rather than silently diverging.

Review

The developer top-hats the implementation. When they find issues, the agent classifies each correction and routes it to the right artifact layer before changing code:

The critical discipline: every correction that touches behavior updates the spec before updating the code. The spec is the source of truth. If the spec drifts from reality, future agents reading it will build the wrong thing.

The agent comments review findings on the PM issue, then loops back to build until the developer approves.

Retrospective

Once the implementation is approved, the agent reviews its decision and learning logs and recommends promotions:

• Cross-cutting decisions → ADR (constrains future stories)
• Recurring patterns → Pattern (eliminates classes of divergence)
• Story-specific items → stay in the log

On approval, the agent writes the ADRs and patterns, sets the spec status to completed, updates the PM issue to DONE, and comments a retro summary on the issue.

The Compounding Loop

The system improves itself over time through a promotion cycle:

Planning Track
  Developer shapes product brief,
  creates epics and stories in PM
          │
          ▼
Developer + agent co-author story
  spec (propose → dispose loop)
          │
          ▼
Agent builds, logs decisions +
  learnings (pitfalls, patterns)
  PM: status → DOING, comments
          │
          ▼
Developer top-hats, reviews
  Corrections flow back to right layer
  (spec, ADR, or even product brief)
  PM: comments review findings
          │
          ▼
Agent recommends promotions
  ├── Recurring decisions → ADR
  ├── Recurring patterns → Pattern
  └── Pitfalls/learnings → ADR/Pattern
  PM: status → DONE, retro summary
          │
          ▼
Knowledge corpus grows richer
  Next story has fewer branch
  points to specify

The first story through this process requires the most specification because the knowledge corpus is thin. By the twentieth story, accumulated ADRs and patterns handle most cross-cutting branch points automatically. The developer only specifies what’s genuinely new about this story.

Measuring Effectiveness

Three metrics track whether the process is working.

Decisions logged per story (leading indicator). Count the unspecified decisions from the agent’s decision log for each story. If the system is working, this number decreases over time because more decisions are pre-specified by existing ADRs and patterns, so the agent encounters fewer uncharted branch points. Learnings logged per story should also decrease. Promoted pitfalls and patterns mean the next agent inherits prior knowledge rather than rediscovering it.

Rework rate (lagging indicator). How often does a developer reject or significantly modify the agent’s output during top-hat? Track per story (count the revised entries in spec changelogs). If the system is working, rework decreases because the agent’s implementation is more tightly constrained toward the desired outcome.

Time to acceptable output (efficiency indicator). Total elapsed time from “developer starts specifying” to “implementation is accepted.” This should decrease as the knowledge corpus grows and the agent needs less per-story specification to produce correct results.

The compounding effect is the real payoff. Each correction that updates a spec or creates an ADR prevents the same mistake from recurring. Each promoted pattern eliminates a class of stylistic divergence. The corpus gets richer, the per-story effort gets lighter, and the output quality improves. It is a self-reinforcing loop.