Autopilot: Life After Code

Inspiration

Code generation is largely solved. Getting that code reviewed, secured, fixed, released and monitored is not. Teams still lose hours to red pipelines, vulnerable dependencies, unchecked policies and release notes nobody writes. We wanted to see how much of that post-code work GitLab Duo Agent Platform could take over, while a human stays in charge of the final call.

What it does

Autopilot is seven GitLab Duo flows plus a CI/CD pipeline wrapped around a small Flask notes API, at Supervised autonomy (Path A: Start Fresh). Agents do the multi-step work; a person approves the outcome.

• Issue to MR: an issue labelled autopilot gets a plan note, a branch, code, tests and a merge request that closes it.
• Security fix: reads Dependency Scanning findings, upgrades the vulnerable package and opens an MR.
• Pipeline fixer: reads a failed job log, finds the root cause and pushes the smallest fix.
• Governance check: reviews an MR against POLICY.md and comments PASS or FAIL per rule with evidence.
• Release summary: writes release notes for what merged.
• Incident reporter: opens an incident issue when the health-probe job fails.
• Config review: checks that every setting is documented, set per environment and free of secrets.

The issue-to-MR, security fix, pipeline fixer and governance flows have all run on this repo. The release summary, incident and config review flows are defined and run on demand as Duo sessions.

All nine lifecycle stages are covered:

How we built it

• App: a Flask notes API with pytest tests, a Dockerfile and environment-driven config.
• Pipeline: unit tests, container build and push, SAST, Dependency Scanning, Secret Detection, a deploy-staging job that runs the image in a staging environment, a health-probe job, and a create-release job that turns a version tag into a GitLab Release.
• Flows: each flow is a YAML definition in .gitlab/duo/flows/ with its own prompt, guards and a limited toolset, run as Duo Agent Platform sessions.
• Policy as code: POLICY.md holds four rules (tests required, no secrets, license present, no vulnerable dependencies) that the governance flow enforces.
• Guardrails: flows skip work that is not theirs, never loop on their own fixes, and the review flows are read only.

Challenges we ran into

• Agent sandbox limits: the issue-to-MR agent could not install pytest because package downloads were blocked. It said so in the MR, and our CI then confirmed the tests passed. Agent claims stay unverified until the pipeline agrees.
• Preventing loops and duplicates: a pipeline fixer that pushes commits can retrigger itself, so we added commit markers and checks for existing work.
• Precise prompts: loosely written instructions produced loosely scoped changes. Explicit steps and a defined final answer made flows far more reliable.
• Time: we built and documented everything inside the hackathon window and cut scope to keep the demo honest.

Accomplishments that we're proud of

• Issue #3 became a merge request with new endpoint code and four tests; CI passed and the governance check gave it a PASS on all four policy rules.
• An agent fixed a failing pipeline and another upgraded a vulnerable dependency.
• A version tag produced a GitLab Release (v1.0.0) through the pipeline.
• All nine lifecycle stages are mapped to a flow or pipeline job in a single coherent workflow.
• Public repository, MIT license, visible CI/CD history: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/29022429/showcase

Sustainability

We estimate footprint with the Green Software Foundation's Software Carbon Intensity method (ISO/IEC 21031:2024): SCI = ((E x I) + M) per R, where R is one merged change.

Worked example for one main pipeline (7 jobs, about 160 s wall time), using stated assumptions: 7 jobs x 60 s on a 2 vCPU runner at 3.5 W per vCPU gives E of about 0.0008 kWh. With an assumed grid intensity of 0.4 kgCO2e/kWh and 0.05 gCO2e of embodied emissions, SCI is about 0.37 gCO2e per pipeline run. This is an estimate: job durations, runner power and grid intensity are assumptions, and LLM inference energy for agent sessions is not measured.

Design choices that cut waste: agent guards prevent duplicate sessions, fix loops and no-op runs; the pipeline fixer shortens fail, diagnose, rerun cycles; the governance check blocks bad merges before they cost more pipeline runs; and the app is a single small container on slim base images.

What we learned

• Narrow toolsets and explicit guards matter more than clever prompts.
• CI is the source of truth; agent summaries are useful, green pipelines are proof.
• Supervised autonomy is the practical sweet spot today: agents do the grind, humans decide.

What's next for Autopilot: Life After Code

• Register every flow as an automatic trigger (MR opened, pipeline failed, tag pushed).
• Move toward hands-off mode: auto-merge when governance and scans pass, then promote staging to production.
• Deploy to Google Cloud Run and point the health probe at the live service.
• Add more policy rules and let the governance flow propose fixes, not just flag failures.
• Cut CI minutes further (staging deploys on main only, cancel superseded pipelines, caching) and re-measure SCI.

Built With

• gitlab-ci-cd
• gitlab-duo-agent-platform
• gitlab-duo-agents
• gitlab-duo-flows