Ask a team what they shipped last week and watch where the answer comes from. Almost never the tracker. Someone scrolls the merged pull requests, someone else remembers a hotfix, and a few things surface that never had a ticket at all. Everyone in the room knows the board is behind. Nobody says it, because keeping it current is a chore, and chores lose to real work every single day.
A board that is mostly right gets ignored
In most teams the tracker does not describe what is actually happening. Planning runs on estimates that miss part of the work, managers interrupt engineers to find out what is going on, and when production breaks nobody can trace the change that caused it. The cost is invisible because it arrives as a thousand small questions instead of one big failure. So people go back to asking each other, and the tracker quietly becomes decoration.
There is an old rule meant to prevent exactly this: no ticket, no code. Not one line of production code until a ticket exists for it, with an estimate, an assignee and a place in the current cycle. The ticket first. Not after the code, not backfilled on Friday afternoon.
The rule almost never survives contact with a real team. At one of our clients it now holds without anyone thinking about it: seven production releases over a recent five-day stretch, and the tracker stayed accurate through every one of them, with nobody updating a ticket by hand. What changed is that the AI agents that write the code also do the ticket clerking, a script enforces the gate instead of a team agreement, and every ticket ends up carrying two numbers: the estimate the team gave it, and the tokens the agents actually spent on it.
Why a team would want a rule this strict
Everything else in a team hangs off the ticket: the plan, the estimate, the review, the release note, the answer when something breaks.
When every piece of work starts as a ticket, the tracker describes reality, and that changes how the team runs day to day:
- Nobody has to ask. What is in flight, who has it, and how far along it is are on the board, so managers stop interrupting engineers for status.
- Standups shrink. The status recitation disappears because it is already visible; what remains is blockers, which is the part worth a meeting.
- Velocity becomes plannable. Estimates cover all the work rather than the fraction someone remembered to file, so the cycle number is one you can plan against instead of one you apologise for.
- Agent spend gets an owner. A ticket is the only place a token bill can be attributed to a specific piece of work, which is the difference between knowing what the month cost and knowing what a feature cost.
- Every change is traceable. Which ticket, why it existed, who asked for it, which release shipped it. When production breaks, that trace is the difference between a five-minute answer and an archaeology project.
The inverse is what most teams live with: a tracker that covers most of the work but not all of it. Most is not enough.
Why the rule usually dies anyway
Because it runs on people. Everyone agrees to the rule. Then people forget, deadlines win, and the ticket gets written after the code or not at all. We ran the rule for years on a large production platform and watched exactly that happen, cycle after cycle. It never failed because anyone opposed it. It failed because it ran on memory, and a rule that depends on people remembering it is not a rule; it is a preference.
AI coding agents then made it worse before they made it fixable. Agents removed the friction that used to protect the process: when starting a piece of work meant opening the editor, scaffolding files and wiring the boring parts, there were ten minutes of thinking time in which the ticket got created. An agent starts in ten seconds. An idea arrives in conversation, a branch appears, and forty minutes later there is working code with no ticket, no estimate and no trace in the sprint. Do that a few times a week and velocity becomes fiction.
On the engagements we have looked at, this is the most common failure mode of agent adoption: not bad code, but an untracked stream of it.
So the fix is not more discipline. Discipline was never enough even when friction helped it along. The fix is to take the clerking away from the humans entirely and have a script enforce the gate.
The six rules
Rule 1: a script enforces the ticket gate
Every piece of work needs a ticket, estimated, in the current cycle and assigned, before any branch is created. The rule lives in the agent instruction files, and a pre-edit hook backs it up: any attempt to edit code on a branch without a ticket id in its name is blocked. Documentation paths are exempt, so writing notes never requires a ticket.
The instruction files also carry a line aimed at the human, not the model: if the user asks the agent to start coding without a ticket, the agent is to stop and flag it. Agent-speed starts were leaving work uncounted, so the guardrail points at the person with the ideas.
Production emergencies invert the order but not the rule. Fix first, but the ticket exists before the pull request opens, created retroactively at the highest priority the same day. Bypassing the hook requires deliberately relaunching the session with an override flag, which makes skipping the process a decision rather than a habit.
Rule 2: the agent searches before it creates
Duplicates are the default failure mode of automated ticket creation. The same idea usually already sits in Triage or Backlog from a customer report or an earlier conversation. So before filing anything, the agent runs at least three searches: the core nouns of the request, an alternate phrasing, and a full read of Triage plus a filtered pass over Backlog.
An open item with the same behaviour is reused, not twinned. A Triage item is promoted. A closed ticket describing the same behaviour turns the request into a regression ticket linked to the original. Only when nothing matches does a new ticket get created.
Rule 3: every field is filled, and the agent decides
A ticket the agent creates arrives complete: team, current cycle, assignee, state, project, labels, priority and an estimate on a fixed 1, 2, 3, 5 scale. Anything larger than a 5 is not one ticket and gets split into independently shippable children. The estimate rubric is written down with named examples, so a 3 means the same thing in week forty as it did in week one.
The agent asks a question only when picking wrong would throw away real work. Everything else is the agent's call, reported back in a single line. A mis-sized estimate costs nothing; a round of clarifying questions before every task costs the whole point of the workflow.
Rule 4: status moves with the code
The branch name carries the ticket id, which links the pull request to the ticket automatically. The ticket moves to In Progress when the agent starts editing, to In Review when the pull request opens, and to Done when it merges. No stand-up ritual of dragging cards; the board state is derived from the repository state.
A hand-updated board tells you what people remembered to record; a derived board tells you what actually happened.
Rule 5: releases label themselves backwards
When a deploy succeeds, a script in the pipeline labels every ticket shipped in the deployed range with the version, and comments on each one with the environment and date. The range starts from whatever version was actually running before the deploy, read from the environment's health endpoint, so a production deploy that skips versions still covers the skipped ones.
The step is best-effort by design: a tracker outage never fails a deploy. But when it runs, non-engineers get the answer to the two questions they actually ask. Filter by the version label to see what is in a release. Open a ticket to see which environments it has reached and when. Nobody has to interrupt an engineer to find out what is running where.
Rule 6: every ticket records what it cost in tokens
Points say how big the team thought the work was. They say nothing about what it consumed. So the same automation that moves status also writes the agent spend back to the ticket: token usage from the sessions that worked on the branch carrying that ticket id, converted to a cost and posted when the pull request merges.
That leaves two numbers on every card. The estimate is the team's guess at size, made before the work started. The token spend is what the agents actually burned getting there. Neither is worth much alone. Together, across a cycle, they answer questions a monthly token bill cannot: which kinds of work are cheap to hand to an agent and which quietly cost several times what their points implied, which tickets fell into the debug loop of ask, run, fail, ask again, and whether a 3 still costs roughly what a 3 cost two months ago.
Two tickets, both estimated as a 3. One was a well-specified API change and came in at a few dollars of tokens. The other was a poorly specified debug loop and cost several times that. The points were the same; the spend was not.
The attribution is approximate. Sessions overlap, some context is shared across tickets, and review conversations are not free. It is accurate enough to compare one class of work against another, and not accurate enough to bill against.
The part we did not expect is what it does to the estimate rubric. When a type of ticket consistently overruns its points in tokens, that is either sizing the work wrong or missing context in the instruction files, and both are cheap to fix once you can see which one it is.
It also changes the finance conversation. What you spent on coding agents last month is a bill. What a merged change costs, by type of work, trending over cycles, is a number a CFO can plan against, and it comes out of the tracker instead of a spreadsheet somebody maintains by hand. We built Atlas for the cross-tool version of that view; the per-ticket number is the part any team can have this week.
What this buys
Everything the rule promises, the team actually gets, because no part of it depends on a person having a good day. The board is not a report anyone writes. It is the control plane, derived from what the repository did. And because the clerking costs the humans nothing, the process survives busy weeks, which is exactly when hand-maintained boards die.
The numbers it produces also survive scrutiny. "What did the team deliver last cycle, and what did it cost us" is a question a CFO or an auditor eventually asks. A board that covers all the work, with estimates attached at creation, token spend attached at merge and releases labelled on deploy, answers both halves without anyone assembling a slide the night before.
When this is not the right fit
A solo prototype or a throwaway spike does not need it; the repository is the record. And a team that adopts the rule without agent tooling gets the cost without the compensation: every task gains a context switch, and people quietly route around the gate within a month. The rule works at this client because the agent does the filing. Adopt the automation and the rule together, or not at all.
Key takeaways
- The tracker was never a discipline problem. It was a friction mismatch: updating tickets costs more than skipping them, so people skip them.
- A hook in the toolchain does what a retrospective action item never did. Blocking an edit on a branch with no ticket id in its name takes the rule out of memory and puts it in the code path.
- Documentation and emergencies need a stated exit. Exempt paths and a deliberate override flag are what stop people routing around the gate permanently.
- Derive status, never type it. Board state should come from the repository, not from a person dragging a card.
- Record the cost next to the estimate. Points are a guess about size; token spend per ticket is the measurement, and the gap between them is where sizing and context problems show up.
- The clerking has to be free. If creating and managing tickets costs human attention, the process will erode within weeks.
The rule was never the hard part
"No ticket, no code" was always a good idea. What was missing for twenty years was a way to follow it that did not depend on busy people remembering a chore. AI agents closed that gap from both ends at once: they created the untracked-work problem by making code cheap to start, and they solved it by making the clerking free. The tracker that comes out the other side is one the team can actually answer questions from, including the cost ones.
The tools here are Linear, GitHub and Claude-based coding agents. Those will change. What should be durable is the shape: a script in front of the code, an agent doing the filing, and both status and spend derived from the repository rather than from memory.
If your team has adopted AI coding agents and your tracker no longer reflects what is actually being built, we run a short diagnostic on development workflows: where work goes untracked, what can be derived automatically, and what your agent spend looks like per merged change. Book a slot.