Method and measurements for development with a coding agent

This supports How I run development with a coding agent. The article describes my practice, while the measurements below count calls and sequences in session logs. The proposed team trial has not been run.

What these numbers describe

The historical window starts on 17 March and ends on 29 October. The recent window runs from 14 September to 29 October and contains 111 sessions. Monthly figures count sessions started in that month, and October stops on the 29th.

• The denominator includes every session in the window, including questions that needed no code edit or interface check. The percentages are observed frequencies across those sessions, not compliance rates among eligible changes.
• A specification-stage call can be a read of an existing file. It does not establish that a new proposal was written or reviewed.
• A test or product-check call records an action. It does not establish that the check passed or covered the necessary cases.
• An action may first appear on the day its tool became available. That does not isolate the effect of the instruction to use it.
• Full-chain coverage is measured within a session. Sessions have not been linked by shipped change, so a low session percentage is not a completion rate for changes.
• Tool-response sizes describe different operations and query populations. They do not measure savings on an equivalent task, monetary cost or retrieval quality.

Percentages in the text are rounded to whole numbers, while the charts are drawn from one-decimal percentages and full-character search medians.

How I counted the sessions

Each Claude Code session is recorded in a JSON-lines file containing the conversation and tool calls. I count sessions across both machines and publish aggregates without splitting them by project.

1. Tool calls are deduplicated by their ID so the same call is counted once.
2. Token usage is deduplicated by message and request ID, taking the maximum output when a response is recorded across several lines.
3. Subagent transcripts are included in the session’s work.
4. Tool search, the language-server bootstrap call and housekeeping commands are excluded from the work counts.
5. Commands I typed are counted separately from skills the model invoked on its own.
6. Command-line tools are identified inside shell commands, because some layers have no separate tool interface.
7. A session counts as using a layer if it made at least one call to it.
8. Sessions with no prompt and no counted call are dropped.

Part of April on one machine was restored from a backup and part is missing, so April is undercounted. Work before the first recorded session is outside this dataset.

How calls become stages and sequences

Recognized calls are grouped into the following stages:

1. Search: knowledge-base reads.
2. Inspect: symbol reads, code-graph queries, file reads and text searches.
3. Plan: plan mode and writes to the plan file.
4. Spec: specification tools, their skills and reads or edits of specification files.
5. Edit: code edits.
6. Test: commands that run tests, type checks or lint.
7. Product check: emulator, physical-device and browser tools.
8. Note: end-of-session capture and knowledge-base writes.

Subagent dispatch is also identified in the short-chain counts. Within each session, stages are ordered by time and consecutive repeats are collapsed.

• Before the first edit means a call of that stage exists before the session’s first code edit.
• After means a call exists later than an earlier call of the other stage.
• Ends with a note means the final recognized stage is a note.
• Short chains count adjacent stages after repeats have been collapsed.
• Workflow coverage counts a sequence when its stages appear in that order anywhere in the session, even if other stages occur between them.

Which parts of the workflow changed

The main article plots search before editing and product checks after tests. The monthly measurements also show how planning, specification use and end-of-session notes changed.

Planning already preceded editing. A plan or specification call appeared before the first edit in 36% of March sessions, before the specification tool arrived. The corresponding share was 46% in October. This shows that the stage existed early, while the document used for it changed.

Specification files became part of that stage. A specification-stage call before editing rose from 14% in August to 40% in September and 44% in October. Because a read counts here, this is evidence of specification use rather than a count of reviewed proposals.

Separate end-of-session notes became less frequent. The share fell from 24% in July to 8% in October. Much of what we discussed was already in the knowledge base, and the change documents kept information that previously needed a separate note when I used only plan mode. I had less new material to capture separately. That is my explanation of the change in practice, while the logs measure how often a separate note was written.

Tool use and workflow order are different measurements

Adoption counts any use of a tool during a session. For example, knowledge-base search appears in 80% of recent sessions, while a search before the first edit appears in 60 of those 111 sessions (54%). The second measure adds an ordering requirement.

Monthly adoption also shows how the setup changed. Subagents appeared in 76% of March sessions and 18% of October sessions. Plan mode appeared in 76% of April sessions and 14% of October sessions. These shares describe usage and do not establish that replacement tools were equivalent.

Tools used in the recent 111-session window

Each percentage below counts sessions with at least one use. The date is the tool’s first appearance anywhere in the logs.

• Knowledge-base search: 80%, first seen on 8 June.
• Symbol-level reads and edits: 59%, first seen on 3 June.
• Specification tooling and files: 48%, first seen on 23 August.
• Issue tracker: 38%, first seen on 4 September.
• Code graph: 32%, first seen on 3 September.
• Device checks: 26%, first seen on 2 July.
• Browser checks: 25%, first seen on 4 July.
• Subagents: 22%, first seen on 28 March.
• Plan mode: 21%, first seen on 28 March.

Device and browser checks overlap. In the recent window, 29 sessions had a device check, 28 had a browser check and 16 had both. That leaves 41 sessions with at least one of them, or 37% of the window. Across the full period, the corresponding counts were 59, 53, 29 and 83 sessions.

