Why coding-agent harnesses don’t fit RCA
Coding agents are built to edit a repo and run the tests until they pass. An incident asks a different question, about a system you cannot run twice.

Coding agents got good fast. Point one at a repository, describe a change, and it will read the files, write the patch, run the tests, read the failure and go again. That loop works. It is most of why these tools feel like magic.
Then people point the same tool at a production incident and it falls apart. Not because the model got worse, but because the loop around it was built for a different job.
The harness is most of the product
The model is the smaller half. What separates one coding agent from another is the harness, the loop that decides which files it reads, which commands it can run, and when it is finished.
That loop assumes four things. The repository is the whole world. You can run the code as often as you like. A passing test means you are done. Nothing moves underneath you while you work.
All four hold in a dev loop. None of them holds during an incident.
You cannot run production twice
A coding agent makes progress by trying something and looking at what happened. Compile, test, repeat. Being wrong is cheap, so being wrong often is a good strategy.
An incident hands you one system, already in a state you did not choose, that you cannot reset and cannot replay. The evidence is whatever got recorded before you arrived.
The answer is not in the repository
Root cause lives across layers the code never mentions. A deploy three hours ago. A config change in another team's service. A queue backing up. A dependency degrading upstream. You can read every file in the repository and still not have the cause.
No test goes green
A coding harness knows it is finished when the suite passes. RCA has no equivalent. You stop when a human believes the explanation, which makes the output an argument with evidence attached rather than a diff.
The system moves while you look at it
By the time an agent finishes reading, the thing it was reading has changed. A harness that assumes a stable snapshot will keep drawing confident conclusions about a system that no longer exists.
What that means for the harness we build
The map has to exist before the incident does. ewake keeps a graph of production, the services, the repositories, the people who own them and how they depend on each other, and keeps it current. When an alert fires, the agent does not start from a blank prompt and a checkout. It starts from the topology.
Where coding harnesses do belong
Once you have the cause and the fix is a code change, a coding agent is exactly the right tool. That is a handoff worth building. It is just not the same loop.
See ewake on your own stack
The fastest way to understand ewake is to point it at something real.

