-
-
Ship breaking changes without breaking trust. Forward transformsna shallow migration returning 2/5 records into a proven 5/5 release.
-
Forward exposed 60% silent data loss, restored all five records, connected all nine lifecycle stages and completed recovery.
-
GitLab Duo derived source-linked requirements, repaired only the target and recorded the candidate, tests, attempts a& residual risks.
-
Inspiration
Software teams are being asked to move faster with AI, but the riskiest changes—API migrations, dependency upgrades, schema changes and platform transitions—can still fail in subtle ways.
A change can compile, pass familiar tests and return HTTP 200 while silently violating a new contract. The problem is not whether an AI agent can write code. The problem is whether a team can trust, verify and safely release what the agent changed.
That inspired Forward: a trust layer for AI-powered software change. It gives GitLab Duo room to reason and repair while keeping verification and production authority independent.
What it does
Forward turns migration documentation into a release that teams can defend.
A maintainer provides a trusted change source and a bounded target. Forward then coordinates a supervised workflow:
- GitLab Duo understands the change by reading a commit-pinned migration source and deriving traceable requirements.
- Duo creates executable checks that express the new contract.
- Duo repairs only the permitted scope and records its work in an auditable merge request.
- Trusted GitLab CI independently verifies the exact candidate with generated checks, baseline tests, security scans and a separate correctness oracle.
- Google Cloud stages the immutable image so the real deployed behavior can be tested.
- A human approves the exact commit and image digest before production.
Our controlled demonstration migrates a records client from a flat response to cursor pagination. The naive implementation passes its original shallow test but returns only 2 of 5 records, silently losing 60% of the data. Forward produces and proves a release that returns 5 of 5 records, rejects repeated cursors and rejects duplicate identifiers.
The API migration is the demonstration—not the product boundary. The same model applies to SDK upgrades, dependency changes, schemas, infrastructure and other high-risk software modernization work.
How we built it
We built Forward around the GitLab Duo Agent Platform as the runtime reasoning and repair engine.
Real Duo custom flows:
- Retrieved a pinned migration source
- Derived source-linked requirements
- Generated executable compatibility checks
- Repaired a bounded target
- Wired the verified repair into the application
- Responded to real staging failure evidence with two constrained reliability repairs
- Rejected an unsupported OAuth request before editing any code
GitLab provides the complete, auditable delivery backbone:
- Issues for maintainer intent
- Duo agent sessions for runtime reasoning
- Merge requests for constrained changes
- Public pipeline history for independent verification
- Security and secret scanning
- Immutable container packaging
- Environment-aware release controls
- Evidence linking all nine lifecycle stages from Plan through Govern
We deployed Forward on Google Cloud Run in africa-south1. Terraform provisions dedicated runtime identities, separate staging and production deployers, Artifact Registry and keyless GitLab-to-Google Cloud authentication through Workload Identity Federation.
Images are promoted by digest rather than mutable tags. Staging and production therefore run the exact artifact that passed verification and received human approval.
The public Forward experience presents the product story, measured result, trust model, GitLab Duo receipts and release evidence in one judge-friendly view.
Challenges we ran into
The hardest challenge was proving that agent output is not the same as release evidence.
Our deliberately shallow migration looked successful under its original test, so we created an independent five-scenario oracle that exposed missing pages, repeated cursors and duplicate identifiers.
GitLab Duo's managed runtime also required careful source retrieval. We added bounded HTTPS access, redirect revalidation, pinned source content and explicit provenance instead of allowing unrestricted browsing.
Google Cloud Run scale-to-zero exposed another real defect: the first cold staging request exceeded the original timeout. We did not hide or manually patch that failure. We returned the evidence to GitLab Duo.
The first bounded retry repair was insufficient, so Duo made a second, narrower timeout repair. The candidate then passed a confirmed cold-path replay with all five records.
We also learned that Google Cloud project ownership does not automatically provide billing-account budget permissions. We kept the system tightly bounded with scale-to-zero, one maximum instance per service and no database, GPU, persistent disk or VPC connector, while documenting the unavailable budget alert honestly.
Accomplishments that we're proud of
We are proud that Forward demonstrates real supervised autonomy, not a scripted chatbot experience.
- GitLab Duo performed substantive runtime research, test generation and code repair.
- A negative-control request proved that the flow can reject unsupported work with zero edits, zero branches and zero merge requests.
- The independent oracle exposed 60% silent data loss that the original test missed.
- The repaired release returns 5 of 5 records and handles cursor and duplicate-ID failures safely.
- Public GitLab pipelines preserve the visible history of testing, security checks, packaging and cloud identity verification.
- Keyless Workload Identity Federation connects GitLab to Google Cloud without a stored service-account key.
- Staging and production are bound to the exact candidate SHA and immutable image digest.
- A staging recovery exercise observed an intentional HTTP 500, restored traffic to the known-good revision and reverified all records.
- The public evidence experience maps the complete GitLab lifecycle—Plan, Create, Verify, Package, Secure, Release, Configure, Monitor and Govern—to inspectable proof.
Most importantly, no component is allowed to approve its own work:
- GitLab Duo reasons and repairs.
- Trusted automation verifies.
- The human maintainer decides.
What we learned
We learned that trustworthy AI development depends more on authority boundaries than on bigger prompts.
Agent explanations are useful, but they are not proof. Strong evidence comes from executable requirements, independent checks, immutable artifacts and observed runtime behavior.
We also learned that failures can strengthen an agentic system when they remain visible. The Cloud Run cold-start failure became evidence for a better Duo repair instead of something to edit out of the story.
A safe agent must also know when not to act. Forward's rejection flow showed that refusing unsupported scope is as important as successfully generating code.
Finally, reproducibility improves credibility. Our fixture is deliberately synthetic so every judge can inspect the same source, reproduce the same defect and verify the same outcome without depending on a changing external vendor API.
What's next for Forward
Next, we want to evolve Forward from a focused proof into a reusable modernization platform.
Planned extensions include:
- Ingesting authenticated vendor documentation and internal architecture decisions
- Supporting SDK, dependency, schema and infrastructure migrations
- Generating migration-specific evaluation suites from multiple trusted sources
- Adding concurrency, idempotency and performance stress evidence
- Introducing latency and reliability monitoring for staged candidates
- Expanding policy controls for file scope, tool access, retry budgets and risk tiers
- Adding protected release environments where plan capabilities permit
- Comparing multiple bounded candidate strategies before human review
- Creating reusable Forward templates for common modernization journeys
The long-term vision is simple: AI should not merely help teams change software faster. It should help them produce better evidence, clearer accountability and safer releases.
Forward: understand the change, prove the repair, control the release.
Log in or sign up for Devpost to join the conversation.