Notifications
Clear all
Topic starter
20/08/2026 6:07 pm
TL;DR: Coding agents are already shaping 16 to 23 percent of code contributions, and Arize argues the real bottleneck is not model capability but the harness, telemetry, and evaluation loops that let agents verify changes against runtime evidence. The governance challenge now is to treat traces as the source of truth for agentic software, because blind automation only scales review overhead.
NHIMG editorial — based on content published by Arize: Closing the Loop on Coding Agents, Telemetry, and Self-Improving Software
Questions worth separating out
Q: How should teams govern AI-assisted development workflows that use coding agents?
A: Treat them as identity-governed execution paths, not just productivity tools.
Q: Why do traces matter so much for agentic software?
A: Because in agentic systems, traces describe what the system actually did at runtime.
Q: What breaks when coding agents do not have governed observability?
A: Verification breaks first, then debugging, then trust in the agent’s output.
Practitioner guidance
- Define agent tool boundaries Scope each coding agent to the minimum set of repositories, commands, and services required for its task.
- Require trace-backed verification Make every agented change produce trace evidence, evaluation results, and a change summary before merge approval.
- Separate human and machine interfaces Expose telemetry to agents through APIs and query interfaces, while reserving dashboards and deeper investigation views for humans.
What's in the full article
Arize's full article covers the operational detail this post intentionally leaves for the source:
- Examples of how coding-agent harnesses are wired to tracing and evaluation tools in practice
- Discussion of programmatic observability interfaces that let agents query runtime evidence directly
- Implementation details for skills, telemetry access patterns, and verification workflows in agentic software
- The article's specific examples of how teams use trace data to diagnose agent failures and refine code
👉 Read Arize's analysis of coding agents, telemetry, and self-improving software loops →
Coding agents and telemetry: can self-verification really scale?
Explore further
20/08/2026 6:41 pm
Coding agents are becoming a governed identity problem, not just a software productivity problem. Once an agent can select tools, retain context, and act across a development workflow, it behaves like a non-human identity that needs explicit access boundaries. That is why this topic belongs in the same governance conversation as workload identity and secrets control. The practical conclusion is that teams should manage agent permissions as runtime authority, not as a loose extension of developer tooling.
A question worth separating out:
Q: Should organisations separate agent telemetry access from human analyst access?
A: Yes. Agents need structured APIs and query outputs they can reason over, while humans need richer investigative views and audit context. Mixing the two creates overexposure for the agent and clutter for the operator, so the safer pattern is separate interfaces built for different consumers.
👉 Read our full editorial: Coding agents need telemetry to support self-verifying software loops
