The problem

Code generation is effectively solved; everything after the code is not. Review intake, test runs, security scanning, packaging, release notes, configuration checks, health monitoring, and license compliance are still manual chores. Small teams skip them under pressure, and the skipped steps are exactly where production incidents and quiet security flaws come from.

The solution

A Supervised post-code pipeline that takes over the whole DevSecOps lifecycle after the code is written. An issue or merge request enters the pipeline; nine stages — one for each GitLab lifecycle stage (plan, create, verify, package, secure, release, configure, monitor, govern) — execute autonomously and produce a single structured report. The pipeline then stops at an approval gate: at the Supervised level, a human approves the outcome before anything reaches production.

To prove it against something real, the pipeline ships NoteForge, a small notes API with shareable read-only links. The Secure stage catches two genuine flaws planted in its token code (MD5 token hashing and random-based token generation) and generates the corrected implementation using SHA-256 and the secrets module — the kind of flaw that slips into production codebases every day.

How GitLab and Duo automate the post-code lifecycle

  • GitLab Duo Agent Platform: .gitlab/duo/flows/post-code-supervised.yml defines the pipeline as a Duo custom flow (flow registry v1 style). LLM-driven AgentComponents handle intake planning, change summarization, release drafting, and the final report; deterministic OneOffComponents run the tests, build the artifact, scan for security issues, validate configuration, probe health, and check governance. .gitlab/duo/agent-config.yml pins the execution image, setup, cache, and network policy.
  • GitLab CI: .gitlab-ci.yml declares one job per lifecycle stage, each running the matching stage of a reference orchestrator, so the project's pipeline history visibly shows the automation running.
  • Reproducibility: the reference orchestrator (orchestrator/, Python standard library only) implements all nine stages deterministically and runs anywhere — laptop, CI, or container — so judges can reproduce the full run from the repository alone: python -m orchestrator run.

What the judges can try

  1. Read reports/report.md after a local run: per-stage status, security findings table, and the approval gate state.
  2. Run the pipeline themselves and watch the Secure stage flag the planted flaws and emit reports/fix-suggestions.md.
  3. Run the service (uvicorn service.app.main:app) and exercise the share-link feature the pipeline delivered.

Impact

For a 2–10 person team, this turns "we should really scan that before release" into a pipeline that always scans, always tests, always writes the changelog — and still leaves the one decision that matters, the production approval, with a human.

Built With

Share this project:

Updates

Submission history