Pipeline Optimizer

Inspiration

I have been writing Go professionally for several years, across distributed systems at OVHcloud, microservices at Ateme, and blockchain infrastructure at Massa Labs. In every one of those environments, CI pipelines were an afterthought. Nobody owned them. They just grew.
The pattern is always the same: a pipeline starts clean, then over months of feature work it accumulates when: always on jobs that should be conditional, images pinned to :latest, package managers redownloading dependencies on every single job. The waste is invisible because it never throws an error. It just costs us time on every commit, forever. I wanted to build something that fixes this without requiring anyone to become a CI expert.

What I built

Pipeline Optimizer is a GitLab Duo Flow. Mention it in any issue and it reads your .gitlab-ci.yml, follows any trigger: include: references to child pipelines, and analyzes all discovered files as a system. It detect missing caches, unpinned images, redundant installs, jobs with no path-based trigger rules, and integration tests running on every branch. It then commits the fixes to a new branch and opens a merge request with a full report: findings table, before/after efficiency score across five categories, and a CO₂ estimate based on compute time saved.

The demo stack is a realistic three-service monorepo : Go API, React frontend, Python FastAPI, with 23 intentional inefficiencies baked in. A single trigger run finds all of them, scores the pipeline at 20/100, and produces a merge request that brings it to 100/100.

What I learned

Writing a reliable multi-step agent prompt is harder than it looks. The first versions would analyze correctly but then either open the issue reply before the MR existed, or batch commits and fail silently. I ended up with a strict 8-step structure where steps 3 through 5 are explicitly marked as mental steps : no output to prevent token overflow before the commits happen. That pattern alone fixed most of the reliability issues. Dynamic file discovery was the other challenge. The first version hardcoded the demo file paths directly in the prompt, which meant it only worked on this specific project. Switching to root-based discovery read the root file, follow include references, I've made it work on any GitLab project without configuration.

What's next for Pipeline Optimizer

Extend language support beyond Go, Node, and Python. Replace the YAML-only waste estimates with real pipeline history data pulled from job logs. And build a recurring mode where the agent monitors pipelines over time and opens a fix MR whenever regressions accumulate past a threshold.

Built With

• agent-platform:-gitlab-duo-flows
• create-commit
• create-issue-note
• create-merge-request
• get-job-logs
• get-pipeline-errors
• gitlab-ai-catalog-demo-stack:-go-1.26-(chi-v5
• gitlabaicatalog
• list-repository-tree