You replaced the coder. Who runs the rest of the SDLC?
Every DevOps diagram you've ever seen — the infinity loop, plan through monitor and around again — was secretly an org chart. Someone on call reading dashboards. Someone filing the ticket. A triage meeting deciding what matters. A developer fixing it. QA checking the fix. A manager tracking whether any of this is getting better. The loop was never a pipeline; it was people, passing state to each other at meeting speed.
Then coding agents arrived, and we emptied exactly one chair: the developer's. The fix that took a day now takes minutes. And almost immediately, teams discovered the uncomfortable thing — the fix was never the expensive part. Everything around it still runs at human speed, held together by the same tickets, meetings, and memory it always was. You hired a fixer that works in seconds and kept a coordination layer that works in Tuesdays.
The other chairs were never engineering
Look at what each SDLC organ actually did, stripped of its ceremony:
- The ticket was memory — "someone is on this, here's what we know."
- The triage meeting was a ranking function — "of everything broken, this first."
- The senior engineer who remembers was institutional memory — "we fixed that in March; if it's back, that's worse than new."
- QA was verification, twice — once before the release, once by watching what production did after.
- The sign-off was accountability — a human owning the consequences of a change.
None of that is writing code. It's coordination: memory, ranking, verification, accountability. We implemented it in humans and Jira because software couldn't hold judgment-adjacent state. That constraint just expired.
The experiment that fails politely
Here's the tempting shortcut: skip all of it. Give your coding agent raw production traces and say fix this. It works — once. We know because we tried; the first version of this loop was exactly that.
Then it decays, in a predictable order:
- No memory — the agent re-diagnoses last week's problem with full confidence, every session, forever.
- No claims — two sessions grab the same failure; you get two conflicting PRs for one bug.
- No verification — "merged" quietly becomes the definition of "fixed." Nobody re-reads the next window.
- No clustering — four hundred spans of the same timeout drown the one novel failure that matters.
The coding agent was never the bottleneck. The coordination tissue was — and raw traces plus a smart agent is a coder with no ticket system, no QA, and amnesia.
Every chair, machine-shaped
So we collapsed the lifecycle into one MCP server. Not metaphorically — organ by organ:
| SDLC organ | What it actually was | Its machine shape in LoopOps |
|---|---|---|
| On-call reading dashboards | Observation | observe claims every unprocessed telemetry record — the claim is the window, so handled pain never resurfaces |
| The Jira ticket | Memory of who's on what | A loop run with a run_id and a stage timeline; every session opens with what's fixed, in flight, and regressed |
| The triage meeting | A ranking function | The diagnose packet clusters failures by shape and ranks them by the tokens they burn |
| The engineer who remembers March | Institutional memory | cluster_status: new, in_progress, verified, or regression — computed against loop history, not recall |
| QA before the release | Pre-ship verification | Replay the cluster's captured failures against the candidate fix and grade them, before anything ships |
| QA after the release | Post-ship verification | verify compares the windows around the fix — and refuses to record a verdict on no data |
| The manager's spreadsheet | Are we getting better? | Time-to-verified-fix and verified-fixes-per-week, first-class on the loop surface |
| The sign-off | Accountability | The approval gate — deliberately still a human |
One row didn't get automated, on purpose. Every external write — the issue, the PR, the deploy — stops at a human. Agent proposes, human approves. That's not a limitation we'll grow out of; it's the row that makes the other seven safe to run fast.
Two harnesses, one connector
The shape that falls out is symmetric. On one side, a production agent — a support bot, a founder's ops agent, anything emitting OTLP. On the other, a coding harness — Claude Code, Cursor, Codex — the agent that already knows the repo. In between, LoopOps holds the state neither side can: claimed telemetry windows, cluster history across fix cycles, verdicts that refuse to flatter you.
Neither side keeps loop state. The production app just emits; the coding agent just asks. The lifecycle lives in the connector — which means either end is swappable. Different model next month, different harness next year: the improvement history survives both.
And the connector measures itself with its own machinery. Every MCP tool call the coding agent makes lands as telemetry in LoopOps' own project — which verb, how long, how big, failed or not — scored by the same session scorecard we point at everyone else. The loop's most recent catch on its own dogfood: a single agent turn that burned 724k input tokens re-reading the same lookups, diagnosed from its telemetry, fixed behind the approval gate, merged. On our first production project, the first verified fix landed 43 minutes after the loop's first event, and fourteen fixes verified in the first week — verified meaning the next production window proved the metric moved, because a merged PR is a claim and a moved window is a fact.
The lifecycle didn't change. The operators did.
The SDLC was always right about what software needs: observation, memory, triage, verification, accountability. It was just implemented in the only substrate available — people and meetings. Now the fixer is an agent, and the coordination around it can finally be what it always wanted to be: state, with an API.
The loop is live: observe claims the window, the packet triages it, verify closes it honestly, and your agent opens every session already knowing what it fixed last time. Point your coding agent at it — the quickstart takes about five minutes.