Inspiration
"Code generation is solved." The bottleneck has moved: the hours after the last line is written, review, security, release, deploy, watching it in prod. That work is mostly glue, gates, and waiting, which is exactly what agents should own. I wanted to see how much of the entire post-code lifecycle could run from a single issue with nobody in the middle, and prove it, not just claim it.
What it does
You open a GitLab issue. A GitLab Duo Agent Platform flow plans the change, implements it on a branch, and opens an MR. A nine-stage CI/CD pipeline then carries it across the whole DevSecOps lifecycle, plan, create, verify, package, secure, release, configure, monitor, govern, deploying to Cloud Run. A remediation agent fixes security findings on the branch; a monitor stage runs synthetic checks and an error-budget decision that auto-rolls-back on failure; a govern stage computes a Software Carbon Intensity (SCI) ledger and posts a full audit summary back on the issue. The thing being shipped is Pulse, a small, real, dependency-free status service, so the pipeline has genuine code to build, test, scan, and run.
How I used GitLab to automate the post-code lifecycle (required)
GitLab Duo Agent Platform drives the reasoning: a custom flow (.gitlab/duo/flows/autopilot.yaml, Flow Registry v1) wires five components, planner → implementer → remediator → merge_when_pipeline_succeeds → reporter, each a focused agent with its own prompt and a minimal toolset. GitLab CI/CD is the auditable spine: .gitlab-ci.yml runs real work in all nine stages, uses GitLab-managed SAST / Secret Detection / Dependency Scanning / Container Scanning templates, the Container Registry, release-cli, environments, and dotenv artifacts that flow evidence stage to stage. Governance by artifact, not narration: every claim the Autopilot makes (health, carbon, stages covered) is backed by a pipeline artifact, so the issue summary is auditable.
DevSecOps stages covered (required, all nine)
plan · create · verify · package · secure · release · configure · monitor · govern. See docs/STAGES.md for the job and evidence behind each.
Sustainability, for the Most Environmentally Impactful prize (opt-in)
The govern stage runs a real SCI ledger (tools/sci_ledger.py) implementing the Green Software Foundation spec, SCI = ((E × I) + M) / R (ISO/IEC 21031:2024):
E from measured CI job seconds × requested vCPU/RAM via a documented power model (CCF coefficients, Google PUE 1.09); I from per-region grid carbon intensity (overridable with a live value); M embodied hardware carbon amortised per vCPU-second; R = one deployment. It compares each run to a baseline and reports the delta. Design choices that lower the number and are quantified per deploy: a dependency-free runtime (tiny image, low idle power), Cloud Run min-instances 0 (near-zero idle carbon), fast/coverage-guided tests, and caching. A live run measured ~0.34 gCO2e per deploy, ~82% under baseline. Region choice is made visible: the same pipeline is ~97% cleaner in europe-north1 than asia-south1. See docs/SUSTAINABILITY.md and sci_report.json.
Google Cloud bonus
The app deploys to Cloud Run (ops/deploy_cloud_run.sh, invoked by the deploy job); the deploy code is in the repo. Live URL: https://issue-to-prod-autopilot-maus47ftea-uc.a.run.app.
How I built it
Python standard library only for the service (so the image is tiny and the carbon story is honest), with the domain logic isolated in a pure, fully unit-tested core and a thin http.server adapter. The automation tooling (tools/) is likewise stdlib: plan parsing, synthetic checks, the error-budget decision, the evidence bundle, the job-duration collector, and the SCI ledger. The pipeline fails safe, deploy/registry jobs are gated on their credentials, so build→test→secure→govern runs green before any cloud is wired.
Challenges I ran into
Keeping the automation auditable rather than "the agent said it's fine", I pushed every verifiable fact into a deterministic tool with its own tests, so the agents orchestrate but the evidence is reproducible. Mapping all nine lifecycle stages onto real, non-token jobs (not placeholders) took the most design care, especially a monitor stage that can actually decide to roll back.
Accomplishments I'm proud of
A genuinely hands-off loop from issue to production, all nine stages doing real work, a carbon figure computed from the pipeline's own job record, and a 32-test suite, all in a project a judge can clone and run with zero dependencies.
What I learned
How far the Duo Agent Platform's flow model goes when you keep agents narrow and let a deterministic pipeline carry the evidence, and how much of "DevSecOps" is gate-and-wait work that automates cleanly.
What's next
Insert a single HumanInputComponent to offer the same project as Supervised or Assisted; add canary/progressive-delivery to the monitor stage; and feed the SCI trend back into the planner so the agent optimises for carbon over time.
Log in or sign up for Devpost to join the conversation.