EcoPilot

Inspiration

CI/CD pipelines are the backbone of modern software delivery, but they're often silently wasteful — redundant test runs, missing cache layers, over-generous
timeouts, and retry loops that mask flaky jobs rather than fix them. At scale, this waste translates directly into higher cloud bills, increased carbon
emissions, and slower developer feedback cycles.

We asked: what if every merge request came with an AI teammate that could automatically audit your CI configuration, quantify its environmental and financial
impact, and hand you a merge-ready fix?

EcoPilot was born from that question — built on the GitLab Duo Agent Platform because it represents the most natural place for this kind of sustainability
assistant: right inside the review workflow developers already live in.

What it does

How we built it

EcoPilot has two layers that work together:

1. GitLab Duo Flow & Agents (flows/, agents/) — the primary developer experience. A four-stage Duo workflow orchestrates public agents: triage_agent finds the biggest waste patterns, impact_agent quantifies cost and carbon, remediation_agent proposes CI changes, and guardrail_agent adds merge confidence and rollback guidance.
   
2. EcoPilot Service (ecopilot/) — the execution engine. A Python ASGI service receives GitLab webhooks, parses .gitlab-ci.yml and pipeline history, runs deterministic analysis, computes savings estimates using BigQuery-backed GCP metrics, generates .gitlab-ci.yml patches, and posts results back to the merge
   request. When Anthropic is configured, the service augments reasoning through GitLab's Duo integration.

The flow-first architecture means EcoPilot presents correctly for the hackathon as a genuine GitLab Duo product, while the service backend delivers real,
actionable automation.

Challenges we ran into

1.Webhook reliability under load — GitLab webhooks fire on every MR event, and during burst activity (e.g., a team all merging at end of sprint), the service needs to handle concurrent requests without duplicating work or losing state. We addressed this with idempotency checks and graceful error handling that still produces useful output even when analysis partially fails.
2.Quantifying carbon impact accurately — Moving beyond runner-minutes to actual carbon estimates requires assumptions about runner infrastructure (on-prem vs. cloud, instance types, region grid intensity). We chose a pragmatic approach using GCP billing data and region-based carbon intensity factors, acknowledging that precision matters less than establishing a credible, consistent methodology.
3.Generating safe CI fixes automatically — Auto-fixing .gitlab-ci.yml carries real risk: a bad patch can break pipelines for every developer on the project.
4.EcoPilot mitigates this by limiting deterministic fixes to well-understood patterns (cache keys, test parallelism, retry counts) and always opening a remediation MR rather than modifying the main branch directly. The guardrail agent then provides rollback guidance so the fix can be reversed quickly if needed.

What we learned

Building EcoPilot taught us that deterministic remediation beats pure AI in demos. A system that relies entirely on an LLM call to generate a fix will fail at the worst moment — during a live demo, on a bad network, or when the model is rate-limited. By leading with rule-based pattern detection (missing cache, broad test scopes, wasteful retry counts) and using AI only to refine and reason about edge cases, EcoPilot stays reliable while still being intelligent.

We also learned that impact storytelling matters as much as the technical fix. Raw numbers — runner-minutes saved, dollars off the cloud bill — are compelling, but annualized projections and carbon equivalencies (trees planted, flights offset) make the savings feel real and personal to every developer.

Built With

• python
• yaml