Inspiration
AI agents can already write code, and generating it is getting cheap. The open problem is what comes after: review, security, tests, release and monitoring. When several agents work on one repository they collide on branches and shared files, report results they never measured, and write tests that pass whatever the code does. A prompt that says "do not weaken the gates" is advice. We wanted the gates to be code, and the whole loop after the code to run on GitLab.
What it does
AFAW Engine closes the loop after the code is written. An orchestrator script picks the next task from the project board and files an issue with a fixed template, so no model chooses the work. A GitLab Duo Developer agent writes the change as a merge request. Deterministic gates judge it: a new test must fail on the old code (red_check), changed files are mutated and the tests must notice (mutation_gate), SAST and secret detection become a blocking decision (security_gate), and the files that define the rules cannot be changed by a service account (human_only_files). When every gate is green, merge_guard takes the merge request out of Draft and merges it. The pipeline of main releases and deploys to Google Cloud Run, and a Playwright test checks the live app (e2e_live). If a check fails, request_fix opens an issue and a Duo agent repairs it. The pipeline covers all nine GitLab DevSecOps stages, and each stage has a merge request written by Duo.
How we built it
- GitLab CI/CD with a nine-stage pipeline: plan, create, verify, secure, govern, package, configure, release and monitor.
- GitLab Duo Agent Platform: Developer Flow, Fix CI/CD Pipeline Flow, Code Review Flow and a custom flow, all under a service account.
- Python, FastAPI, pytest, mypy, ruff, mutmut (AST mutation testing), Semgrep, Playwright and Docker.
- Terraform for Google Cloud: two Cloud Run services (the dashboard and the demo app tha change), Artifact Registry, and a Workload Identity Federation pool for GitLab with no service account keys.
- A rule applied everywhere: the AI decides, the engine measures. Every number comes from a tool or the GitLab API, never from an agent.
Challenges we ran into
- Parallel agents picked the same task id several times. The pipeline caught it every time but does not prevent it.
- Seven merges within a minute made parallel deploys overwrite each other. A deploy lock fixed it.
- A repair of a planted branch inherited the planted task file and failed a check of its started a chain of issues. A cap of six open issues stops it.
- A failed pipeline can start a Duo session that costs credits even when the failure is a network cut. Closing the issue does not stop a session already started.
- human_only_files lives in .gitlab-ci.yml, so the same merge request can edit it away. We label it as a weak control.
Accomplishments that we're proud of
- One run from the orchestrator command to a verified live app: 25 min 19 s and 6.86 GitLab Credits.
- Three dependent tasks filed one after another, each verified live: 1 h 18 min 23 s in total, with no repair request.
- Self-healing: Playwright found three planted bugs on the live app, and one Duo session fixed them, 23 min 44 s from issue to verified app.
- Chaos experiments held: a flow editing a protected file, a test with no assertions, a fix that never works, a person's merge request, and a job killed mid-run.
- Every flow carries a carbon estimate with the SCI method and its assumptions stated.
What we learned
- A gate that says PASS does not prove it measured the right thing. A check that cannot red, not green.
- The weakest part of an autonomous loop is the identity that merges. Here the guard uses a person's token, because a service account token needs an Owner. We state it as a limit
- GitLab exposes no per-session cost or token counts. We read the GitLab Credits by hand and report a measured cost, not a saving.
What's next for Anti-Fragile Agentic Workflow Engine
- Replace the person's token in merge_guard with a service account token.
- Move human_only_files to a pipeline execution policy or required code owner approval.
- Run a repair that needs more than one attempt, and the chaos faults not yet run live ( and a failed deploy).
- Measure the comparison against reading the code, to turn the sustainability result fro measured cost into a measured saving.
- Run the custom agents AFAW auditor and AFAW planner, which exist and have not run.
Log in or sign up for Devpost to join the conversation.