Engineering the Goal: Building MatchDay with Codex 5.6 Sol

How we remotely supervised Codex 5.6 Sol from our phones, using an evidence-gated Peter-style loop to build and deploy MatchDay, a memory-aware 2026 World Cup travel agent, across two sessions

Comment

Inspiration

We had already built earlier versions of MatchDay around a simple problem: planning travel for a major soccer ⚽ match is fragmented and surprisingly risky. A cheap flight is useless if it lands too late. A hotel can look close while being difficult to reach on match day. A booking link can open a generic page with no actual results. A travel assistant can also remember the wrong thing—or forget a preference the user already confirmed.

For OpenAI Build Week, we wanted to explore a different question: what happens when we stop using Codex like autocomplete and start treating it as a persistent engineering system?

We did not give Codex one giant “build our app” prompt. We gave it a goal, an observable finish line, and evidence gates. Then we used our hybrid version of a Peter-style autonomous execution loop to keep moving through small, verified slices until the release was actually complete.

What we built

MatchDay v3 is a memory-aware World Cup travel agent. It can understand a natural travel request, recall relevant confirmed preferences, search and rank trip packages, detect a trip-breaking conflict, repair the plan, and independently verify the final result.

The product includes persistent owner-isolated memory, multi-turn corrections such as “cheaper” or “not Vancouver, Montreal,” immutable trip versions, ranked packages, evidence provenance, an interactive map, Stadium Lens, and privacy-safe sharing. It also distinguishes fixture, cached, discovery, live, available, and bookable evidence instead of presenting every provider result as equally trustworthy.

The live experience is deliberately conversational. A fan should feel like they are refining one trip with a capable assistant—not repeatedly filling out a form or restarting the plan.

How we built it

The user experience is a Next.js and React application on Vercel. Browser requests pass through a signed server facade before reaching FastAPI, durable workers, and private PostgreSQL on Alibaba Cloud ECS. Qwen Cloud handles runtime intent interpretation, bounded tool selection, memory proposals, repair selection, and user-facing explanations. Typed travel and context providers supply evidence, while deterministic ranking, safety rules, and an independent verification contract decide whether the final plan can be called verified.

We kept the build plane separate from the runtime plane. Codex and GPT-5.6 operated the engineering workflow through Git worktrees, tests, browser automation, independent reviews, deployment scripts, and evidence trackers. Qwen runs inside the finished travel product.

How we used Codex and GPT-5.6

Both core build sessions used Codex CLI with gpt-5.6-sol and reasoning effort set to max. We often shortened that combination to “Codex 5.6 Sol Max” while working.

Our execution loop was:

  1. Define the user-visible finish line.
  2. Build the smallest complete slice.
  3. Attack the result by trying to disprove it.
  4. Check the evidence against the goal.
  5. Fix verified defects and repeat.

A survivor tracker recorded the delivered boundary, dirty files, failures, next safe action, and executed proof. That became important when our remote workflow was interrupted. We were supervising Codex from a phone through Tailscale and Termius. The second session started three minutes and 24.847 seconds later, loaded the evidence-rich handoff, revalidated the repository state, and resumed from the exact unfinished revision instead of restarting from zero.

The resumed goal existed for roughly 25 hours and 56 minutes of wall-clock time. Codex’s goal tracker recorded 20 hours, 8 minutes, and 26 seconds against that goal. That was not 20 uninterrupted hours of model inference. It was a long sequence of implementation, tool calls, tests, reviews, deployment gates, and our steering between slices.

We made the product and authority decisions: what correct memory behavior meant, when a seller link was unsafe, how natural follow-ups should behave, which risks required human approval, and when public deployment was authorized. Codex handled source tracing, implementation, regression tests, adversarial review, browser and database QA, recovery, deployment orchestration, and evidence collection.

The production travel agent uses Qwen Cloud at runtime. Codex with GPT-5.6 was the engineering system that built and verified it. We keep those roles explicit.

The hardest challenges

The most useful work began with failures we could actually show Codex.

One screen displayed a saved home airport of YUL while the chat claimed no durable preference existed and continued planning from YVR. That became a deeper memory source-of-truth investigation covering autonomous learning, manual edits, correction, deletion, bounded recall, cross-session reuse, tenant isolation, and trip replanning.

Another flight action opened a generic or zero-result provider page. Codex turned that into an exact handoff contract for route, date, party, seller, freshness, redirects, corrupt history, and honest fallback behavior.

We also created a process deadlock by allowing only one independent review in total. When that review found a real defect, the fixed revision could not be reviewed and landed. We corrected the rule to allow one review per frozen revision, with up to three bounded cycles. That kept review strict without letting the loop run forever.

The release gate also caught a mobile LCP reading of 2.69 seconds against a 2.5-second budget. Codex stopped promotion, repeated the measurement, ran the functional canaries, and promoted only after the median passed at 2.006 seconds.

Results

The final release evidence included:

  • 1,438 backend tests passed;
  • 217 browser tests passed across Chromium, Firefox, and WebKit, plus two expected non-Chromium WebGL skips;
  • 8/8 real PostgreSQL concurrency and recovery checks passed;
  • 800 bounded stress and soak requests completed with zero errors;
  • production memory add → reload → delete → reload non-resurrection passed;
  • the final independent review converged clean within the bounded three-cycle rule.

The result is a working product, not only a technical demonstration. Judges can open it without credentials, run the demo scenario, inspect the visible Memory → Plan → Tools → Repair → Verify proof map, refine the trip with one-word follow-ups, reload persistent memory, and confirm that a private window receives a separate guest profile.

What we learned

The biggest lesson was that long-running autonomy should not mean endless activity. If a task genuinely takes five minutes, it should finish in five minutes. If release QA needs hours, it should keep going only while new evidence is moving toward a clear stop condition.

The most valuable part of the loop was not generation—it was Attack. Codex became much more useful when we required it to challenge its own completion claim, reproduce failures before fixing them, distinguish harness failures from product failures, and refuse promotion when the evidence did not pass.

We also learned that our role did not disappear. It moved upward into product truth, taste, priorities, risk, authority, and acceptance. Codex took on the demanding engineering loop below those decisions.

What is next

MatchDay currently serves fans planning event travel. The same architecture could become an embedded, branded planning agent for travel agencies, with approved inventory providers, tenant-isolated customer memory, and human approval before commercial transactions. That is a product direction, not a shipped B2B feature today.

We also published the exact Peter-style hybrid skill used for this build so other developers can inspect, adapt, and challenge the execution method rather than only reading a success story.

Built With

Share this project:

Updates