TDDD
(TODO Driven Development)
A practical operating record of development in a specific era of generative AI.
Contents
Why TDDD
Why TDDD is needed
TDDD (TODO Driven Development) was not born to invent a new development method.
It was born to catch up the development process to changes that have already happened.
The death of implementation
With the rise of generative AI, "writing implementation" is no longer the core of development.
- Code is generated at high speed
- Quality is reasonably consistent
- The cost of rewriting has dropped drastically
As a result, code became a consumable. Code written today exists on the premise that AI will delete and rewrite it tomorrow.
And yet, systems must keep running.
What changed is not "How"
This change is not about "how" we write. The real change is where we stop.
Mechanics step off the plane
Engineers used to be:
- Designers
- Implementers
- Mechanics during incidents
In other words, they were on board even during flight. But as implementation becomes automated, engineers are pushed off the plane.
Decisions are made before takeoff, and after takeoff, the premise is "do not touch".
This is not a choice. It is a structural change.
The problem is not who is flying
Common debates ask:
- Is AI flying?
- Is the human flying?
But that is not the real question.
Where is the control stick?
And where are the pilot's decisions recorded?
Code cannot preserve decisions
Code preserves implementation, but does not preserve decisions.
- Why this specification?
- Why stop at this boundary?
- Why allow this exception?
Those decisions may remain as comments or docs, but the code itself is not the medium of judgment.
In the era of generative AI, entrusting decisions to code is dangerous.
TODO can preserve decisions
TODO is a message of judgment for future implementation.
- Do this up to here
- Do not go beyond this point
- Must satisfy these conditions
- This needs confirmation
TODO remains even if implementation disappears. Even if code is rewritten, the decisions in TODO pass to the next implementation.
What TDDD does
TDDD is simple.
- Concentrate decisions into TODO
- Make implementation only execute TODO
- When problems occur, fix TODO rather than code
That is all.
Why it is a loop
Generative AI does not reach the right answer in one shot. Humans are the same.
TDDD does not aim for one-shot completion.
- Create TODO
- Implement
- Verify
- Update TODO
It is a loop of continuously updating judgment.
Why boundaries matter
Generative AI always goes wild where boundaries are vague.
- What you may do
- What you must not do
- What is out of scope this time
If these are not explicit, AI crosses boundaries in good faith.
In TDDD, boundaries are written as TODO. They are not design docs, but pre-execution judgments.
Why yearly editions
TDDD depends on the current tool stack.
- Conversational generative AI
- Automatic code generation AI
- IDE-integrated AI support
If these become unified, TODO generation and implementation will merge. Then TDDD will change.
It is not a timeless theory. It is an operating method for that year's reality.
What TDDD keeps out
TDDD keeps ideology minimal.
- AI governance
- Design philosophy
- Organization theory
- Responsibility design
These are outside TDDD. They can be placed on Loop A, but TDDD does not enforce them.
Summary
Implementation is no longer the main actor.
What remains is:
- Judgment
- Boundaries
- Expectations
TDDD is the smallest development loop to hand those forward as TODO.
Even if code disappears, development can continue as long as TODO remains.
TDDD Advanced (2026)
What this is
This document shows concrete steps to run TDDD stably in practice. It minimizes design theory and focuses on "how to avoid accidents".
Two premises
Design premise: Re-creation as a default leads to value continuity.
Means premise: Conversational AI and automatic code generation AI still have distinct roles.
TDDD Advanced is built only on these two points.
The overall cycle
- Create TODO with conversational AI
- Let automatic code generation AI execute TODO
- Review and return to TODO
Repeat this loop.
1. Create TODO with conversational AI
This is the most important step.
1-1. Align the specification
- Explain in conversation
- Paste existing documents
- Ambiguity is acceptable
The goal is not "the correct answer" but shared assumptions.
1-2. Define the boundary where AI may act
Always make these explicit:
- What to do this time
- What not to do this time
- The range that must not affect the outside
Example:
- Do not touch external APIs
- Do not change DB schema
- Do not perform file I/O
1-3. Ask for TODO inside the boundary
Ask the conversational AI: "Within this boundary, create implementation TODOs. Explicitly include what not to do."
1-4. Output YAML if needed
- Inputs / outputs
- State
- Configuration
Write only the structure in YAML before code.
Artifacts:
todo/
├─ TODO.md
└─ schema.yaml (if needed)
2. Let automatic code generation AI execute TODO
Here, do not let it decide.
2-1. Large systems are "one boundary, one project"
- Split repositories or folders by boundary
- Keep a size the AI does not get lost in
This is not design ideology but a countermeasure to AI's cognitive limits.
2-2. Make the TODO folder the single source of truth
Instruct the automatic AI: "Implement in xx language using only the contents of the todo folder. Do not implement anything not written in TODO."
2-3. If behavior is odd, make a test into TODO
- Do not fix the code
- Ask: "Create a test to confirm this behavior"
Example:
- [ ] Add a test to confirm no exception is raised when input is None
Procedure:
- Manual check
- Execute
- Confirm differences from expectation
- Fix in the next cycle
3. Review and re-TODO
3-1. Refactor with another automatic AI if possible
- Organize code
- Remove duplication
- Improve readability
Adding tests from a different viewpoint is not very meaningful.
3-2. Review with the conversational AI that created TODO
- Does the implementation satisfy TODO?
- Does it cross boundaries?
- Where is judgment missing?
3-3. Return all feedback to TODO
- Fix TODO before fixing code
- Freeze judgment
- Repeat the cycle
- Create TODO
- Implement
- Verify
- Fix TODO
TDDD does not aim for one-shot completion.
Techniques to connect boundaries (at scale)
A single boundary is small, but you can scale by loose coupling.
Examples:
- Connect boundaries via data structures only
- Prefer JSON / YAML / DTO to function calls
- Avoid direct references (use Adapter / Facade)
- Design boundary communication assuming failure
This allows:
- Discarding one side
- Re-creating components
- Switching AI
Limits
- Life/safety systems
- Physical control
- High legal liability domains
These require different design.
Summary
- Judgment is made by conversational AI
- Implementation is delegated to automatic AI
- Cut by boundaries, connect by loose coupling
- Do not erase TODO
TDDD Advanced is a practical loop premised on continuous re-creation.
Supplement: The 11 boundaries as an invisible map
The most important point in TDDD Advanced is not to mistake where to cut.
VCDesign / VC-AD organize "constraints outside code" as 11 boundaries to help with that judgment.
These are hard to express as code and are where AI is most likely to go wild.
Overview of the 11 boundaries
The 11 boundaries are grouped into four sets by nature.
Group 1: Unchangeable Context
Boundaries you must not try to solve by design
- Physical / field constraints
- Organization / boundary
- Governance
Examples:
- Physical separation
- Different organizations or responsibility owners
- Fixed by law or policy
TDDD handling
- Write as preconditions in TODO
- Do not solve in implementation
- Fix as assumptions for AI
Group 2: Select-only Resources
Boundaries determined by choice, not design
- Execution platform
- Network
- Platform
Examples:
- Cloud / on-prem
- Latency / bandwidth
- Managed / self-hosted
TDDD handling
- Split projects by boundary
- Write the choice as preconditions in TODO
- Do not change during implementation
Group 3: Standards to Protect
Boundaries AI must not break
- Reliability (SRE)
- Security
- Observability
Examples:
- Retry policies
- Access control
- Log / metrics formats
TDDD handling
- Write as constraints in TODO
- Do not let automatic AI decide
- Turn checks into TODO tests if needed
Group 4: VC-AD Core Domain
No correct answer, only decisions
- Essence of distribution
- Data semantics
Examples:
- Consistency vs availability
- Allow duplicate processing or not
- Meaning of money and quantities
TDDD handling
- Always decide with conversational AI + humans
- Record decisions in TODO
- Implementation only executes those decisions
This is the hardest area for AI, and must be handled most carefully.
Practical usage in Advanced
Boundary split check
Before splitting a project / TODO by a boundary, check:
- Which of the 11 boundaries are included
- Whether multiple groups are mixed
- Especially whether Group 4 is mixed in
If mixed, split.
Principles for connecting boundaries (loose coupling)
- Connect boundaries via data structures
- Avoid direct references
- Assume failure
- Keep the ability to discard one side
This makes TDDD applicable to large-scale systems.
Relationship between TDDD and the 11 boundaries
- TDDD is about "how to run"
- The 11 boundaries are the map of "where to cut"
- VCDesign / VC-AD explains "why to cut that way"
Advanced covers driving while looking at the map.
Summary
- AI does not know boundaries
- Humans must teach boundaries
- Decisions are left in TODO
- Implementation stays inside boundaries
With this, TDDD scales beyond small systems to real large systems.