Let's Go Christo!
#ai#codex#claude-code#agents#qa

Codex Builds, Claude Reviews: A Two-Agent Loop That Ships Better Products

I built Daytripper and RepoFinder entirely with OpenAI Codex, then turned my Claude Code tooling loose on the results. The QA and design findings are numbered in the git history, one regression test cites the report that found the bug, and both products came out better than either agent would have produced alone.

Last week I built two products entirely with OpenAI Codex: Daytripper, a travel planner, and RepoFinder, an open source recommender. I wrote up how each was built: the Daytripper post and the RepoFinder post. This post is about the part of the workflow I did not plan and now will not give up: after Codex built each app, I ran my Claude Code tooling against it as an adversarial reviewer. One agent builds. A different agent, from a different vendor, tries to break the result.

The evidence is sitting in both public git histories, so let me show you the loop instead of describing it.

#The receipts

RepoFinder shipped its first commit at 11:59 PM. Within minutes, my QA workflow (a Claude Code skill called /qa from gstack, a toolkit I run over every project, that drives a real headless browser against the deployed app) started filing findings, and Codex-built code started absorbing fixes. The commit log reads like a conversation between two agents:

  • fix(qa): rank direct capability matches first - QA noticed the fallback ranker buried exact goal matches under star-heavy generic repos
  • fix(qa): filter incompatible fallback picks - it recommended tools you could not actually install in the project’s ecosystem
  • fix(qa): return 400 for invalid source input - garbage input got a 500 instead of a useful error
  • style(design): FINDING-001 align search panel columns, FINDING-002 increase touch targets, FINDING-003 widen navigation targets - the design review pass, filing numbered findings the same way a human design reviewer would

Daytripper has the same fingerprints: two numbered design findings about the laptop fold (the hero was a fixed 820px, which broke on 1280x720 screens), each fixed and then documented with before/after measurements. And the QA pass caught things that were not cosmetic: the “Surprise me” button silently did nothing because the handler changed a style label the itinerary selection never read, and the save button invoked print with no persistent state. One High and six Medium bugs, every one with a root cause written down.

My favorite artifact is a test file header in the RepoFinder repo:

// Regression: ISSUE-001, passive traffic and unfinished analyses triggered Telegram alerts.
// Found by /qa on 2026-08-03.
// Report: .gstack/qa-reports/qa-report-repofinder-io-2026-08-03.md

The app was spamming me with operator notifications for every bot that sniffed the homepage. The Claude-side QA run found it, the fix landed as fix: notify only after completed analyses, and the regression test permanently cites the report that caught it. Provenance, checked in.

#Why cross-vendor review works

Human teams separate author and reviewer for a reason, and the reason applies double to agents. A model reviewing its own output shares the blind spots that produced the output. Codex built a “Surprise me” button, was told it worked, and had no reason to doubt itself - the code compiled, the tests it wrote passed. A different agent, with no investment in the code and a mandate to click every button in a real browser, found it dead in minutes.

The two agents also fail differently. Codex was excellent at the things I asked for: architecture, API contracts, structured outputs, the security boundaries in RepoFinder. The gaps were in things nobody asked for: touch targets under 44px, a fold that broke at common laptop resolutions, notification noise. Those are exactly the gaps a browser-driving QA agent and a design-review agent are built to find. Build depth from one agent, product judgment from another, and the union covers more than either alone.

And there is no diplomacy tax. A human reviewer softens findings. An adversarial agent files FINDING-003 at 11 PM without worrying about anyone’s feelings, and the fix is committed twenty minutes later.

#How to run the loop yourself

Nothing here needs my specific tools. The pattern is:

  1. Build with one agent. Give it the brief, the constraints, and a verification path. Let it own the implementation.
  2. Review with a different agent, in a real browser. Not a code review - a product review. Click everything. Resize the window. Watch the network tab. The bugs that embarrass you in a demo are behavioral, not syntactic.
  3. Number the findings and put them in commit messages. FINDING-001, ISSUE-001. Cheap discipline, and six months from now the git history explains itself.
  4. Pin every real bug with a regression test that cites its source. The test header pointing at the QA report is the difference between “we fixed it” and “it cannot come back.”
  5. Route fixes back through the builder. The reviewing agent files findings; the building agent (or you) fixes them. Keeping the roles separate keeps the review honest.

The uncomfortable takeaway from the week: the interesting question is no longer which coding agent is best. Both of these are genuinely good. The question is what workflow you wrap around them, and the best workflow I have found treats agents the way good engineering orgs treat people - nobody reviews their own pull request.

Let’s go!

Share this post