FORGE: What Happens When You Spec Before You Build

PAIRED solved the multi-agent execution problem. Then I noticed what it didn't solve.

Writing the spec was still me, sitting down, doing the decomposition in my head. What needed to happen first. What could run in parallel. What would block what. That thinking was invisible and inconsistent. Different every time I sat down with a new feature.

In December 2025, four months after PAIRED's first commit, I built FORGE.

FORGE takes a natural language specification and breaks it into discrete tasks with explicit dependencies. It maps which tasks block which, identifies the clusters that can run in parallel, and hands the structured plan to multiple agents before a single line of code gets written. The repo is at github.com/SEMalytics/forge.

The core shift isn't that AI writes the spec. It's that decomposition becomes explicit before execution starts.

When decomposition stays in your head, it's implicit. You carry the dependency graph mentally and route work ad hoc. That works until the project is complex enough that implicit routing creates collisions: agents working on things that depend on something that isn't finished yet. Then you're debugging coordination failures, not building.

FORGE makes the dependency graph visible. The spec becomes a structured artifact before any agent touches code. You can see what's truly parallel and what's sequential. The order of operations moves from memory to something you can read.

Building PAIRED taught me that separating roles creates natural review loops. FORGE is the upstream step: before the roles have anything to do, the work itself needs a shape.

Most of those four months was just acknowledging that the spec problem was real, not an edge case. Once I accepted that, the build took about three weeks.

What does your decomposition look like before you hand work to an agent?