Notifications
Clear all
Topic starter
19/08/2026 3:44 pm
TL;DR: Coding agents can now generate complete code changes, but observability still depends on explicit human-authored standards for spans, metrics, logs, and severity rules, according to Sawmills. The practical shift is from adding telemetry after code works to defining agent-readable instrumentation contracts before implementation.
NHIMG editorial — based on content published by Sawmills: The Instrumentation Guide for Observability in the Age of Coding Agents
Questions worth separating out
Q: How should teams make coding agents instrument software safely?
A: Teams should give coding agents a machine-readable observability contract before code is generated.
Q: Why do high-cardinality metrics cause so many observability problems?
A: High-cardinality metrics create too many unique time series, which raises cost, slows queries, and can make dashboards unusable during incidents.
Q: What do security teams get wrong about structured logging and traces?
A: Teams often assume that having logs and traces means the service is observable, but observability depends on correlation and meaning.
Practitioner guidance
- Publish an observability contract for every service Define approved logger, tracing library, metric naming, required fields, forbidden fields, and severity meanings in a machine-readable repo file that coding agents must consume before generating code.
- Block high-cardinality fields at review time Reject user_id, order_id, raw path, exception message, and similar unbounded labels in metrics, and route request-level detail to traces or controlled structured logs instead.
- Tie telemetry to business journeys and SLOs Require every new span, metric, and log event to map to a named user journey, an SLO, and a runbook entry before merge.
What's in the full article
Sawmills' full article covers the operational detail this post intentionally leaves for the source:
- Concrete examples of how to rewrite weak telemetry into stable, searchable event names and bounded metric labels.
- Practical guidance on deciding what belongs in logs, what belongs in traces, and what should never be emitted.
- A service-level observability contract pattern that teams can adapt for CI review and agent instructions.
- The article's detailed breakdown of how to align instrumentation with real SLOs and user journeys.
👉 Read Sawmills' instrumentation guide for observability in the age of coding agents →
Coding agents and observability: are your telemetry standards ready?
Explore further
19/08/2026 4:22 pm
Agent-written code turns observability into a governance problem, not just an engineering task. When a coding agent can edit multiple files, run tests, and prepare pull requests, the question is no longer whether instrumentation exists somewhere in the stack. The question is whether the organisation has defined enough policy for the agent to write telemetry that remains coherent under incident pressure. That makes telemetry standards part of software governance, not an afterthought. Practitioners should treat observability contracts as enforceable control documents.
A question worth separating out:
Q: How can organisations tell whether agent-written instrumentation is actually working?
A: Look for evidence that alerts lead cleanly to dashboards, example traces, log events, and runbooks without manual guesswork. If responders still have to reverse-engineer what a metric means or which log line matters, the instrumentation is not working. The test is whether the system explains a failure in operational language.
👉 Read our full editorial: Coding agents need observability contracts, not just auto-instrumentation
