Where development time goes with Claude Code

1. Summarymeasured

Time attributed to development work over the measured period:

2. How time splits across activitiesmeasured

This is the central question: how much goes into building the feature, and how much into everything else. Each hour is attributed to the activity in progress at that moment, reconstructed from the chronological record of every session.

3. Evidence: where each hour came frommeasured

No hour in this report is extrapolated from a sample. Each is a sum of intervals between recorded events. The table below decomposes every category into number of operations × average duration, so any line can be checked independently.

4. Active tool work vs. human interaction timemeasured

Time falls into two distinct regimes. During active work Claude Code is executing and the developer follows along. During interaction time the tool is idle, waiting on a human — this is where reviewing the result and manual testing live.

5. The effect of project maturitymeasured

The hypothesis that mature projects spend proportionally more effort on tests holds, and holds strongly. Each dot is a project; dot size is total hours in it. The line is the hours-weighted fit.

6. With and without Claude Codeassumption

This is where the analysis stops being measurement. How long the same work would have taken without the tool does not exist in the data — it can only be modelled. So two independent models are presented, with visible and adjustable assumptions. They answer different questions and land on very different numbers; the distance between them is itself informative.

7. Estimator for a new projectassumption

The measured coefficients put to practical use: describe a project's size and profile and the page projects hours per activity, using the rates and maturity adjustments observed across the projects in the fitted sample.

8. Projects in the samplemeasured

Own projects with at least one hour of attributed time.

9. Methodology, audit and limitations

9.1 Time reconciliationmeasured

Raw session duration is far larger than attributed time, because long gaps are not work. Nothing is discarded silently — the arithmetic closes:

9.2 How time is attributed

• Each session is rebuilt as a chronological event stream: developer instructions, tool actions, and their results. The interval between two consecutive events is attributed to the activity in progress during that interval.
• An action is classified by what it does: editing a test file is test authoring; running pytest, node --test or mvn test is test execution; editing .md is documentation, and so on. The complete rules live in classify.py.
• Per-event caps. A work interval counts for at most minutes; test runs and builds, which legitimately block for longer, count up to minutes. Pauses waiting on a human count up to minutes. Gaps beyond minutes are treated as a break and discarded entirely.
• The caps are conservative by design: they reduce the measured total. The effect is to understate time, never to inflate it.

9.3 How delivered lines are counted

• The official count is an end-to-end diff: from the last commit before the first session to the current state. This is reproducible in two commands and cannot double-count a file that was revised many times.
• Summing per-commit additions gives a larger number — the churn. In this sample it is × net delivery, meaning rework exists but is moderate.
• Lockfiles, build output, minified bundles and generated directories are excluded, as are bot commits (dependabot, copilot).

9.4 Limitations — what these numbers do not prove

• Section 6 is a model, not a measurement. No observed data says how long the same work would have taken by hand. The two models bracket a range; neither is a fact.
• Lines of code are a weak proxy for value. They measure volume, not difficulty. A 40-line algorithm can cost more than 4,000 lines of repetitive scaffolding. Model A exists precisely so the comparison does not have to rely on this measure.
• Scope is not constant. Some of what was delivered would likely never have been written by hand — exhaustive tests and extensive documentation become worth writing once producing them gets cheap. This inflates Model B and is the main reason the two models diverge.
• A reliable before/after comparison was not possible. It was attempted and the output is kept in before_after.json, but the data does not support a conclusion:
• Git cannot distinguish assisted from manual commits in this environment, by process choice — recorded authorship is always the developer's. So the two populations cannot be separated by metadata, and using the co-authorship trailer would produce false negatives across most of the history.
• One developer, one set of projects. Nothing here generalises to other people or other codebases without fresh measurement.
• Interaction time includes waiting and reading, which would exist without the tool as well. That is why it is accounted separately from active work.

9.5 Instrumentation for measuring from here on

What retrospective analysis cannot see is manual testing and review time spent outside a session. That is directly measurable with hooks installed in the projects, which record the timestamp of each work cycle. The repository ships the hooks and installation instructions; once installed, future editions of this report will have manual test time measured rather than estimated as a floor.