Both core build sessions used Codex CLI with the exact recorded configuration gpt-5.6-sol and reasoning effort set to max. During the build, I shortened that to “Codex 5.6 Sol Max.” It is simply my shorthand for that model-and-reasoning combination—not the name of a separate model.
The second, resumed goal existed for approximately 25 hours and 56 minutes of wall-clock time. Within that window, Codex’s /goal tracker recorded 72,506 seconds—20 hours, 8 minutes, and 26 seconds—against the goal before it reached VERIFIED. I am not claiming that the model generated continuously for 20 hours. The number is the tracker’s execution total across a long sequence of planning, implementation, tool calls, test runs, review cycles, deployment gates, and my steering between slices. I reviewed progress, corrected decisions, and let the loop continue only while it was producing new evidence toward the release gate.
For part of that work I was not sitting at my laptop. I connected to it from my phone through Tailscale and Termius, watched the Codex CLI, answered the important decisions, and monitored progress from wherever I was—watching FIFA games in fan zones, jogging with friends, walking by the marina, biking, or just doing normal daily things. Safe, pre-authorized work sometimes continued overnight while I slept; in the morning I checked the goal tracker, reviewed the evidence, and steered the next slice. That was my own remote setup, not an official Codex mobile feature. What mattered was that the work could survive a long run, an interrupted connection, and a new session without restarting from zero.
This is the story of how that worked—and also where it did not work until I corrected the process.
First, an honest boundary
MatchDay did not begin as a blank prompt in these two sessions. I had built earlier versions for previous hackathons. They proved the basic idea: one football fan should be able to plan a match trip without opening separate tabs for fixtures, flights, hotels, maps, weather, and stadium timing.
What I used Codex and GPT‑5.6 to build here was the much deeper MatchDay v3 transformation:
a persistent MemoryAgent that can learn from verified behavior across sessions without treating every chat message as permanent truth;
a durable Autopilot that can recover after interruption, invoke typed tools, detect conflicts, repair a plan, and independently verify the result;
evidence-gated provider and seller handoffs that do not call a generic or zero-result page “verified”;
an owner-isolated FastAPI/PostgreSQL backend on Alibaba Cloud behind a signed Vercel facade;
a coherent product experience with multi-turn chat, ranked packages, provenance, an interactive map, Stadium Lens, immutable trip versions, and safe sharing;
adversarial security remediation, cross-browser QA, real PostgreSQL concurrency tests, load checks, deployment, and production canaries.
The production travel agent uses Qwen Cloud at runtime. Codex with GPT‑5.6 was my engineering system: it read, planned, implemented, tested, attacked, reviewed, recovered, deployed, and proved the release. Those are different roles, and I do not want to blur them.
The prompt was not the important part. The loop was.
The skill I used was my hybrid version of a Peter-style autonomous execution loop. Its core is simple:
One goal. One persistent tracker. Small evidence-producing slices. Attack your own work. Fix what is real. Stop only when the defined proof passes.
But the real skill is more than a repeated prompt. While preparing this article, I had Codex reread all seven files—990 lines covering the main loop, verification gates, hardening gates, scenario patterns, recovery and parallelism rules, artifact templates, and agent metadata—and check this explanation against them. The exact version used for this build is now included in this repository, not merely summarized here: open the skill.
The Peter hybrid execution loop
Here is what happens inside it.
1. Define the observable finish line
Before changing code, Codex converts my request into a behavioral contract. I called the final numbered release checklist Q11–Q24; in plain language, it covered the remaining product work, security remediation, full release QA, deployment, and production canaries. “Done” did not mean that a feature existed or that a unit test passed. It meant:
the remaining Q23 security remediations were closed;
the final clean-revision scan found no known validated in-scope finding;
Q24 backend, AI evaluation, memory, provider, PostgreSQL, browser, accessibility, security, load, recovery, migration, observability, build, and rollback gates had executed;
the exact verified revision was deployed;
production smoke tests and canaries passed;
the evidence matched the deployed revision.
That contract prevented an early “looks done” exit.
2. Keep a tracker that survives the conversation
The loop maintains a factual tracker with status, completed steps, blockers, next actions, and proof. A summary is treated as a claim, not as truth. On every resume, Codex checks the current repository, diff, tests, and runtime before trusting it.
That became critical when the first session was interrupted. It was not a Codex failure or a defect in MatchDay: the tmux/server connection used by my remote phone setup dropped. I opened a new Codex session, supplied the previous Session ID privately, and pointed it to the evidence handoff. The new session first rechecked the tracker, Git state, diff, and failing regression; only then did it resume from the exact unfinished boundary. The handoff did not merely say “continue Q23.” It recorded the delivered boundary, the uncommitted files, the failing regression, the clean and invalidated test results, the remote refs, and the next safe command.
3. Scale the work to uncertainty—not to how long the model can run
I repeated one instruction because it mattered to me:
If a task really takes five minutes, finish it in five minutes. If it needs an hour, use an hour. Do not turn a five-minute fix into three hours of ceremony.
The loop chooses the smallest complete slice that can produce trustworthy evidence. It avoids speculative frameworks and redundant reruns. A clean test is not repeated unless a relevant file, configuration, environment, or data boundary changed.
Long-running autonomy should not mean endless activity. It should mean persistent progress toward a stop condition.
4. Write the failure before the fix when possible
For a defect, Codex first tries to reproduce the user-visible failure. The expected result comes from the product contract, not from the implementation being tested.
This mattered when I showed it two concrete problems:
the UI displayed a saved home airport of YUL while chat claimed that no preference existed and continued planning from YVR;
a flight action could open a generic or blocked page instead of exact route/date results.
Codex did not just patch those screenshots. It expanded them into source-blind contracts for memory capture, persistence, retrieval, correction, deletion, cross-session reuse, trip replanning, exact route/date/party binding, stale evidence, redirects, corrupted history, and zero-result fallbacks.
5. Attack the result instead of proofreading it
This is the part of the Peter loop I value most. “Attack” does not mean attacking the product or writing dramatic criticism. It means trying to disprove your own completion claim:
Did I actually read every required file?
Does the test fail without the change?
Can a stale URL, duplicated query, malicious provider response, or wrong date still pass?
Did the browser really exercise the application, or did the harness fail before reaching it?
Is a claimed performance improvement measured, or only inferred from source?
Is the evidence current after the last material change?
During the flight-handoff slice, this phase found that public provider HTML could appear to certify itself, duplicate query parameters could drift, and a clicked July 19 flight could be rejected because the API used the trip’s July 18 start date. Each accepted finding became a regression and a smaller root fix.
6. Review a frozen revision, then review the successor—not a moving target
Non-trivial changes were frozen and independently reviewed. A finding was not accepted because a reviewer sounded confident; Codex reproduced it against the real path first. Verified findings were fixed, invalid findings were rejected with evidence, and affected gates ran again.
The bounded rule we eventually settled on was:
One independent review per frozen revision. If it finds a verified defect, fix it and review the new revision, up to three cycles. When clean, land it and continue.
That “eventually” matters. My first rule allowed exactly one review total. When the review found a real defect, the code was fixed—but the new revision could not be declared clean or landed. The goal kept colliding with its own authorization boundary.
I changed the rule. We kept review strict, but made it convergent. This was a human process decision, not something I wanted Codex to silently reinterpret.
7. Ship evidence, not reassurance
The loop ends with commands, runtime behavior, browser proof, review findings, hashes, or an explicit blocker. “Should work” is not a release verdict.
Reuse the exact skill
The repository includes the complete skill contract and its six companion reference/metadata files. To install it in Codex:
Then invoke $peter-hybrid-autonomous-execution-loop for a bounded, non-trivial goal. The skill explicitly requires right-sized effort: it should finish a five-minute task in roughly five minutes, while allowing difficult release work to continue only as long as new evidence is moving toward the defined stop condition.
Two sessions, one recoverable goal
Two Codex sessions and the evidence handoff
The first core session began on July 13. The final Q11–Q24 goal inside it started on July 17 and recorded 24h 4m 45s of goal execution before the remote tmux/server interruption forced me to move the work into a new Codex session. At that boundary:
Q11–Q22 were delivered;
Q23 remediations 1–2 were delivered;
remediation 3 still had a real unlanded regression;
remediations 4–17, the final scan, Q24, deployment, and canaries remained.
The session produced the detailed handoff instead of pretending the goal was complete.
The last turn was interrupted. Three minutes and 24.847 seconds later, Session 2 started. Its first useful work was not coding. It identified the prior session, loaded the handoff, compared it with the live tracker and Git state, and found that the temporary worktree had lost its .git pointer and 36 tracked paths while the four unfinished source files remained intact.
Codex restored the worktree metadata and missing paths from the delivered revision without rewriting the unfinished source. It then reran the current gates before continuing. That recovery is one of my favorite parts of the build because it shows why persistent execution needs more than a large context window.
I started the resumed /goal at 2026-07-19 07:32:25 UTC. It completed at 2026-07-20 09:28:34 UTC with 72,506 seconds—20h 8m 26s—of tracked goal time.
Across the two core intervals, the final branch contains 103 commits: 77 from Session 1’s interval and 26 from Session 2’s completion-goal interval. I do not use that number as a proxy for quality; small atomic commits were part of the review and rollback strategy. The more meaningful evidence is what those slices closed.
What Codex actually did during the long run
This was not one giant generation. It was a sequence of bounded loops.
Workstream
What Codex executed
What made it evidence rather than a claim
MemoryAgent
Repaired manual and autonomous memory source-of-truth behavior, current-message precedence, correction, deletion, disablement, bounded recall, cross-session reuse, and trip replanning
Source-blind memory and chat regressions, lifecycle evals, browser reload checks, tenant isolation, and production add/reload/delete/reload canary
Flight handoffs
Bound actions to the exact route, date, party, flight, seller, freshness, and safe URL; failed closed on generic, stale, blocked, corrupt, or zero-result pages
Valid/empty/mismatch/stale/redirect/corrupt contracts plus the real YUL→JFK browser path
Security
Completed all 17 queued remediations, then ran six independent review passes over the same 81-file deployed surface and fixed three additional verified findings
Ran backend, AI eval, provider, security, memory, PostgreSQL, three-browser, accessibility, load, build, dependency, migration, recovery, observability, and rollback gates
Exact pass/fail/skip counts saved against the frozen revision
Deployment
Backed up PostgreSQL, staged immutable backend/frontend revisions, verified identity and health, ran browser canaries, then promoted
No promotion after the first LCP reading exceeded budget; promotion followed repeat measurement and clean functional canaries
Session 2 recorded 20 successful worker starts, including parallel specialists for flight handoffs, 3D/map behavior, and infrastructure release QA. Parallelism was used for independent read-only audits and isolated slices—not to let multiple agents edit the same state blindly.
The final Q24 release evidence recorded:
1,438 backend tests passed;
8/8 real PostgreSQL concurrency and recovery tests passed;
73 Chromium, 72 Firefox, and 72 WebKit tests passed, with two expected Chromium-only WebGL skips across the non-Chromium engines;
800 bounded stress/soak requests completed with zero errors;
Explore Map, mobile overflow, control sizing, console, network, and repeated-open stability passed;
final independent review converged clean in the allowed three cycles.
The deployment canary is a good example of the loop refusing to flatter itself. The first staged mobile LCP reading was 2.69 seconds, above the 2.5-second budget. Codex did not promote. It repeated the measurement and attacked the render path; the median was 2.006 seconds, the cache-ignored run was 1.991 seconds, CLS was zero, and the functional, console, and network checks remained clean. Only then did it promote the stable release.
What I decided, and what Codex owned
I do not think “the AI built everything” is an honest description. The division of work was more interesting.
My decisions
Codex’s execution responsibility
Memory must learn autonomously from grounded chats and verified trips—not exist only as a manual settings form
Trace the source-of-truth paths, reproduce contradictions, implement lifecycle semantics, and prove them across API, eval, database, and browser boundaries
A seller link is not useful if it opens a CAPTCHA, generic page, wrong date, or zero results
Design the exact handoff contract, implement fail-closed behavior, and test valid plus adversarial states
Keep the experience conversational: short corrections such as “cheaper,” “closer,” or “not Vancouver, Montreal” must preserve context
Build and test intent grounding, precedence, ambiguity, correction, and multi-turn continuation
Make the system impressive but honest: show Stadium Lens and maps without pretending illustrative geometry is ticket evidence
Build accessible immersive UI with factual labels and non-WebGL/degraded fallbacks
Do not spend paid credits, make bookings, publish, or cross irreversible boundaries without authority
Use fixtures, sandboxes, cached or approved read-only evidence; keep transaction and publication gates closed until authorized
Do not over-engineer; fix safe in-scope problems instead of handing them back to me
Choose the smallest complete fix, add the regression, rerun affected gates, and stop when evidence satisfies the contract
Replace the one-review deadlock with bounded review-per-revision cycles
Freeze each revision, verify findings, fix real defects, re-review up to three times, and land only clean slices
My job moved upward: product truth, priorities, risk, taste, authority, and acceptance. Codex took on the repetitive but demanding engineering loop beneath those decisions.
How the build system connects to the product
Codex build plane and MatchDay runtime plane
The build plane was my phone or laptop → Codex CLI → GPT‑5.6 Sol at max reasoning → the Peter loop → Git worktrees, tests, browser tools, reviewers, deployment scripts, and evidence.
The runtime plane is the product judges can use: browser → Next.js on Vercel → a signed server facade → Caddy/FastAPI and a durable worker on Alibaba ECS → private PostgreSQL → Qwen Cloud and typed travel/context providers → deterministic ranking, repair, and independent verification.
That separation matters. Codex did not become the hidden production travel model, and Qwen did not write or deploy the application.
Mapping the work to the judging criteria
Technological Implementation
The non-trivial part is not that Codex generated TypeScript and Python. It is that the two sessions operated a recoverable engineering system: explicit goals, persistent evidence, dirty-state recovery, isolated worktrees, source-blind regressions, bounded parallel workers, browser/network inspection, independent reviews, deployment identity checks, and canary-gated promotion.
The session IDs — shared privately through the hackathon submission — let the judges inspect the actual work rather than rely on this article.
Design
The loop produced a complete user experience, not a dashboard of agent internals. A fan can chat naturally, preserve or correct preferences, see a conflict, approve or refine a repair, compare ranked packages, inspect evidence, explore the map and stadium perspective, reload an immutable trip version, and create a privacy-safe share.
Design decisions were verified across desktop and mobile, keyboard and reduced motion, Chromium/Firefox/WebKit, loading/empty/error/degraded states, and the boundary between an illustrative experience and a factual commercial claim.
Potential Impact
The immediate audience is a fan planning event travel. The problem is real: a cheap itinerary can still fail because of airport distance, arrival buffer, hotel location, stale seller links, missing refunds, or preferences the planner forgot.
The same architecture also has a credible B2B path. A travel agency could embed a branded planning agent in its website, connect approved inventory and commercial providers, preserve customer preferences under its own tenant boundary, and require human approval before transactions. That agency product is a direction, not a shipped feature in this release.
Quality of the Idea
Many travel assistants can produce an itinerary. MatchDay’s different idea is that the recommendation should become more personal across sessions and more trustworthy before action. Memory has provenance, lifecycle, bounded retrieval, and correction. Autonomy has durable checkpoints, conflict repair, human gates, and an independent final contract. Commercial evidence has freshness and a ceiling: fixture, discovery, cached, sandbox, live, available, and bookable are not interchangeable words.
The Codex workflow mirrors that product idea. It also remembers the goal, survives interruption, attacks its own assumptions, and refuses to call the result verified until the evidence boundary passes.
The mistakes are part of the story
The build was not a straight line:
My one-review-total instruction created a real authorization deadlock. I fixed the process instead of weakening review.
A browser harness failed before reaching the product because dependencies were missing, then failed again because a symlink duplicated Next.js request context. Codex separated harness failures from product failures before continuing.
A provider page returned HTTP 200 while showing a robot challenge or losing the route/date. The contract changed from “link opens” to “usable exact result is proven.”
A production-stage LCP sample missed budget. Codex held promotion until repeat measurements and functional canaries established the real state.
The final evidence review found stale historical pointers after the runtime was already green. The review loop fixed the documentation boundary and finished clean on cycle three.
This is why I would not replace the loop with one enormous prompt. The failures were not noise around the work. They were inputs to the next verified slice.
Try the result
No account or credentials are required for the deployed application.
For a configured live-Qwen run, omit MATCHDAY_QWEN_MODE=scripted; the copied .env supplies the selected production adapter and key.
Start the frontend in terminal 2:
npm run dev -- --hostname 127.0.0.1 --port 3000
Then open http://127.0.0.1:3000.
Evidence and privacy
The sanitized claim ledger is in EVIDENCE.md. I am not publishing raw session transcripts: they include private conversation, local machine paths, security work, and potentially sensitive operational context. Devpost receives the two /feedback session IDs so the actual Codex work can be evaluated through the intended channel.
I also do not publish private chain-of-thought. The evidence covers observable decisions, tool actions, commands, diffs, tests, reviews, timings, and outcomes.
What Codex changed for me
Codex did not remove me from the loop. It changed where I spent my time.
I spent less time manually moving between files, terminals, test runners, browsers, reviewers, deployment commands, and evidence documents. I spent more time deciding what “correct” meant: whether memory was actually autonomous, whether a result link was honest, whether a visual was factual, whether a review rule could converge, and whether the release deserved the word verified.
That is the part I want to keep using after the hackathon: not “AI writes code,” but a human sets the product truth while Codex carries a difficult engineering goal through implementation, attack, recovery, and proof.
