-
-
The story’s happy ending: Claire receives both tickets, linked to her original payment.
-
Lisa explains the tested repair and outstanding findings in ChatGPT. Alex approves before recovery begins.
-
Claire’s recovery test: original payment preserved, two tickets recovered, no additional charge or extra tickets.
-
GitLab Duo fixes the missing buyer email that prevented tickets from being created after payment.
-
Claire paid $80 for two tickets. Her payment succeeded, but her tickets and email never arrived.
-
GitLab Duo handles the repair. You stay in charge of the show.
-
The completed GitLab Duo session links Claire’s reported problem to the merge request containing its repair.
-
GitLab completes the candidate’s tests, packaging and security scan. Nine security findings remain documented.
-
Recovery tests preserve two payments, issue four tickets and receive two emails—with no additional payments.
Inspiration
Vibe coding makes it possible for regular non tech people to build software by having a conversation. Once it's built though running that software brings a different set of challenges: testing changes, investigating failures, checking security findings and deciding when a repair is ready.
That layer beyond the actual build creates a significant opportunity to bring GitLab’s capabilities to independent builders and small-business owners who are already working with an AI assistant.
Our example is Alex, owner of The Shermer Palace. He built a ticket site with Lisa in ChatGPT, using GitLab for the code and its verification. When Claire’s payment succeeds but her tickets never arrive, Alex needs an understandable explanation and a decision he can make.
What it does
Lisa connects through her thread in ChatGPT to GitLab’s engineering evidence and an explicitly approved recovery action.
The demonstration follows one customer’s problem:
- Claire pays a simulated $80 for two concert tickets. Ticket creation fails, leaving her payment recorded but no tickets or email.
- GitLab Duo investigates the failure and prepares a repair.
- GitLab CI packages and tests the candidate, including checkout, recovery and received email.
- Lisa reads the case and supporting evidence, explains the proposed fix and outstanding findings, and asks Alex to approve the specific candidate.
- After approval, Lisa invokes the recovery tool and checks the result.
Claire receives her two tickets against the original payment. No additional payment is created.
GitLab Duo handles the repair. You stay in charge of the show.
How we built it
The ticket application uses Python, Flask and SQLite, with a controlled SMTP inbox that makes email receipt observable.
GitLab Duo investigated the incident and produced the repair in merge request !2. The defect was a ticket insert that omitted the required buyer email after payment had already been committed.
Merge request !3 packages the runnable candidate and its verification. GitLab CI builds the container image, runs tests and recovery exercises, and records security-scan results.
Our integration supplies MCP tools for reading cases and evidence, delivering alerts, and applying an approved recovery. Lisa uses those tools from ChatGPT. The approval action checks the case, run and candidate before recovering existing paid purchases.
What we verified
The CI image exercise uses a separate, disposable database:
- Checkout produces one payment, two tickets and one received email.
- Recovery preserves two existing payments, issues four tickets—two per purchase—and produces two received emails.
- Repeating recovery retains the same ticket codes without adding payments or tickets.
The final recorded run, claire-case002-take2, contains one simulated payment. Its recovery receipt records one payment before and after, tickets T-1-1 and T-1-2, and a received email containing both codes.
The repository includes the recording receipt, candidate details and security disposition.
Challenges and lessons
A passing test, a successful execution receipt and a received email establish different things. We encountered a stale status reader that continued showing the original failure after recovery. We also corrected an inbox view that mixed records and orders.
Those lessons shaped the final demonstration: identify the exact run, preserve the original payment, separate test evidence from the recorded recovery, and verify what reaches the customer.
The candidate’s security scan still reports nine findings: four informational assertion findings and five medium findings in collection/watcher scripts. Their disposition is documented; successful recovery does not make the scan clean.
Why this matters
GitLab’s published direction recognizes a broader population of software builders and the growing importance of verification and governance around AI-generated code.
Lisa explores how those capabilities can serve an independent business owner through an assistant they already use. The owner can understand the proposed action, inspect its evidence and retain control over execution.
The potential extends beyond ticketing to other customer-facing applications built by small teams and individual creators.
Current scope and trying it
This is a controlled local demonstration with simulated payments and a demo mailbox. The recorded action performs local recovery; the repair and candidate merge requests remain unmerged.
Judges can clone the public repository, run the tests and launch the ticket application. Reproducing Lisa’s connected workflow requires their own GitLab credentials, MCP client and tunnel configuration. Our credentials and active recording environment are not distributed.
The README explains setup, evidence links and these boundaries.
What’s next
Improve installation and connection setup, expand recovery scenarios, and evaluate the workflow with independent builders. We would measure time to verified recovery, owner effort and successful customer fulfillment.
Our goal is to make dependable software operations accessible to more of the people who can now create software.
Log in or sign up for Devpost to join the conversation.