When Your Coding Agent Doesn't ListenKurrent Capacitor Shared Memory for Humans & Coding Agents Shared Memory for Humans & Coding Agents Get It Now >
Login Sign up
Login Sign up
Back to all postsWhen Your Coding Agent Doesn't Listen<br>Tony Young<br>• Wed Jul 15 2026<br>Ai Coding Agents Capacitor
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<br>The session at a glance in Capacitor — PR #933, Σ 7.5M tokens, 4,038 tool calls, 1d 5hAnd yet parts of it were maddening<br>The corrections nobody should have to make<br>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<br>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<br>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"<br>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<br>What Capacitor showed me<br>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<br>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<br>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<br>Capacitor's Plan Adherence evaluation - 4/5, with turn-by-turn evidence and a "Try next time" recommendationQuality: 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<br>Capacitor's Efficiency evaluation - 3/5 warning, identifying both efficiency losses by turn numberThen it did the part I actually care about. For each failure it produced a "try next time":<br>When review findings are identified, fix them immediately rather than deferring - the user had to explicitly push back, which wasted a round-trip<br>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<br>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<br>Why this compounds<br>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....