I built a tool that builds tools. That sentence sounds like a riddle, but it is the most accurate description I have of what Forge is and why it exists.
Forge is an AI-powered development system that takes an application from idea to shipping product. Not a code generator. Not an autocomplete engine. A structured methodology that covers the entire software development lifecycle, with AI embedded at every stage.
I want to explain what it actually does, because the concept tends to get lost behind the buzzwords.
Why It Exists
About a year ago, I started building a cross-platform trip planning application. Offline-first sync engines, dual SQLite and Postgres schemas, real-time collaboration, iOS and Android deployment through Capacitor. Seventeen database tables, over three hundred commits, and a complexity level that made it clear I needed more than an AI assistant sitting in a terminal.
The problem was not that AI tools could not help. They could. The problem was that every session started from scratch. I would open Claude Code, re-explain the architecture, re-establish the conventions, and hope the context window held long enough to do meaningful work. The AI had no memory of what we decided last week. It did not know why we chose one schema design over another. It could not hold the full picture of a complex application in its head.
I needed a system, not a conversation partner. So I built one.
The Three Parts
Forge is three tools that work together.
Forge: Plan
Planning is where most AI-assisted projects fall apart. It is tempting to jump straight to code generation. As many have discovered, this usually ends up with an application that works in isolation but collapses under real-world requirements. Forge Plan is a structured planning workbench that forces the hard questions before a single line of code gets written.
It runs guided interviews that cover what an entire engineering organization would do. Product requirements. User experience flows. System architecture. Data modeling. Security considerations. Not "what features do you want?" but "what happens when the user is offline and edits a record that was modified on another device?" It surfaces tradeoffs and documents the reasoning behind every choice, not just the choices themselves.
The output is not a specification document that gets ignored. It is a living project context that carries forward into everything that follows.
Forge: Build
This is where the project comes to life. Forge Build takes the planning output and creates a fully configured development environment. Not a boilerplate template. A project that already knows its own architecture.
The exported environment includes the technology stack, configured and wired together. It includes the architectural decisions from planning, encoded as conventions the AI will follow. It includes context files that teach any developer, human or AI, how the project is structured and why.
It also includes a Forge plugin that hands the developer a set of workflow tools inside the project. Commands like /next to surface what to work on, /ship to run through the release checklist, and /retro to capture what went well and what did not. It then suggests repairs to the development system itself. The development process is not something you have to remember. It is built into the environment and is designed to be run with an operator calling the shots every step of the way.
This is the part worth pausing on. The exported project is not a starting point that you immediately start modifying. It is an environment where the AI already understands the codebase because the codebase was designed to be understood. Every convention, every architectural boundary, every "here is how we handle X in this project" is explicit and accessible.
This is the key to a well-structured and maintainable end product.
Forge: Flow
The planning phase is complex. It involves multiple interview rounds, document generation, architectural review, gap analysis, and phase transitions that can span many sessions. That is a lot of process for an AI to hold in its head while also doing the actual thinking work.
Flow is a deterministic state machine that takes over the process management so the AI does not have to. It externalizes the workflow into a state graph: every phase, every transition, every decision point lives in a file, not in the context window. The AI stays focused on the work. Flow handles what comes next.
Some transitions are predictable. After all interviews are complete, the next step is always document synthesis. Those fire automatically. Other transitions require judgment: "Are there gaps in this requirements document?" "Has this phase covered enough ground?" Those get routed to the AI with clear criteria.
The result is that the planning phase can be long and complex without losing coherence. The process survives session breaks, context resets, and the kind of interruptions that are inevitable in real development work. Nothing falls through the cracks because the state of the workflow is not stored in anyone's memory. It is persisted to the file system.
The Meta-Loop
Here is the part I did not expect when I started building Forge.
Forge is how I build everything else. It planned and scaffolded my music composition engine. It is managing the development of a novel authoring studio. It built the task management Claude plugin I use every day. When I needed a memory system for Cairn, my persistent AI collaborator, Forge ran the planning interviews, identified a three-phase architecture, and produced the design brief I built from.
Each project I build with Forge teaches me something about how the methodology should evolve. Interview questions get refined. Export conventions get tighter. The state machine gets smarter about when to ask for judgment and when to just move forward. The improvements compound in every project that follows.
See It
I have a detailed showcase of how Forge works that walks through the architecture visually. If anything here made you curious, that is the place to dig deeper.
Forge is not a product I am selling. It is the system I use every day to build real applications with AI. The reason I am writing about it is that the principles behind it — structured planning, exported contexts, deterministic orchestration — apply to anyone building complex software with AI tools. The implementation is specific to how I work. The ideas are not.
