Kaname Theory
Kaname is not a process. It is a set of beliefs about how software should be built when AI is doing the building. These three convictions are non-negotiable - they are the foundation everything else rests on.
The specification is the source of truth. Code is a derived, regenerable output. Specifications endure; implementations are replaced. When specification and code conflict, the specification governs.
Why this conviction
AI can generate code faster than any team can write it. The bottleneck is no longer writing code - it is knowing what to build. A specification that is precise, complete, and owned is the only thing that prevents AI-generated code from drifting away from intent.
In practice
Without this conviction
Teams skip the spec and ask AI to "figure it out." The AI produces something plausible. The team ships it. Three weeks later, the product does something no stakeholder wanted - but nobody can point to where the decision was made, because there was no specification to violate.
Work moves continuously through defined stages governed by explicit policies - stated rules about how work enters, advances, and exits each stage. Time-boxed iterations are not required. Work is pulled, not pushed. Limiting work in progress improves delivery more reliably than increasing effort.
Why this conviction
Sprints impose artificial rhythm. In AI-augmented delivery, a single spec can generate a full task list in minutes and implementation can follow in hours. Sprint boundaries become obstacles rather than checkpoints. Flow exposes real bottlenecks - a blocked gate, an overloaded reviewer, an ambiguous spec - rather than hiding them behind a two-week cadence.
In practice
Without this conviction
A team running Kaname-flavored sprints commits to 12 tasks on Monday. By Wednesday, 8 are "in progress" simultaneously. The AI is fast; reviewers are drowning. Nothing ships by Friday. The sprint ends, tasks roll over, and the team calls it normal.
Artificial intelligence generates code at speed and scale. Human judgment governs intent, architecture, and acceptance. No AI output advances through the delivery system without passing a human gate.
Why this conviction
AI is a powerful but undiscriminating executor. It optimizes for completing the task as stated, not for the consequences of completing it. Architectural decisions made by AI without human review accumulate into systems that are expensive to change and dangerous to operate. Human gates are not bureaucratic overhead - they are the mechanism by which intent is preserved across generations of AI-generated code.
In practice
Without this conviction
A Task Implementer runs an AI agent on a batch of 20 tasks overnight. In the morning, all tasks are marked done. The code compiles. The tests pass. Nobody reads the diffs. The system now has a new data model, three new API endpoints, and a caching layer that nobody specified - all "working" and all wrong.
The full guide covers all five roles, the delivery cycle, and human gates.