Decision Graph Development: How AI Teams Can Build Software Without Forgetting
How decision graphs give AI development the memory it desperately needs
Every time you ask an AI to modify code it generated, you’re playing a dangerous game. The model that wrote your authentication system doesn’t remember why it chose JWT over sessions. Change one thing, and the ripple effects cascade through logic that exists only in weights — not in any document you can read or modify.
This is catastrophic forgetting applied to software development. And there’s a way out.
The Problem with One-Shot AI Development
Current AI coding tools work like this: describe what you want, receive code. Need changes? Describe them again, hope the AI understands the context, receive new code. Repeat until something works.
This approach has a fundamental flaw. Every decision the AI made — why this architecture, why this pattern, why this tradeoff — lives nowhere except the model’s latent space during that specific conversation. The reasoning evaporates the moment the context window closes.
When you return to make changes, you’re not modifying a system with preserved intentions. You’re asking a fresh model to reverse-engineer decisions from code alone. Sometimes it works. Often, the AI “improves” things that were deliberately designed that way, or breaks subtle invariants it never knew existed.
Traditional development teams don’t work like this. They write design documents. They have architecture reviews. They make decisions in meetings and record why. The reasoning persists even when team members leave.
Decision Graphs: Freezing the Reasoning
A decision graph captures not just what was built, but why. Each node represents a deliberate choice — architecture, technology selection, handling of edge cases — along with the alternatives considered and the reasoning that led to the final decision.
The structure is simple:
User Story → Roundtable Deliberation → Decision Document → Implementation
The roundtable isn’t a single AI generating code. It’s multiple models (or multiple instantiations with different prompts) examining the problem from different angles. One might focus on security implications. Another on performance. A third on maintainability. They surface concerns a single model might miss — edge cases, potential conflicts, assumptions that need validation.
The output isn’t code. It’s a decision document that answers: What are we building? Why this approach over alternatives? What constraints are we accepting? What edge cases have we considered?
Only after this document exists — and after human approval — does implementation begin.
Why This Changes Everything
Consider what happens when you need to modify the system later.
With traditional AI development: “Change the authentication to support OAuth.” The AI sees your JWT code, has no context for why JWT was chosen, and may introduce changes that conflict with decisions you’ve forgotten you made.
With decision graph development: The AI (or you) can reference Decision Document #7, which states that JWT was chosen because the system needed to work offline, that session storage was rejected due to horizontal scaling requirements, and that the token refresh strategy assumes specific network conditions. Now the OAuth modification can be made surgically — preserving the decisions that still apply, explicitly reconsidering those that conflict.
The decision graph is versioned, searchable, and frozen. Unlike neural network weights, it doesn’t drift. Unlike conversation history, it doesn’t get truncated. Unlike your memory, it doesn’t fade.
The Autonomous Host Vision
The real power emerges when you extend this pattern.
Imagine providing a set of user stories and stepping away. An autonomous host orchestrates the entire development process:
- For each story, the host convenes a roundtable
- Multiple AI perspectives deliberate — How should this be implemented? What could go wrong? What are we missing?
- Consensus emerges and gets documented
- Implementation follows the documented decision
- The cycle repeats for the next story
When you return, you don’t just receive working software. You receive a complete intellectual history: every decision, every alternative considered, every tradeoff made. If something seems wrong, you can trace back through the decision graph to find exactly where the reasoning diverged from your intent.
This isn’t automation that hides complexity. It’s automation that exposes reasoning in a format you can audit, modify, and build upon.
Parallels to Human Teams
This pattern isn’t novel — it’s how effective human teams already work, formalized for AI collaboration.
Architecture Decision Records (ADRs) capture the “why” behind technical choices. Design documents survive employee turnover. Code review ensures multiple perspectives examine each change.
The difference is that human teams do this naturally, through culture and process. AI systems need the structure made explicit. They need the decision graph as an artifact, not an assumption.
What’s new is the potential for scale. A human architecture review might take a week. An AI roundtable can happen in seconds. The bottleneck shifts from deliberation time to human approval bandwidth.
Making Surgical Changes
The decision graph enables something powerful: targeted modification without cascade failure.
Get Alexander Zanfir’s stories in your inbox
Join Medium for free to get updates from this writer.
Every implementation connects to specific decision nodes. Want to change how errors are handled? Find the decision document that established the error handling strategy, understand its constraints, and either:
- Modify the implementation while respecting the documented constraints
- Explicitly update the decision document, triggering reconsideration of dependent decisions
This is version control for reasoning. Just as git tracks changes to code, the decision graph tracks changes to why the code exists.
When you update a decision, you can trace its dependencies. “If we change the authentication approach, what other decisions assumed the current approach?” The graph tells you. No guessing. No hoping you remember all the implications.
The Implementation Path
I’ve built this system and have been using it for months. The difference is stark. If you want to build your own, the components are straightforward:
Roundtable orchestration: Multiple model calls with different system prompts, aggregated into deliberation transcripts.
Decision document structure: A standardized format capturing the problem, alternatives, chosen approach, and rationale. Markdown works. JSON works better for programmatic access.
Graph storage: Decisions link to parent decisions (what they depend on) and child decisions (what depends on them). Any graph database handles this. Even a folder of linked markdown files works.
Implementation binding: Code comments or metadata linking specific functions and modules to the decisions that created them.
The pattern doesn’t require exotic technology. It requires discipline — treating AI-generated code as the output of a process that deserves the same documentation rigor as human-created systems.
Or you can skip the build and use what I’ve already made — I’ll link to the repository at the end of this article once it’s public.
What We Gain
The decision graph approach offers several concrete benefits:
Preserved context: Reasoning survives between sessions, between model versions, between team changes.
Auditable development: Every choice can be traced to its justification. Useful for reviews, debugging, and regulatory compliance.
Surgical modification: Changes target specific decisions rather than hoping the AI figures out what should stay the same.
Compound reliability: Each validated decision becomes foundation for future decisions, rather than each change risking the entire system.
Human oversight without human bottleneck: You approve decisions, not implementations. The reasoning is legible even when the code isn’t.
The Tradeoff
One-shot generation isn’t bad — it’s essential. When you’re exploring a vision, rapidly prototyping, figuring out what you even want to build, one-shot is exactly right. You describe, you receive, you learn. The artifact that emerges becomes the seed for understanding what you actually need.
But one-shot development doesn’t scale as a product lifecycle strategy. The AI is stateless. Every session starts fresh. Every modification requires reconstructing context that could have been preserved.
Decision graph development introduces state where AI development has none. The graph persists between sessions, between models, between team changes. It’s the missing memory layer.
Yes, it’s slower. Every feature requires deliberation before implementation. But this is the same tradeoff as testing suites — slower in the moment, foundation for scale. Teams that skip tests move fast until they don’t. Teams that skip decision documentation face the same reckoning.
The two approaches complement each other: use one-shot to explore and discover, then freeze that understanding into decision documents when you’re ready to build something that lasts.
The Shift in Developer Role
This changes what it means to work with AI on code.
Instead of prompt engineering — finding the magic words to make the AI generate what you want — you become a decision approver. You read deliberation summaries. You validate reasoning. You authorize implementation.
The AI’s job shifts too. It’s not a code generator you hope produces the right output. It’s a thinking partner whose reasoning is visible and persistent.
This is closer to managing a junior team than using a tool. You don’t write the code, but you own the decisions. The quality of the system depends on the quality of your oversight.
Moving Forward
The next time you use AI to write code, ask: Where does the reasoning go?
If it disappears when the conversation ends, you’re building on sand. Every future change will require reconstructing context that could have been preserved.
The decision graph isn’t about adding bureaucracy to AI development. It’s about treating AI-generated systems with the same seriousness we treat human-generated ones. Design documents exist because they matter. Architecture decisions get recorded because future developers need them.
AI systems that build software need the same discipline — not despite being AI, but because of it. Their reasoning is even more ephemeral than human memory. Their context windows are even shorter than human attention spans.
Freeze the decisions. Version the reasoning. Build systems that remember why they exist.
The code is just the artifact. The decision graph is the understanding.
This article represents the original ideas and writing of Alexander Zanfir, edited and refined through an agentic editorial process.
