Inspiration

AI agents can now write code. The hard part is trusting what they write, above all in software that must never be wrong. The core of an exchange is a good example: if one order trades out of turn, someone loses money. I'd already built a matching engine in C++, so I asked: could it maintain itself, with an agent making the changes, while every change carries evidence that is hard to fake?

GitLab project: https://gitlab.com/b4ryterx-lab/matching-engine-autopilot (issues, merge requests and pipeline history referenced below are all public there).

What it does

Open an issue, and the rest happens with no human in the loop:

  1. Plan: a GitLab Duo flow (.gitlab/duo/flows/autopilot.yml) labels the issue as a bug, feature or incident.
  2. Create: the flow finds the cause, makes the smallest change, adds a unit test, runs the tests and opens an [autopilot] merge request.
  3. Verify: unit tests, then differential testing. 3 × 200,000 random orders go through the engine and through an independent Python exchange that shares no code with it, and the outputs must match byte for byte. Then a same-runner A/B speed gate: the new version and the previous one are built and timed alternately on the same machine.
  4. Secure: SAST (Semgrep) and secret detection run on every merge request.
  5. Govern: a gate report is posted on the merge request (red and Blocked if anything fails), and GitLab Duo Code Review has to approve.
  6. Release: an automatic release, tagged and described, on every merge.
  7. Package: a container image tagged with the commit hash.
  8. Configure: that exact image is deployed. Only one deploy runs at a time, and a late pipeline can't roll production back.
  9. Monitor: after each deploy the live service is checked. A scheduled probe re-verifies production every 30 minutes; if it fails, it opens an incident issue, which goes back into the autopilot loop.

How I built it

  • Engine: C++17 limit order book, price-time priority (a sorted map of price levels, a FIFO queue per level, a hash index for cancels). Before this hackathon, it had already rebuilt real Binance and Bitfinex books with 0 mismatches against the exchanges' own checksums and snapshots.
  • Agent: a GitLab Duo Agent Platform custom flow plus agent-config.yml, so the agent can build and test in its own environment.
  • Pipeline: .gitlab-ci.yml with 9 stages: build, test, verify, secure, review, package, deploy, release, monitor. GitLab's SAST and secret-detection templates run in merge-request pipelines.
  • Deployment: Render, deploying the commit-tagged image from GitLab's container registry via a deploy hook; a small Python service exposes /health and /verify.

Challenges I ran into

  • Shared CI runners are noisy. Identical code measured anywhere from 61 to 85 ns per message on different runners, so a fixed latency threshold kept raising false alarms. I replaced it with an A/B test that builds the base and candidate versions on the same runner and alternates them on the same order flows. Every real change since has scored a ratio between 0.988 and 1.012.
  • Deployment races, found by the AI reviewer. The deploy job went through four rounds of Duo Code Review, and each round found a real problem: a missing guard, overlapping deploys, a race on the :latest tag, and a late pipeline that could roll production back. All four were fixed before it was approved.
  • Security scans in merge requests. GitLab's SAST template only runs in branch pipelines by default, so I enabled it for merge requests, so that findings appear before anything merges.

Accomplishments I'm proud of

  • The agent fixed a real bug unaided. Issue #1: submit() could trade on an order whose id was already in the book. The flow labelled it, found the cause, added a test and opened !2. Every gate passed, and it merged, deployed and closed the issue by itself.
  • A feature, end to end. Issue #2 asked for immediate-or-cancel orders. The agent opened !4, Duo approved it on the first review, and it auto-merged and deployed.
  • The gates refuse bad changes. I submitted a deliberately wrong "speed-up" through the same hands-off path (!7): it inserts new orders at the front of their price level, so later orders jump the queue. It failed 5 unit tests, and on all three random order flows the comparison came out identical: false, so auto-merge never ran. The change wasn't even faster (speed ratio 1.045), and the correctness gates are what caught it.
  • The monitor caught a real outage. Production has been re-checked every 30 minutes since 24 Oct, and every check but one has passed. At 02:08 UTC on 27 Oct the probe couldn't reach the live service (HTTP 520 from the hosting edge), so it opened incident issue #3 by itself. The next check, 26 minutes later, passed.

What I learned

Trust in AI-written code comes from evidence, not review alone. Differential testing against an independent implementation is the strongest evidence I found: it checks every output byte rather than the cases someone thought to write a test for. I also learned that performance gates must control for the machine, or they cry wolf.

What's next

  • Make the probe retry before alerting, and word "unreachable" differently from "wrong output". Incident #3 was an outage, but its text said "not byte-identical".
  • The probe also re-runs the speed gate in production, so a slowdown opens an incident just like a wrong answer.
  • More order types (stop orders, self-trade prevention), each added by the agent through the same gates.
  • A depth benchmark (!6): mean latency is 72–87 ns per operation up to 10,000 resting orders, 132–149 ns at 100,000, and 256–279 ns at 1,000,000 (three runs, Apple M4 Max). Duo's review of the first version caught a bookkeeping flaw that made cancels look cheaper than they are; it was fixed and re-measured.

Built With

Share this project:

Updates

Submission history