AfterCode Steward

Inspiration

What it does

How we built it

Challenges we ran into

Accomplishments that we're proud of

What we learned

What's next for AfterCode Steward

Inspiration

Every hackathon demo stops at "merge request opened". The hard part of software delivery is what happens after the code is written: keeping the pipeline green, landing the change, verifying the deployment, and writing down what actually happened. We wanted to see how far GitLab Duo Agent Platform could take that — not a helper that suggests code, but a steward that owns the change until production says yes.

What it does

AfterCode Steward is a five-component GitLab Duo Agent Platform flow that owns a change AFTER the code is written. You create an issue and assign it to the flow's service account ("AfterCode Steward"). From that moment, nobody touches anything:

1. Planner — reads the issue, inspects the repository, publishes an honest plan as an issue comment (files involved + lifecycle stages the change will traverse).
2. Builder — implements the smallest change on a steward/<iid>-<slug> branch, runs the test suite, opens a merge request that links the issue, and enables auto-merge.
3. Pipeline Guardian — owns the pipeline until it is green: reads failing job logs, fixes root causes on the same branch, submits an approving review, and lands the MR without human action once every gate passes.
4. Security Steward — triages the security posture of the change (secret scan, SAST), fixes small findings in the same branch, files larger ones as vulnerability issues, and posts the triage summary with evidence.
5. Release Auditor — confirms the merge and the default-branch pipeline, reads the deployment evidence (Pages deployment, version.json, health-check and audit artifacts), and writes the final audit comment on the original issue.

The flow is enabled in the project with auto-created triggers (Mention, Assign, Assign reviewer), so a plain issue assignment is the only human input.

How the merge happens without a human

The flow's agents do not hold a merge tool. Instead, the MR pipeline itself carries a release:merge job (stage: release, only on merge request events) that arms merge_when_pipeline_succeeds via the API — first with the CI job token, falling back to a dedicated masked merge token when the job token lacks permission. When every gate is green, GitLab executes the armed merge. In the demo run, the MR page shows "Merged by AfterCode Steward" — the service account — with zero human clicks.

Nine DevSecOps lifecycle stages — all covered

The project's CI/CD pipeline has one job per stage, and every stage leaves an evidence artifact the agents read back:

Stage	Job	Evidence artifact
plan	plan:change-plan	change plan from MR diff
create	builder agent commit	branch steward/3-delete-ship-endpoint
verify	verify:syntax, verify:test	syntax + 7/7 unit tests
secure	secure:secret-scan, secure:sast-lite	secret scan + lightweight SAST (0 findings)
package	package:artifact, package:container	artifact bundle + container build
release	release:merge (MR pipeline)	armed auto-merge + landed MR
configure	configure:manifest	environment manifest
deploy	deploy:staging + Pages	live Pages deployment
monitor	monitor:health	live health check of the deployment
govern	govern:audit	audit report artifact

How we built it

• Custom flow "AfterCode Steward" (flow registry v1 YAML) — five AgentComponents (planner, builder, pipeline_guardian, security_steward, release_auditor) with per-component toolsets and prompts, routers chaining them end to end.
• Custom agent "Release Steward" — the MR-to-production steward used inside the flow.
• A real (small) product — ship-log-api: a zero-dependency Node service used as the deployment target, so the automation ships something real on every run.
• CI/CD with nine stages, each producing evidence; Pages deployment + live health check.
• Triggers — the flow fires on issue assignment; no human clicks Run.

Challenges we ran into

• Making auto-merge work without giving the agents a merge tool: the CI job token was not allowed to arm merge_when_pipeline_succeeds, so the release:merge job falls back to a dedicated masked token and keeps the exact 401 trace as evidence.
• Keeping agents honest: the flow's status comments must reflect the pipeline state — in the demo run the builder session ended with "pipeline pending, the audit will follow" instead of claiming a false success.
• Timing the demo around shared runners: pipelines queued 20–40 minutes, so the run is fully hands-off — we assign and walk away.

Accomplishments that we are proud of

• A full loop from issue to production with no human in the middle: issue #3 assigned → plan → MR !2 → 9 green gates → auto-merge → main pipeline (13 jobs, 9 stages) → live Pages deployment reporting the new commit → final audit comment.
• The final audit was written by the flow's own Release Auditor and verified against raw job logs and live deployment state.

What we learned

• GitLab Duo Agent Platform flows can own a change end to end when each component has a narrow toolset and a clear evidence contract.
• "Hands-off" is a design property: it comes from triggers + armed merges + verification jobs, not from a bigger prompt.

What's next for AfterCode Steward

• Extend the loop with MCP servers (issue trackers, chat) for cross-project stewardship.
• Add scheduled triggers for nightly compliance sweeps (govern stage artifacts).
• Publish the flow as a reusable AI Catalog item for other projects.

Evidence (live, demo run #2)

• Demo issue: #3 — "ship-log-api: add DELETE /ships/:id endpoint", assigned to @ai-aftercode-steward-gitlab-ai-hackathon
• Session: 9390937 (triggered by assignment, hands-off; ended honestly with "pipeline pending — the audit will follow" instead of a false success)
• Plan comment + status comment on issue #3 (written by the flow)
• MR: !2 (steward/3-delete-ship-endpoint) — opened by the flow's builder, 7/7 local tests, security triage 0 findings, auto-merge armed by the release:merge job
• MR pipeline: #2943197691 — 9 gates green before the merge
• Merged by AfterCode Steward (service account), MR pipeline → auto-merge, no human click
• Main pipeline: #2943319228 — 13 jobs across 9 stages, all green; issue #3 auto-closed
• Deployed site: https://gitlab-ai-hackathon.gitlab.io/transcend-october-2026/43320880/showcase/
  • version.json changed from commit 3f27749c / pipeline 2943119617 to commit e902c9c9 / pipeline 2943319228 — written by CI jobs, no manual edits

Built with

GitLab Duo Agent Platform (custom flows, custom agents, triggers), GitLab CI/CD, GitLab Pages, Node.js.

Built With

• ai
• ci/cd
• devops
• devsecops
• gitlab
• node.js