I gave my coding agent read access to production. Best hire of the year.

I asked it why staging was slow.

Twenty minutes later I had an answer, with the queries and timestamps to prove it. No tabs, no dashboards, no "let me check with the other team".

I am not alone in this. Anthropic studied 400,000 sessions of its coding agent between October 2025 and April 2026. Sessions spent fixing broken code dropped from 33% to 19%. Sessions spent operating software climbed from 14% to 21%. The coding agent is slowly becoming an operations colleague.

Honestly, it makes sense. The agent already reads code, runs commands and reasons over output. Hand it your logs and metrics, and it does what the on-call engineer does at 3 a.m. Just without the coffee and the bad mood.

Here is how I set it up, in three steps.

1. Connect the telemetry. The Azure MCP server lets the agent query Azure Monitor and Log Analytics. Run it read-only, monitoring tools only.
2. Give it its own identity. Reader and Log Analytics Reader, nothing more. It may look at production. It may not touch it.
3. Write a skill. That is a short markdown file with your runbook, loaded only when needed. Mine says: start from the symptom and the time window. Check the failure rate and the latest deployment first. Narrow the query before pulling raw logs. Follow the operation id across services. Come back with a diagnosis and the evidence. And never propose a fix you have not reproduced in a failing test.

That last rule is the one that counts. The diagnosis becomes a test, the fix goes through the pipeline, and a human merges it. Same rules as for the rest of us.

One warning. Logs are written by strangers. A crafted user agent or error message lands right in the agent's context. Read-only access is what keeps that harmless.

Will it replace your SRE? No. It replaces the first hour of every incident. You know, the one spent finding out where to look.

First published on LinkedIn.