-
-
DuoBack: a fix reaches an older release only when its own test proves it.
-
One merged fix, four releases, four clear results. Also proven on real marshmallow code.
-
The proof table DuoBack posts on the original fix: one row per release.
-
Every judging criterion and every DevSecOps stage, each linked to live evidence.
-
When older code differs, the agent adapts the fix. Here is exactly what it changed.
-
The agent proposes, a script decides, CI checks again. Seven rules the agent can't bend.
What it does
DuoBack takes a bug fix merged to main and delivers it to every older release that needs it, with proof for each one.
For every release it:
- Checks the bug is there. It runs the fix's own test on the old release. If the test already passes, the release was never affected and DuoBack says so.
- Brings the fix over. When the fix doesn't apply cleanly to older code, an AI agent on the GitLab Duo Agent Platform adapts it.
- Proves it. A plain script, not the AI, decides: the test must fail before, pass after, and every test that passed before must still pass.
Each release ends with one clear result: Proven, Proven, adapted (the agent changed the code, so a person looks closely), Skipped (bug was never there) or Refused (couldn't be proven; the reason is written down). Proven fixes become merge requests that are checked again from scratch. A person reviews and merges each one, and DuoBack then ships a patch release automatically. The original fix gets one table showing the result for every release, and a live page shows which versions are fixed, affected, or safe.
Inspiration
Every project that maintains older versions backports fixes by hand, and the only proof is a sentence. In 30 days GitLab merged 50 backports into one stable branch, with notes like "The cherry-pick applied cleanly". Nothing records whether the bug was really fixed there, or whether other versions were checked at all.
How we built it
- A custom flow on the GitLab Duo Agent Platform, published in the AI Catalog, that starts on its own when a fix's pipeline passes on
main. - The AI does only what needs judgement: adapting a fix to older code. Everything that decides the result (planning, testing, judging, publishing, releasing) is a plain, predictable script.
- Safety rails outside the prompt: the agent gets 3 attempts per release, can't touch the checks that judge it, and its claims are ignored; results are always re-checked.
- GitLab CI re-proves every backport, then tags the release, publishes it and uploads the package.
- The live evidence page runs on Google Cloud Run and links every claim to the GitLab job, merge request or release behind it.
Tested on real code
Beyond the demo project, we ran DuoBack on a fork of marshmallow, a popular Python library. It brought a real upstream fix to three real release lines, each passing more than 1,200 existing tests, and shipped v3.25.2, v3.23.4 and v3.21.4 in the fork.
Challenges
- The agent's account isn't allowed to switch on auto-merge, so proven fixes now wait for a person to click merge instead of failing.
- Real code broke two of our assumptions about how tests are named. We found both on marshmallow and fixed them.
What we learned
Let the AI do the creative part and let a script make the call. A reviewer trusts "the test failed before and passes after" far more than "the agent says it worked".
What's next
- Carry a library fix through the projects that depend on it.
- Support languages beyond Python.
- Write the missing test when a fix arrives without one, held to the same proof.
