{"slug": "when-your-coding-agent-doesn-t-listen-evaluating-a-241-turn-claude-session", "title": "When your coding agent doesn't listen: evaluating a 241-turn Claude session", "summary": "A developer spent 241 turns and 7.5 million tokens with Claude to ship a feature, but the coding agent repeatedly delivered confident wrong answers, deferred fixes, and built on unverified assumptions, forcing the developer to act as a safety net. The session was evaluated by Kurrent's Capacitor tool, which scored efficiency at 3/5 and identified specific failures and corrective actions for future sessions.", "body_md": "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\n\nAnd yet parts of it were maddening\n\n## The corrections nobody should have to make\n\nWe 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\n\nLater, 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\n\nThe 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\"\n\nEvery 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\n\n## What Capacitor showed me\n\nHere'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\n\nWhen 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\n\nHere'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\n\nQuality: 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\n\nThen it did the part I actually care about. For each failure it produced a \"try next time\":\n\n*When review findings are identified, fix them immediately rather than deferring - the user had to explicitly push back, which wasted a round-trip*\n\n*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*\n\nThat 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\n\n## Why this compounds\n\nWithout 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\n\nWith 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\n\nCoding 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\n\nGet started with your own insights at [capacitor.kurrent.io ](https://capacitor.kurrent.io)\n\n## Frequently asked questions\n\n**What is Capacitor?**\n\nCapacitor 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\n\n**What are Capacitor Evals?**\n\nCapacitor 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\n\n**Why do coding agents need session evaluation?**\n\nCoding 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\n\n**How do teams use Capacitor's \"Try next time\" recommendations?**\n\nEach 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", "url": "https://wpnews.pro/news/when-your-coding-agent-doesn-t-listen-evaluating-a-241-turn-claude-session", "canonical_source": "https://www.kurrent.io/blog/when-your-coding-agent-doesnt-listen/", "published_at": "2026-07-15 17:40:58+00:00", "updated_at": "2026-07-15 17:58:44.060348+00:00", "lang": "en", "topics": ["ai-tools", "ai-agents", "developer-tools"], "entities": ["Claude", "Capacitor", "Kurrent", "Codex"], "alternates": {"html": "https://wpnews.pro/news/when-your-coding-agent-doesn-t-listen-evaluating-a-241-turn-claude-session", "markdown": "https://wpnews.pro/news/when-your-coding-agent-doesn-t-listen-evaluating-a-241-turn-claude-session.md", "text": "https://wpnews.pro/news/when-your-coding-agent-doesn-t-listen-evaluating-a-241-turn-claude-session.txt", "jsonld": "https://wpnews.pro/news/when-your-coding-agent-doesn-t-listen-evaluating-a-241-turn-claude-session.jsonld"}}