The deep dive · chapter 5 · 7 steps

What it cost, and what it really cost

How AIDLC works out what a piece of work spent, why the first number is usually too low, and why missing data is reported as missing rather than as zero.

1. 1. The problem — a bill with no line items

   At the end of the month you know what you spent on AI assistance in total. You have no idea which feature it went on.

   That's not a curiosity. It's the number you need to decide what to build next, and without it every estimate is a guess dressed up. Worse, the features that felt cheap are the ones most likely to have been expensive, because the expensive part usually happens after they ship.

2. 2. Claim first, then it can be counted

   Where the money went

   aidlc — zsh

   $ aidlc claim price-alerts
   
   claimed price-alerts as session-4f2a (agent)

   why claim first

   A claim is a note saying
   "this session is working on
   price-alerts, starting now".
   
   It is also the only reason the
   tool can tell whose spending
   belongs to which work.

   ← backstep 1 of 3next →

   The claim in the first frame is doing more than you'd think. It's another word to be careful with — nothing to do with support tickets or expenses. It's a note saying this session is working on this piece of work, starting now, and it's what makes spending attributable at all. Usage records carry a timestamp; the claim says whose timestamps those were.

   Which produces the one rule worth remembering from this chapter: spending during an unclaimed session cannot be attributed to anything. It isn't lost — it goes into an unattributed pile you can reconcile later with aidlc cost sync — but it doesn't appear against the work until you do.

3. 3. Read the last column

   Every line of a cost report says how solid its own number is:

   • metered — measured from real usage records. Trust it.
   • estimated — derived from figures the platform reported but didn't itemise. Roughly right.
   • unknown — a period of time is recorded with no usage attached to it.
   • no data — nothing at all.

   The reason to expose this rather than smooth it over: averaging a measured number with a guess produces a number with a guess's accuracy and a measurement's authority. That's the worst possible artefact. Here the report says which is which and lets you decide.

   unknown deserves particular attention, because it does not mean zero. It means a stretch of work happened that nobody measured. Reading it as zero makes the cheapest-looking features the least-measured ones.

4. 4. The number that's a third too low

   Now the part that matters. Ask for the roll-up:

   aidlc metrics
   

   Two numbers appear against each piece of work:

   • cost — what that work itself spent.
   • true cost — that, plus what the bugs it caused spent.

   They can differ enormously. On this project, cost tracking itself spent $153.65. It went on to cause four bug fixes, and its true cost came out at $357.71. Its own cost understated it by well over half.

   That gap isn't an accounting curiosity. It hid a bad decision for two weeks. Cost tracking looked like a moderately priced feature and was in fact one of the most expensive things here, and the reason nobody noticed is that the cheap-looking number was the one on the report.

   The mechanism is deliberately simple. When you fix a bug, you record which piece of work introduced it. That link is never written without somebody confirming it, because a guessed attribution is worse than none. Then the roll-up follows the links one level deep — a bug caused by a bug caused by a feature is not charged onwards, because at two levels the chains get long and the attribution gets dishonest.

   That same linkage gives you a change failure rate per workflow: of the pieces of work completed under each template, what proportion caused a fix. On this project, full-feature runs at 45% and micro-task at 0%, which tells you something useful and slightly uncomfortable about which work actually breaks.

5. 5. What these numbers can't tell you

   Three limits, stated plainly, because a metric you over-trust is worse than one you ignore.

   It cannot tell you whether the work was worth doing. It's a cost, not a return.

   It cannot see one level further. True cost goes one hop. Real causation doesn't stop there.

   It cannot account for a session that wasn't claimed. Two sessions working in one folder at once is the worst case: with overlapping claims, records can't be assigned to either, and on this project two concurrent sessions once lost all their cost data for exactly that reason.

6. 6. Checkpoint

   checkpoint

   A feature spent $153 to build. Three weeks later it has caused four bug fixes, costing $204 between them. What did the feature cost?

   • $153 — the fixes are their own work.
   • About $358 — the build plus the fixes it caused.
   • Not knowable — the fixes had other causes too.

   This checkpoint needs JavaScript.

7. 7. What you can do now

   You can find out what a feature cost, tell how solid that figure is, and get the honest version that includes the bugs it caused. And you know that unknown on a cost report is a gap in measurement, not a free feature.

   Next: the idea list — how to stop good suggestions evaporating, and the design decision that stops it rotting.