Self-healing pipelines sound attractive until you ask which failures an agent is allowed to touch. A flaky network call and a deliberately broken dependency pin are not the same class of problem, and an agent that treats both as "auto-fix" will eventually ship the wrong kind of green.
The useful pattern is a narrow allowlist: retries, cache clears, known lockfile regenerations, and re-runs of labeled flaky suites. Anything that changes product code or production config should open a pull request with a short explanation, not merge itself at 2am.
That boundary is DevOps design, not model cleverness. Write the allowlist and the human gate into the pipeline definition first. Then the agent becomes a reliable junior on-call for a defined set of failures, which is far more valuable than a generalist that can "fix anything" and occasionally invent a worse build.
Self-healing pipelines sound attractive until you ask which failures an agent is allowed to touch. A flaky network call and a deliberately broken dependency pin are not the same class of problem, and an agent that treats both as "auto-fix" will eventually ship the wrong kind of green.
The useful pattern is a narrow allowlist: retries, cache clears, known lockfile regenerations, and re-runs of labeled flaky suites. Anything that changes product code or production config should open a pull request with a short explanation, not merge itself at 2am.
That boundary is DevOps design, not model cleverness. Write the allowlist and the human gate into the pipeline definition first. Then the agent becomes a reliable junior on-call for a defined set of failures, which is far more valuable than a generalist that can "fix anything" and occasionally invent a worse build.