Deploys that check their own work

Path: A (new project) · Autonomy: Hands-off · Google Cloud: Cloud Run, Artifact Registry, Workload Identity Federation

Project: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/43102832/showcase

Live demo service: https://quote-api-222678920984.us-east1.run.app (fictional "Sunshine State Pool Co." instant quotes)

Inspiration

I run a pool-service company, and I'm also its only developer. The bugs that cost me money were never the crashes: those page me. They were the quiet ones. A pricing change passes its tests, review looks fine, the service is healthy, and for a few days it quotes some customers the wrong price. Nobody notices until the margin report, or until a customer does.

"Life after code" for a one-person team means the deploy has to check its own work, because nobody else will.

What it does

Every merge to main runs a pipeline that treats the deploy as a claim to be proven:

1. Review. A GitLab Duo flow posts a pricing review and a security review on the merge request.
2. Release safely. The new version goes to Cloud Run as a candidate with 0% traffic. A smoke gate stops anything that crashes before a single customer sees it.
3. Verify with evidence. After promotion, the pipeline asks production for real quotes and compares them with prices a person reviewed. A Duo verifier flow explains what it sees, but it can only confirm a regression by citing the exact failing cases.
4. Recover without a model. If the evidence shows a regression, traffic goes back to the revision tagged last-good in seconds. If there is no evidence either way, production is left alone and a person is asked.
5. Fix it. An incident issue opens with the failing quotes in a table. A Duo incident-fixer flow writes a minimal fix and a regression test. The fix is deployed to a 0%-traffic preview and re-probed; only if every failing case passes is it merged, pinned to that exact commit. Production is verified again before the incident closes.

It has already done this, unattended

How I built it

• GitLab CI/CD runs the whole lifecycle: test, build, candidate, smoke, promote, verify, finalize, incident, fix build, fix preview, fix gate, fix merge.
• GitLab Duo Agent Platform: three custom flows registered from code into the AI Catalog (a pricing and security reviewer, a deploy verifier, an incident fixer), started by the pipeline through the API rather than by an event trigger, so an agent runs only once the evidence is in and never decides when it runs.
• Google Cloud Run with traffic tags for the candidate, the last-good revision and fix previews; Artifact Registry for images; Workload Identity Federation so GitLab CI deploys with no key at all, and only from the protected main branch of this project.
• The decision rules are pure functions with unit tests (ops/verdict.js), not prompts.

The rules the automation cannot break

• No destructive action without positive evidence; missing data means "hold and ask", never "roll back".
• The probes decide rollback; a model can explain and can gate the automated fix, but never decides alone.
• Automated fixes may only touch application code and tests, as regular files, must add a test, may not delete one, get one attempt per incident, and pause after two incidents in an hour.
• The fix's tests run in a build with no network. Merge-request pipelines get no cloud credentials and no automation token. Only merge requests from this project's own branches can be auto-merged.
• Model output is data. What the pipeline posts for a model is length-capped and flattened first, no model text reaches a shell, and nothing acts on the agents' own comments.

Lifecycle stages covered

Challenges

• Cloud Run reserves /healthz. Google's front end answers 404 before the container sees it, which blocked the very first deploy. The health check moved to /health.
• Model output is not JSON just because you asked. The verifier sometimes put a diff block before its JSON, and the parser took the first fenced block. It now prefers the last json block, with a regression test.
• Making the agent safe to leave alone took most of the work: a fork could open a merge request with the fixer's branch name, and public comments could steer the fixer. Both are closed in code, with tests.

What I learned

The model is best used where judgment helps (explaining a failure, writing a small fix) and kept away from the decisions that need to be boringly reliable (rollback, merge). The evidence decides; the agent does the work.

What's next

Probe cases generated from real quote history, and the same pattern for my real business's quoting system.

Built with

GitLab CI/CD · GitLab Duo Agent Platform (custom flows, AI Catalog) · Google Cloud Run · Artifact Registry · Workload Identity Federation · Node.js 22 (zero dependencies) · Claude Code (my pair programmer)

Built With

• claude-code
• docker
• gitlab
• gitlab-duo
• google-artifact-registry
• google-cloud-run
• node.js
• workload-identity-federation