Ticket Discipline: Why Fast AI Builders Need a Kanban

Here is the paradox that catches every serious AI builder: the faster you build, the more you need a system to track what you built.

Speed is not the bottleneck. Continuity is. You finish a feature in 40 minutes instead of four hours, pivot to the next task, and three weeks later you are not certain whether you actually shipped that feature or whether it is sitting on a branch somewhere half-done. The velocity that AI enables becomes a liability without a structure to absorb it.

The kanban is not a productivity system. In an AI OS, it is the shared memory between you and your agents.

The Velocity Trap

Synchronous engineering has a natural pacing mechanism: the work is slow enough that your memory keeps up with it. You spend three days building a feature, you remember every decision you made. You spend three weeks on a sprint, the standup keeps the team synchronized.

AI-assisted development breaks that pacing. A feature that took three days now takes three hours. A sprint's worth of work ships in a day. The mental overhead of tracking what exists, what is half-done, and what has not been started yet quickly exceeds the capacity of unaided memory — and the context window of any individual AI session.

The session restart problem is where this becomes operational: every new Claude Code session begins with zero project state. Unless it is given context. A ticket is that context. The agent opens the session, claims the next In Progress ticket, reads the description and acceptance criteria, and proceeds. No "where was I?" No archaeology. The kanban bridges the sessions.

The Ticket Discipline Protocol

Every piece of work gets a ticket before work starts. The sequence is non-negotiable:

1. Create the ticket — title, description, acceptance criteria, relevant context
2. Claim it — move it to In Progress before the first line of code
3. Work it — the ticket is the contract. Acceptance criteria define "done."
4. Close it — move to Done only when the criteria are met and the work is deployed

The claim-before-work rule exists not as ceremony but as a decision record. When you claim a ticket, you are creating a timestamped artifact that says: at this moment, this work was chosen over all other work, and here is the context that justifies it. Three months from now, when you are trying to understand why a particular architectural decision was made, the ticket is the answer.

Our Setup

The Invictus Labs kanban lives in Asana: project "Invictus Labs — Command Station" (GID: 1213322822908077).

Three sections do all the work:

• Backlog — everything that has been defined but not started
• In Progress — active work, claimed, being executed
• Done — completed, deployed, closed

The kanban sync script at ~/Documents/Dev/kanban/sync/asana_sync.py keeps the local state current. The section GIDs for automated moves: In Progress 1213322824700795, Done 1213322823508592.

Claude Code can be told at session start: "claim the next Invictus Labs ticket before starting." Now the agent has a structured scope, acceptance criteria to work toward, and a record to update when done. The kanban is not extra overhead — it is the mechanism that turns a capable model into a directed agent.

What Belongs in a Ticket

Not a wall of text. Enough for an agent to start without asking questions:

• Title: specific enough to distinguish from similar work
• Description: what problem is being solved and why it matters now
• Acceptance criteria: the exact conditions that define "done" — testable, unambiguous
• Context links: relevant files, PR numbers, prior decisions

The acceptance criteria are the most critical field. "Build a cron job that runs daily" is not acceptance criteria. "Cron runs at 7 AM ET daily, posts to #logs channel on Discord, retries once on failure, and has a launchd plist at the expected path" — that is acceptance criteria. The difference is whether the AI agent can self-verify completion or requires human judgment at every step.

The Backlog-Burner Pattern

When there is no urgent work, the backlog drives the session. The backlog-burner skill picks the highest-priority ticket and works it. No prompting required. No context-switching required from Knox. The kanban is the autonomous work queue.

This is the compound effect of the kanban: it is not just a tracker. It is the instruction set for autonomous operation. A well-maintained backlog means an AI agent can pick up work at any time without human direction. A neglected backlog means every session starts with a planning conversation instead of execution.

The Anti-Pattern

The most common failure: starting work on an impulse without a ticket, finishing, and closing nothing. Three weeks later you do not know if that feature shipped, where the code lives, or what tradeoffs were made.

Multiply this across twenty AI-assisted sessions per week and you have a codebase that functions but cannot be maintained — because no one, human or agent, has the map. The kanban is the map.

Plans are worthless, but planning is everything. The plan that gets you into action provides the structure to adapt. Without the structure, you have only chaos dressed as speed.

— General Dwight D. Eisenhower · Public Address, 1957

Drill

Open your backlog right now. If it is empty, spend 15 minutes writing the next five tickets for work you know needs to happen. If it has more than 20 unorganized items without acceptance criteria, spend 15 minutes triaging — move the top five to properly specified tickets, archive the rest. Your next AI session should start with a single instruction: "claim the next ticket." If the backlog cannot support that instruction, the backlog needs work before anything else does.

Bottom Line: AI velocity without kanban discipline creates invisible debt. You gain speed but lose continuity — and continuity is what allows both you and your AI agents to operate without constant re-orientation. One ticket per unit of work. Claim before starting. Acceptance criteria that an agent can self-verify. The backlog as the autonomous work queue. This is the system that lets you move fast without losing track of where you are.