Building a Self-Healing CI/CD System with an AI Agent

Engineering teams know when CI pipelines fail. What follows is the problem: a developer stops what they are doing, opens the logs, spends twenty minutes tracing the error, writes a fix, and waits for the pipeline to run again.

This pattern repeats 3-5 times per week per developer. Across a team of ten engineers, this compounds to 6-8 hours of interrupted work weekly. 

CI pipelines validate code changes before deployment. On each code push, the pipeline compiles the application, executes tests, and reports results. When everything works, developers barely notice it. Failures require immediate developer attention.

Most failures are not complex. A dependency version changed. A test assertion has been updated. A configuration value is absent. These are routine maintenance issues.

The cost lies in the interruption overhead. Interruption, context switching, and release cycle delays accumulate. For teams deploying 3-5 times daily, these delays compound.

The systems built by GeekyAnts treat CI failures as programmatically solvable problems. On failure, the system follows standard debugging workflow: it reads the logs, identifies what went wrong, looks at the relevant code, generates a fix, tests it, and submits the patch for review.

This process follows systematic patterns recognizable across most CI failures. Error messages are structured. Stack traces identify affected files. Fixes are straightforward with proper context.

These characteristics enable automation. An AI agent with codebase access and failure context completes this process without context-switching overhead. 

The platform is built across three layers, each with a distinct role.

The Application Layer is a Spring Boot backend service representing a simple product management system. It handles user role management, inventory updates, and discount calculations. A test suite validates these services and provides failure scenarios during CI execution. A GitLab CI pipeline runs on every push: compile, test, report. Stage failures trigger agent analysis.

The AI Agent Layer performs failure analysis and resolution. A Python service built with FastAPI monitors pipeline state. On failure detection, it fetches logs, analyzes them, queries the codebase structure, generates a fix, validates it, and creates a merge request.

The agent uses multiple data sources: a language model for reasoning, a structural codebase map, and historical failure memory. These improve accuracy beyond single-source analysis. The agent is backed by a Neo4j graph database for codebase relationships and a Qdrant vector database for failure memory.

Pipeline failure sequence:

A developer pushes code. The GitLab pipeline starts: compile, test, report. The pipeline fails due to a broken test or a compilation error. The agent detects the failure event.

Rather than passing the full raw log to an AI model, which would be slow, expensive, and full of noise, the agent first cleans it. Dependency downloads, verbose build output, and unrelated stack traces are stripped out. What remains is signal: error messages, stack traces, failing test names, and affected source files. This reduces the search space and improves reasoning accuracy.

The agent performs deep analysis: it queries the codebase structural map to identify component relationships before proposing changes.

A fix is generated based on that full context. The fix is validated locally before pushing. If validation passes, the patch is pushed, and a merge request is created for developer review. If the agent cannot resolve the issue, it escalates with a structured diagnostic report rather than raw logs.

Many CI automation tools detect failures and send alerts. This system differs through multi-layered analysis:

Log Intelligence

Raw CI logs sent to language models produce suboptimal results. Raw logs contain high noise-to-signal ratios.

The agent solves this with a dedicated cleaning stage. Before AI reasoning, deterministic parsing extracts error messages, stack traces, and test failures. The model then operates on a smaller, focused input, which improves both speed and accuracy.

Codebase Understanding Using AST and Graph Modeling

Knowing that a test failed is not enough context to fix it reliably. The system maintains a structural codebase map built through Java AST parsing.

This extracts structural elements such as classes, methods, imports, method calls, and dependencies, all stored in a Neo4j graph database as connected relationships. Class contains Method. Method calls Method. Service depends on Repository.

On failure, the agent traces affected components through the map before proposing fixes. This provides relationship context beyond error messages alone.

To keep this map accurate without rebuilding it from scratch on every commit, the system performs incremental updates. For each commit, modified files are reprocessed, their AST recalculated, and the graph updated. The map stays current without unnecessary computation.

Learning from Past Failures

CI failures repeat across commits and projects. Recalculating a solution that has already been found once is wasteful.

The agent maintains a searchable vector memory of historical failures using Qdrant. Each entry stores the error signature, failure context, and generated fix. When a new failure occurs, its error signature is embedded and the database is queried. If a similar failure is found, the system reuses the existing solution, reducing LLM token usage, response latency, and repeated reasoning costs.

The system improves through accumulated failure data.

Active Investigation, Not Passive Generation

Autonomous code changes require engineer visibility into system decisions.

The dashboard connects to the agent via WebSocket, streaming updates without page refresh. Engineers observe each analysis stage and decision rationale. Events streamed include agent activity, pipeline updates, and metrics updates.

• The dashboard surfaces four key views:
• The Overview shows aggregated metrics: total CI incidents, automated fix success rate, escalation rate, and recent pipeline activity.
• The Live Monitor shows the current pipeline, the active agent stage, and logs streaming from the backend.
• The History view lets engineers inspect past failures in detail: root cause analysis, generated patches, fix attempts, and merge request links.
• The Escalations view displays unresolved failures with diagnostic reports.

The immediate benefit is straightforward: fewer interruptions. When the agent handles a routine failure, developers do not need to context-switch. A merge request appears, they review it, and they move on.

The downstream effects compound. Pipelines that recover faster stay green more often. Increased confidence enables more frequent deployment. Delivery cycles become predictable without debugging delays.

Longer-term benefits accumulate: Initially, the agent analyzes each failure independent. Over time, it builds a library of known solutions. Common failure patterns resolve through memory lookup. The system becomes more valuable the longer it runs.

The current system is built around Java and Maven projects. The underlying architecture is not language-specific.

The log cleaning logic, the vector memory, the LLM reasoning layer, and the merge request workflow are all transferable. Node.js projects, Python services, Go microservices—the same approach applies. The primary adaptation required is language-specific AST parsing in the code graph layer. Other components transfer without modification.

The longer-term direction: a single agent monitoring polyglot organizations and handling CI failures across languages and building systems.

Traditional CI/CD pipelines are built to report. They run when code is pushed, surface failures, and wait for a human to act.

That model made sense when diagnosis required human judgment at every step. It makes less sense now. The patterns are recognizable. The process is systematic. The tooling to automate it exists.

Self-healing CI/CD systems do not remove developers from the loop. The merge request step is deliberate. Human judgment belongs before fixes reach production. What changes is where developers enter that loop. Instead of starting with a raw log file and no context, they start with a proposed solution and a clear explanation of the problem.

That shift from debugging to decision-making is where engineering time should be spent.