AI is writing code that can break prod
AI is writing code that can break production. Not a future problem — a ticket in your queue. The model will draft a helper that reruns a failed job, opens an issue, or pages whoever is on-call. Built carelessly, that helper reruns a prod deploy mid-incident. Your job in this studio is the check that comes first: the tool contract — the list of what the agent is allowed to call — before any of that code ships.
You're in the agent studio. This is a practice workspace: a short brief, and optional demo code if it appears later. You do not need to write code or know Python to start. What you're doing this lesson: decide which actions an AI helper is allowed to take before it can touch a real system.
The ticket below is the job. A few terms, once:
- CI (continuous integration — the automated tests that run when someone pushes code)
- flake (a test that fails randomly, then passes if you run it again)
- prod (production — the live system customers use)
- on-call (the person whose phone rings when production breaks)
- npm (the JavaScript package registry; a 503 means it was temporarily down)
- agentic (an AI that takes actions, not just writes text)
Here's the ticket, same shape it would land in your queue:
feat: CI triage agent. When a job goes red, the agent reads the log tail and does one of three things: rerun (flake), open an issue (real failure), or page on-call (prod is involved). Should stop paging humans for npm 503s.
Sounds like an afternoon. It is an afternoon — if you build it in the right order. The wrong order is the one everyone tries first: wire up the model, hand it some tools, watch the demo work, ship, then bolt on safety after the first incident. The right order is the one this studio runs:
- Tool contract — this lesson. What the agent can call, expressed as data, enforced by a validator.
- The loop with a meter — lesson 2. Step caps, cost caps, a trace line per step.
- Evals before it works — lesson 3. Golden cases from real incidents, wired before the router is finished, plus the ratchet that keeps every fix fixed.
Why the tool contract goes first
Because it's the blast radius decision. Everything else in an agent feature is recoverable: a bad prompt wastes tokens, a bad route wastes a code review. A bad tool call reruns a deploy, force-pushes a branch, pages the wrong on-call at 3 a.m. The contract is where you decide, before any model gets involved, which calls are cheap, which are destructive, and which need a human's thumbprint.
Your agent gets five tools:
| tool | what it does | risk |
|---|---|---|
get_failing_jobs | list red jobs | none — read-only |
read_log_tail | last N lines of a job log | none — read-only |
open_issue | file an issue with a severity | low — noisy at worst |
rerun_job | re-queue a job | costs compute, masks real failures |
escalate | page the on-call | wakes a human |
Two of those five get a confirm flag. By the end of this lesson, calling either one without it won't be a judgment call the model gets to make — it'll be a string that says reject: needs confirm, returned before anything runs.