When each workflow sequence first appeared

The following compares the full historical window with the recent window. Each item uses the same definition in both windows.

• Search before the first edit first appeared on 8 June and occurs in 26% of all sessions and 54% of recent sessions (60 of 111).
• Specification-stage call before the first edit first appeared on 23 August and occurs in 8% of all sessions and 34% of recent sessions.
• Specification or plan before the first edit first appeared on 28 March and occurs in 43% of all sessions and 38% of recent sessions.
• Test after an edit first appeared on 17 March and occurs in 42% of all sessions and 37% of recent sessions.
• Product check after a test first appeared on 4 July and occurs in 8% of all sessions and 30% of recent sessions.
• Session ending with a note first appeared on 11 June and occurs in 9% of all sessions and 9% of recent sessions.
• Full workflow inside one session first appeared on 4 July and occurs in 2% of all sessions and 5% of recent sessions.
• Workflow without the product check and final note first appeared on 8 June and occurs in 11% of all sessions and 27% of recent sessions.

The full workflow is search, inspect, specification or plan, edit, test, product check, then note. The 5% figure counts sessions containing that sequence and says nothing about the percentage of shipped changes with complete verification records.

Search response size around the reranker fix

The configuration error and failed requests establish the incident described in the article. The monthly response sizes give another view of the period. The median fell in September after the fix and rose again in October, while the query mix also changed between months.

Search response size by month

Median characters returned per search, thousands

Data

Month	Median characters per search, thousands	n
Jun 2026	16.1	133
Jul 2026	18.3	310
Aug 2026	18.4	367
Sep 2026	9.4	533
Oct 2026	15.3	228

What a tool call returns to the model

The median is the middle result size. The 90th percentile is the size at or below which 90% of responses fall. All values here are characters, so they should not be read as prices or directly compared with token counts.

• Whole-file read: median 2,100 characters and 90th percentile 10,500.
• Symbol read: median 970 characters and 90th percentile 3,800.
• File overview: median 200 characters and 90th percentile 650.
• Knowledge-base search: median 15,500 characters and 90th percentile 30,700.
• One knowledge-base page: median 5,700 characters and 90th percentile 15,300.
• Subagent report: median 5,500 characters and 90th percentile 19,800.
• Plan returned for approval: median 4,200 characters and 90th percentile 18,200.

These are different operations with different scopes. Their response sizes do not show the cost of answering the same question through each tool.

Context, output and tool calls use different units

Context per request includes input and cache tokens in one API call. Its median is calculated across calls in sessions started that month. Output and tool-call medians are calculated across sessions, so they have a different unit of observation.

The charts show selected months in 2026, with October ending on the 29th. Each chart uses its own scale. Expand Data below a chart to see the values in a table.

Context per request

Median, thousand tokens

Data

Month	Median context, thousand tokens
Mar 2026	41
May 2026	96
Jul 2026	170
Sep 2026	255
Oct 2026	284

Output per session

Median, thousand tokens

Data

Month	Median output, thousand tokens
Mar 2026	14
May 2026	35
Jul 2026	97
Sep 2026	111
Oct 2026	116

Tool calls per session

Median number of calls

Data

Month	Median tool calls
Mar 2026	89
May 2026	68
Jul 2026	99
Sep 2026	120
Oct 2026	127

Output produced inside subagents

Share of output tokens

Data

Month	Share of output tokens
Mar 2026	49.0%
May 2026	10.0%
Jul 2026	24.0%
Sep 2026	18.0%
Oct 2026	2.0%

Requests and session outputs became larger between May and September, but these measurements do not establish the monetary cost of a completed change. Work has not been linked across sessions at that level.

Short sequences inside sessions

In May, the most common three-step chain was a subagent read, an inspection and a plan, in 47% of sessions. In the recent window, the edit-and-inspect loop appeared in 41%, inspect then edit then test in 31%, the product-check loop in 28%, and search then inspect then edit in 23%.

Tools and the choices behind the setup

These paragraphs record when tools entered the setup and what I chose to stop using. They do not establish that a tool caused an improvement.

March. I used Claude Code with plan mode to think before editing and subagents that read code for the main session.

June. Serena added symbol-level code reads and edits through a language server. gbrain, an open-source project I run with a handful of my own patches, made the knowledge base searchable by meaning. That knowledge base replaced the per-repository documentation folders.

July. I added an end-of-session note with a source. Mobile MCP and Playwright MCP let the agent operate an emulator, a physical phone and a browser.

August. OpenSpec supplied versioned change proposals and specifications, and I stopped using plan mode as my design document.

September. I added graphify to help find dependencies, with its additional value still under trial, and Atlassian MCP to bring the issue tracker into the session. I stopped using subagents as the default way to read code and kept them for separate reviews.

If you analyse agent transcripts, I would like to hear how you connect sessions to completed changes and handle cases that these definitions miss. Send me an example on LinkedIn so we can compare the methods.