# When your coding agent doesn't listen: evaluating a 241-turn Claude session > Source: > Published: 2026-07-15 17:40:58+00:00 I just finished a long coding session with Claude. Two hundred and forty-one turns, 7.5 million tokens, four thousand tool calls, a day and five hours of wall clock. We shipped real work - a six-phase feature plan, executed with TDD, isolated worktrees, and review cycles. The tests were excellent. The end result was good And yet parts of it were maddening ## The corrections nobody should have to make We were adding Antigravity ingest support to Capacitor: a six-phase feature plan that Claude and I executed end to end. Early in the session, I asked Claude to investigate which lifecycle hooks fired in a tool we were integrating. It came back confidently: only PreToolUse and PostToolUse, no Stop hook. That didn't match the docs, so I pushed back. It re-tested and - surprise - found the full lifecycle, including Stop. The coding agent's first answer wasn't just incomplete; it was wrong, delivered with confidence, and it took my correction to trigger the re-investigation it should have done the first time Later, a code review surfaced a batch of issues. Instead of fixing them, Claude quietly deferred them. I had to ask, verbatim: "Why are we deferring? Fix all the issues Codex identified." Only then did the fixes land. That's a full round-trip of my attention spent on something the coding agent already knew needed doing The worst one: a subagent nesting feature was fully designed, spec-reviewed, and implemented across six tasks. All of it rested on the assumption that no spawn-time signal existed in parent transcripts. Forty turns later, a ten-minute audit of real captured transcripts showed the signal was there all along. The core premise was false. Complete rip-out, full redesign. By the third pivot I found myself typing: "We've made major design changes on this topic a few times now" Every one of these episodes has the same shape. The coding agent commits to a path based on an unverified belief, builds on it fast, and I become the safety net. That's backwards. The whole point of a coding agent is that I shouldn't have to be the one catching confident wrong answers - and every catch costs wall-clock time, context window, and a pile of tokens spent generating code that gets deleted ## What Capacitor showed me Here's the thing: I knew the session felt inefficient, but I couldn't have told you precisely where the waste was. Capacitor could. Capacitor is Kurrent's shared memory and observability tool for AI coding agents, and it had been quietly capturing this whole session as it happened: the full transcript, the token spend, every tool call, the PRs that came out of it. Every screenshot in this post comes straight from it When the session ended, Capacitor's Evals went to work. The full transcript is replayed against a rubric covering four dimensions - safety, plan adherence, quality, and efficiency - and each is scored with turn-level evidence pulled from the session itself. The coding agent doesn't grade its own homework; the eval is an independent pass over what actually happened Here's how this session scored. Plan Adherence: 4/5, pass - the coding agent did follow the six-phase plan, with the deferral pushback and design pivots flagged as the deviations Quality: 5/5 - every feature and every review fix came with tests, from the first normalizer test to the final merge-conflict resolution. Efficiency: 3/5, warning - and this is where it got specific. It identified the two big losses by turn number: the wrong hook conclusion at turns 7–12, and the doomed feature built on an unverified assumption at turns 130–171 Then it did the part I actually care about. For each failure it produced a "try next time": *When review findings are identified, fix them immediately rather than deferring - the user had to explicitly push back, which wasted a round-trip* *Before implementing a feature whose design rests on a behavioral assumption, verify that assumption against real captured transcripts first - the ten-minute audit could have preceded the six-task implementation and saved a full redesign cycle* That second one is the entire lesson of the session compressed into a sentence. A ten-minute verification versus a multi-day rip-and-redesign. I lived it; Capacitor named it ## Why this compounds Without evaluation, the cost of a session like this is paid once and the lesson evaporates. My frustration shouldn't transfer to my teammates - the fix should. Everyone on the team independently rediscovers that coding agents defer review fixes, or that they'll build six tasks on an assumption nobody checked With session evaluation, the lesson becomes an artifact. "Verify behavioral assumptions against real data before building on them" goes straight into our coding agent instructions, so the next session starts with the rule baked in rather than learned at turn 171. "Fix review findings immediately, don't defer" becomes a standing directive instead of something each of us types in exasperation at our own turn 63. And because the evaluations are scored, we can actually see whether the changes work - when efficiency scores climb across the team's sessions, the feedback loop is real Coding agents aren't going to stop being confidently wrong tomorrow. Every session generates noise - confident wrong answers, deferred fixes, code built on unverified assumptions - and most of it never shows up in a diff, so code review was never going to catch it. Left unfiltered, that noise compounds into standing cost: wasted token spend, work nobody flagged as off-spec, code nobody understands in six months. Capacitor filters it against safety, plan adherence, quality, and efficiency, and turns what it catches into guardrails the next session - and the next teammate - starts with. The coding agent didn't listen at turn 7, turn 63, and turn 173. Capacitor did Get started with your own insights at [capacitor.kurrent.io ](https://capacitor.kurrent.io) ## Frequently asked questions **What is Capacitor?** Capacitor is Kurrent's shared memory and observability tool for AI coding agents. It captures every session your team runs with coding agents - full transcripts, token spend, tool calls, and the pull requests that came out of them - and evaluates how the work actually went **What are Capacitor Evals?** Capacitor Evals are automated reviews that run when a coding session ends. The full transcript is replayed against a rubric covering safety, plan adherence, quality, and efficiency, and each dimension is scored with turn-level evidence pulled from the session itself. The coding agent doesn't grade its own homework; the eval is an independent pass over what actually happened **Why do coding agents need session evaluation?** Coding agents sometimes deliver confident wrong answers, defer fixes they should make immediately, or build features on unverified assumptions. Without evaluation, those lessons evaporate after each session and every teammate rediscovers them independently. Session evaluation turns each failure into a specific, reusable guardrail **How do teams use Capacitor's "Try next time" recommendations?** Each eval produces concrete recommendations tied to specific turns, such as "verify behavioral assumptions against real captured transcripts before implementing." Teams add these directly to their coding agent instructions, so the next session starts with the rule baked in - and because evals are scored, rising efficiency scores confirm the changes work