Topic starter
18/08/2026 2:41 pm
TL;DR: Coding agents can loop, lose context, and misuse tools without throwing errors, so request-level monitoring misses the failure modes that matter, according to Fiddler. Observability has to capture session traces, behavioural signals, and cost attribution before teams can safely grant more autonomy than they can oversee.
Editorial analysis by NHI Mgmt Group, based on content published by Fiddler: “Coding Agent Observability: How to Observe What Your Agents Actually Do”.
Key questions
Q: What breaks when coding agents are only monitored with request logs?
A: Request logs assume a single call, a single response, and a deterministic outcome, but coding agents execute across many tool calls and model decisions.
Q: Why do adaptive agents create more governance risk than ordinary automation?
A: Because they can change their next step based on feedback, context, and prior memory.
Q: How do security teams know when a coding agent is degrading in production?
A: Watch for rising step counts, repeated tool errors, context-window saturation, and token burn that is far above the expected baseline for the task.
Practitioner guidance
- Instrument full session traces Capture every coding-agent session end to end, including model calls, tool invocations, file operations, and handoffs, so reviewers can replay the exact execution path.
- Track behavioural degradation signals Alert on loop counts, step inflation, context-window saturation, and tool-call error rates because those patterns usually appear before a bad code change is merged.
- Add code-quality evaluation to the pipeline Measure groundedness, faithfulness, and relevance on generated code so you can detect output that looks successful but no longer matches the ticket or repository reality.
Bottom line: Coding agents can produce wrong or unsafe code without generating obvious errors, which makes traditional request monitoring too shallow for governance.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:25 pm
Coding agent observability is now an identity and governance problem, not just an engineering telemetry problem. The moment an agent acts through delegated tools, the question becomes what it was allowed to do, what it actually did, and whether the session can be reconstructed after the fact. That is why runtime evidence must sit beside access policy, not behind it. Practitioners should treat coding-agent traces as part of the control surface, not just a debugging aid.
A few things that frame the scale:
- Claude Code-assisted commits leaked secrets at a rate of 3.2%, more than double the human-only baseline of 1.5%, with peaks reaching 31 secrets per 1,000 commits in August 2025, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: Should organisations treat coding agent telemetry as a control or only as observability?
A: They should treat telemetry as the input to control, not as control itself. Traces tell you what the agent did after the fact, but safe autonomy requires enforcing limits on tool use, context exposure, and delegated access while the session is still live. The control point has to move closer to runtime behaviour, not stay in the dashboard.
👉 Read our full editorial: Coding agent observability exposes where autonomous code fails