Adversarial Dogfooding Loop
Force all your work through your own product even when it's the wrong tool, so it becomes the right tool
- Difficulty
- Moderate
- Time to result
- ~ongoing to results
- Steps
- 3
- Confidence
- 88%
The Codex team deliberately does as much of their own work inside the Codex app as possible — even when it's not the best tool for the job — so that the friction they hit becomes the roadmap for making it the best tool. This means intentionally accepting a worse day-to-day process to force product improvement, tightened by a fast personal build-fix-build loop.
Origin
Andrew Ambrosino describes this as the loop that informed the entirety of the Codex app's development at OpenAI.
Core principles
- 01Use your own product for real work even when it's actively hostile to that work
- 02The friction you feel becomes the prioritized list of what to fix
- 03Accept a worse process temporarily so the product gets better
- 04A tight personal loop — hit a wall, fix it, now you can do more — compounds fast
How to run it
- 1
Commit to doing real work in the product, not just testing it
Set the goal of performing your actual job inside the app — Ambrosino's original goal was to build the Codex app using the Codex app itself.
Pro tip Pick a job that genuinely stresses the product so the friction you surface is real.
Watch out This is a 'deeply uncomfortable place to be in' — you're accepting a worse process on purpose.
- 2
Turn every point of friction into a fix
When you can't do something in the app, fix that gap so you can — then the next thing you couldn't do becomes visible.
Pro tip 'I can't do this thing, I should fix that so I can do the thing; now I can do more things.'
- 3
Let your evolving role redefine what the product must do
As your own job changes (IC → hiring → product discovery), re-point your usage at the new problem so the product grows to cover it.
Pro tip Watch what themes recur across many people's personal setups, then promote the common one into a first-class feature.
Watch out Don't promote every personal hack — decide what should become a product primitive versus what's just how one person does their job.
In the wild
Ambrosino set a personal goal to make Codex good enough at development that he could build Codex itself with it, running a fast dogfooding loop: hit a limitation, fix it, unlock more capability.
→ Codex went from a tool the team didn't use full-time to one they use for everything; ~100% of OpenAI employees use it weekly and usage grew 6x since January.
Non-engineering teams started using Codex even though it was 'actively hostile' to them — showing code, asking approval to run ripgrep. Rather than dismiss it, the team read it as signal that the surface could generalize.
→ The friction of non-engineers using a dev tool became the basis for generalizing Codex into a broader knowledge-work tool.
Common mistakes
Improving your process instead of the product
Reaching for a better external tool when the product falls short removes the very friction signal that would have told you what to fix, so the product never becomes the best tool.
Promoting every personal workflow into the product
Not every clever personal setup should become a feature; failing to distinguish a genuine recurring primitive from 'that's just how you do your job' bloats the product.
Is it for you?
Best for
Builders of horizontal tools who can plausibly do their own work inside their product
Not ideal for
Teams building products they cannot realistically use for their own daily work, or where accepting a degraded process would harm customers
From the transcript
“There is a desire among all of us to try to do as much as possible in the app even when it's not the best…”
“we often don't improve our process so that we can make the product better to do it which is a deeply like uncomfortable place to…”
“I need to make this so good at development that I can build the code app with this”
From the episode
OpenAI Codex lead on the new shape of product work
Andrew Ambrosino