AI writes the code. Who fixes the build?

const metadata = ; Main is red. The Slack thread starts within seconds. Someone asks whether it's flaky tests. Platform engineering says the runner pool looks fine. The author of the last merge says their branch was green locally. DevOps points at a dependency bump from two days ago. Twenty minutes pass. Nobody has opened the failing job log. This is not a tooling problem. It's an ownership problem. The invisible handoff Modern CI/CD sits at the intersection of three worlds: - Application teams write the code and the tests - Platform teams maintain runners, caches, and pipeline config - Infrastructure teams own the networks, secrets, and cloud accounts underneath When a build fails, each group can plausibly say "probably not us." That ambiguity is expensive. [Google's DORA research](https://dora.dev/) consistently links faster recovery from failed changes to higher delivery performance, and slow recovery almost always starts with unclear ownership. The rerun button makes it worse. Under deadline pressure, teams learn to hit re-run and move on. The build goes green. The underlying cause stays. Next week, the same failure returns, and the same ownership debate plays out again. What "ownership" actually means for CI/CD Clear ownership doesn't mean one team fixes everything. It means every failure type has a default responder and a defined escalation path. | Failure signal | Default owner | Escalate when | | | | | | Test assertion failed | Author / feature team | Failure repeats across unrelated PRs | | Dependency or lockfile conflict | Author / feature team | Affects multiple services simultaneously | | Runner timeout or OOM | Platform / DevOps | Isolated to one job type or repo | | Pipeline config or secret error | Platform / DevOps | After config change is ruled out | | External service unavailable | Service owner + platform | SLA breach or widespread impact | Most orgs never write this down. So every red build becomes a negotiation instead of a workflow. The senior-engineer tax Without explicit ownership, investigation defaults to whoever knows the most. Usually that's a senior engineer, often the same person who gets pulled into every incident, every flaky-test debate, every "is this us or the pipeline?" thread. That creates a bottleneck that scales poorly. Junior engineers wait. Teams lose confidence in CI. And the seniors burn out doing work that shouldn't require tribal knowledge: reading logs, comparing failed runs, checking whether the failure is new or recurring. The fix isn't hiring more seniors. It's making the investigation legible enough that ownership can be assigned automatically, or at least suggested, before the Slack thread starts. A practical ownership model Teams that ship reliably tend to share three habits: 1. Failures get triaged before humans argue about them. An agent or bot reads the failed job, classifies the failure (test, infra, config, flake), and posts a summary with a suggested owner. The conversation starts with context, not guesswork. 2. Platform owns the platform; devs own the code, with a narrow overlap zone. Flaky infrastructure gets fixed by platform. Broken assertions get fixed by authors. The gray area, "this test fails only on CI", gets a shared runbook, not a shared shrug. 3. Recurring failures become tickets, not folklore. If the same job fails more than twice in a week, it gets tracked. Ownership is assigned. The rerun culture stops because the cost of ignoring it is visible. Where agents fit This is exactly the gap CI/CD agents were built to fill, not to replace engineers, but to answer the first question faster: what broke, why, and who should look at it? An agent that reads the failed run, traces the error through logs and diffs, and opens a PR or posts a structured report doesn't eliminate ownership. It assigns it, with evidence. That's the difference between "main is red, anyone know why?" and "main is red: TestCheckoutFlow failed on timeout in payment-service. Likely caused by the Redis connection pool change in PR #847. Suggested owner: @payments-team." The takeaway CI/CD reliability isn't just about green badges and fast runners. It's about knowing who fixes the build when it breaks, before the standup, before the escalation, before the senior engineer gets pinged for the third time this week. If your team can't answer that question in under thirty seconds, you don't have a CI problem. You have an ownership problem, and no amount of faster hardware will fix it.