Reflex

• 

  Every fixed incident becomes a rule the pipeline remembers This is the tab that keeps track and shows all of them

• 

  A repeat of an old mistake is refused by name

• 

  A repeat of an old mistake is refused by name the second test that rejects it

• 

  One issue handed to the Duo Developer agent

• 

  The agent’s fix and its regression tests

• 

  Jobs across all nine lifecycle stages

• 

  Jobs across all nine lifecycle stages second side

• 

  The gate checks evidence, including that the new test fails on the old code

• 

  The app’s live invoice builder selction

• 

  The app’s live invoice builder

• 

  LedgerLite, the demo app Reflex protects

Inspiration

Most of what I read about AI coding agents is about how fast they write code. What kept bothering me was the part after the code is written. How do you know the change is actually right? And how do you stop the same mistake from coming back next month?

I got a small taste of both while testing GitLab's Duo agents on a demo shop app. I planted a bug (a coupon code that crashed checkout when typed in lowercase), filed an issue that said nothing about the cause, and watched. The Developer flow found it, fixed it more carefully than I expected, and added tests for cases I hadn't thought of. Earlier, the pipeline agent's own report had mentioned a separate refactor merge request that dropped the type annotations from a file. I hadn't asked for that.

So one agent did something good and another did something nobody could explain, and nothing in the pipeline could tell the difference. Even the good fix would be forgotten, because nothing stops the next person (or the next agent) from writing the same bug again. Reflex is my answer to both problems.

What it does

Reflex is a GitLab pipeline with two jobs: verify every AI-made change, and remember every mistake.

You file an incident issue and hand it to the Duo Developer agent. After that:

1. Fix. The agent opens a merge request with a fix and tests.
2. Verify. A deterministic gate checks the merge request against evidence. Changed source needs a changed test, the new test must fail on the old code (the gate runs it there), no surprise dependencies may appear, the pipeline and guard files can't be edited together with code, and existing rules and incident records can never be edited or deleted.
3. Learn. After the merge, one command turns the fix into a guard rule. It refuses unless the rule flags the code as it was before the fix, stays quiet on the code after it, and the same flaw is gone from the rest of the codebase. If other places still have the flaw, it lists them.
4. Remember. The incident is written to the repo as a record chained by hash to the one before it, so editing history is detected. It shows up on the Immunity page of the demo app.
5. Enforce. The rule joins the guard job that runs in every pipeline. If a later change repeats the mistake, the job fails and names the original incident.
6. Watch. After a deploy to Render, a live check waits until the new commit is actually running, then sends requests and checks error rate and latency.

It has jobs in all nine lifecycle stages: planning (a risk score for every change), creating (the Developer agent's merge request and a type check), verifying (tests, build, rule proof, guard, and the gate), packaging (a Docker image and a software bill of materials), securing (GitLab's secret detection and SAST, plus a dependency audit), releasing (tags and release notes built from the incident records), configuring (policy and deploy configuration checks), monitoring (the live check), and governing (the audit report and the chain check).

The app it protects is LedgerLite, a small invoicing and stock app for shops, with four realistic bugs planted on purpose so there were real incidents to handle.

How we built it

LedgerLite is a TypeScript monorepo: a React, Vite and Tailwind client with Framer Motion animation, and an Express API with zod validation and tests on every route.

The AI work is done by GitLab Duo's built-in flows, mainly the Developer flow, which turns an issue into a merge request. Everything that decides whether a change is trusted lives in a small command line tool written in TypeScript with no dependencies, which Node runs directly. It has its own 40 tests, and it runs inside GitLab CI/CD.

The rule I held myself to: agents decide, the pipeline enforces. Every verdict comes from a deterministic job, so no AI sits in the gate and no one can talk their way past it. The app ships as a Docker image on Render.

Challenges we ran into

My first pipeline failed in five different ways in a row: dev dependencies skipped because of one environment variable, a stale lock file, a Docker image with no npm, a missing tool, and a malformed artifact file. Each one was small, and each taught me to add one job at a time and prove it works before adding the next.

An early version of the pipeline I generated looked impressive and checked nothing. It printed success messages and hardcoded numbers. I deleted it, and that became a rule for the whole project: nothing in a report is allowed to be typed in by hand.

GitLab itself shaped the design. Flow triggers need a human action and one flow can't start another, so I built the loop around a single human step plus CI jobs for the deterministic work.

I also had no payment card for Google Cloud, so I deployed on a free host instead. And I was new to CI/CD and to GitLab's agent platform, with about two weeks.

Accomplishments that we're proud of

• A gate that checks facts instead of announcing them. On the Developer agent's real fix, it ran the new test on the old code, saw it fail, and passed every check. [[Keep only if it still shows PASS in your screenshot.]]
• The agent did better than my rule expected: it fixed the bug the recorded way, tested inherited keys I hadn't thought of, and pointed out two other places with the same flaw.
• A rule that can't be learned without proof. [[Add: how many incidents you learned, and keep the blocked repeat only if it worked in your demo.]]
• A live check that confirmed the deployed commit and then ran 40 requests with no errors. [[Replace with your latest numbers, or remove.]]
• Going from "what is a pipeline?" to all nine lifecycle stages in about two weeks.

What we learned

• AI agents are good at fixing and bad at telling you exactly what they changed. Those are two different skills, and the second one needs a checker.
• A verdict you can't argue with has to come from a program, not from another model.
• A fix is only half the job. The other half is making sure it stays fixed.
• Impressive isn't the same as long. Some of my best decisions were deleting things.

What's next for Reflex

• Letting agents draft the guard rules, with the same proof requirement before any rule is trusted.
• An MCP server, so any agent can ask Reflex what the project has learned before it writes a line of code.
• Rule packs that teams can export and import, so an incident in one project protects another.
• Comparing the new version against the old one on the same requests before promoting a deploy, with automatic rollback.
• A one-line GitLab CI/CD component, so adopting Reflex takes minutes.

Built With

• docker
• express.js
• framer-motion
• gitlab
• gitlab-ci/cd
• gitlab-duo-agent-platform
• node.js
• react
• recharts
• render
• semgrep
• supertest
• tailwind-css
• tanstack-query
• typescript
• vite
• vitest
• zod