Project HHM

A GitLab Duo flow that asks what an issue means before it writes code, then ships to Google Cloud with no person approving or merging its merge requests.

Comment

Path A (Start Fresh), Hands-off. Repo: https://gitlab.com/gitlab-ai-hackathon/transcend-october-2026/43501501/showcase Live app: https://potluck-production-p7vgszsfla-nn.a.run.app · Video: https://youtu.be/qauKfuWAvbc

Hmm.

For teams that let coding agents ship: every silent guess an agent makes costs a revert, a review cycle and some trust. HHM is a GitLab Duo flow that asks what an issue means before it writes code, turns the answer into tests the code step cannot change, ships to production on Google Cloud and keeps checking it there. People answer questions; no person approves or merges its merge requests, a CI job does. (HHM is the sound you make before you guess.)

What it caught, in 8 real issues

What Count
Test scenarios answered by two reviewers (one reads the issue, one also reads the code) 56
Places they disagreed (where a guess would have hidden) 13
Open questions asked on the issue, most shipped behind a feature flag the reporter can switch in seconds 15
Decisions written down for the reporter instead of made silently 46
Times HHM stopped and asked instead of breaking an earlier promise (#12; #8 only after its first try broke one) 2
Acceptance checks passing in production, each issue's file in its own process (24 more run in CI) 98 of 98

The run worth watching: issue #12

"When someone adds a dish that's already on the list, let them know." Both reviewers read "let them know" as "stop them", so HHM shipped a block and asked about the rest. Ten minutes in, the reporter replied "I didn't mean block it", but the merge job did not wait for HHM's answer then: it merged the block at minute 13, and production verified it at minute 23. HHM saw its block had shipped, corrected its own note and asked. A person added a path for revising a shipped issue (and the merge job now waits for HHM's answer). The reporter answered, HHM rewrote that issue's tests, and the fix was verified in production 42 minutes after filing, after two replies. Later that day the reporter flipped one switch in GitLab's Feature flags (17:16 UTC, in the video), and seconds later the live page said "Potato Salad is already on the list", with no deploy.

The clean run: #14 "Let the host change the guest count" went from filing to verified in production in 36 minutes with nobody touching it: two questions asked, six decisions written down, and when the owner pushed a README change while its merge request was open, the merge job rebased it and waited for a fresh green pipeline.

How it works

  1. Ask first: two reviewers answer the same test questions; where they differ or the issue is silent, HHM asks on the issue and ships the safer answer, with the other behind a flag.
  2. Tests first: the tests are the first commit, and a check stops the code step from changing them. They change only through a revision the reporter asks for, or when a question is settled.
  3. The agent never merges its own work: a CI job on main merges only what passed on top of today's main (ran live on #14), and waits while the reporter's message to HHM is unanswered.
  4. Ship and keep checking: staging (checked without the scratch-database header), production on Cloud Run, a release, evidence on the issue, and every promise checked against production every hour.

Is it just a good prompt?

We gave two fresh issues to HHM, to GitLab's Developer flow and to a plain agent with HHM's rules file, with what the reporter meant hashed before filing. On first answers the other two did as well or better (HHM 7 of 8 checks, both others 8 of 8). Their project only ran tests, so their merge requests sat open: nothing merged, shipped or watched them. Everything after the merge request is what HHM adds. comparison/PROMPT_TEST.md.

Limits, said plainly

  • The owner filed the counted issues and plays the reporter. GitLab only starts a flow for project members, so an outside person can file an issue but HHM will not start on it until a member does.
  • CI merges with the owner's token, because flows cannot start other flows here, so GitLab names the owner as the merger (the agent account for !3 and !4). Agent commits show the owner as committer.
  • People pushed fixes to main while live runs exposed gaps; #8 reached production through one of those pushes, so #8 (and #3, which predates it) has no evidence note. A provenance check stops any deploy if agent work arrives another way, but main itself accepts Developer pushes.
  • The merge job's "wait for HHM's answer" rule is unit-tested but has not met a live case yet.

Stages

Plan · Create · Verify · Package · Secure · Release · Configure · Monitor · Govern, each with the GitLab feature that does it, in the README. Google Cloud: Cloud Run (staging and production), Artifact Registry, keyless deploy from GitLab, database backup in Cloud Storage, budget alert.

Built With

  • claude
  • fastapi
  • gitlab
  • gitlab-ai-catalog
  • gitlab-ci
  • gitlab-duo-agent-platform
  • gitlab-feature-flags
  • google-artifact-registry
  • google-cloud
  • google-cloud-run
  • pytest
  • python
  • sqlite
Share this project:

Updates

Submission history