Self-Healing DX Pipelines

Because we can afford to measure new things if our metrics pipelines maintain themselves

Originally posted on LinkedIn.

We track DX metrics via a GitHub Action — code coverage, CI build time, app start time, hot reload time.

We’re mid-replatform, so the app and how it runs are changing constantly. What we want to measure isn’t. Result: the action breaks every other morning. A path moves, a script is renamed, a dependency shifts.

For a week I just fixed it: open the failure, paste it into Claude Code, patch the workflow, merge. I was a courier between the CI log and the model.

So I built a second Action: headless Claude Code, with read access to the failing run’s logs and permission to open a PR against the workflow. When the DX metrics action fails, it reads why, proposes the fix, opens the PR. I review and merge.

Most AI energy right now goes into building new agentic workflows. The quieter move is pointing agents at the workflows you already have — to keep them doing the right thing as everything underneath shifts.

When the what is stable (measure these four DX metrics) and only the how keeps changing, an LLM is enough to hold it together. Self-healing is a declarative way of describing what you want. The model handles the imperative.