Over the past few weeks, I've been using Codex to build "an app a day". Here are some of the things I've learned and observed along the way:
I really, really trust Codex. Like, dangerously.
When Codex makes changes to my apps, I trust that it has done what it said it would. And then I push those changes. For minor fixes, I don't even test locally before pushing and merging. My apps are low-risk as I'm just building things for the sake of learning and enjoyment, but this is such a dramatic shift from when I was using Cursor a few months ago.
In Cursor, I would review and accept/deny all changes. I wanted to know what the code was doing because I didn't trust it. With Codex, I feel like I have a hungry developer that's anxious to please.
Codex is excellent at maintaining focus.
Up until now, all of the applications I've used (Cursor with various models, ChatGPT copy/paste) would eventually get confused over long context windows. With Codex, I literally have one chat going for the complete development of my app.
I have found that if I ask it to do several complex things in one prompt, it conveniently leaves out a couple, but that takes me to my next tip...
Use queues to get the best quality.
While Codex is building, you can queue up the next request so that it continues where it left off. This can be very useful if there is a list of things that you'd like to get done.
Ask it to plan before building.
Codex is remarkably detailed at planning. What I've started to do is ask it to create plans and leave them in a .md file. It'll create the plan, I'll go in and review/edit the plan and then I'll ask Codex to execute against the plan.
Do a deep dive review of site architecture and performance and save it to backlog.md so that we can create plans to improve it in the next sprint.
This is where we use a couple of the other tips I mentioned. When asking it to plan, you can ask it to do so in a way where it gives you sprint plan for doing work in small increments. You then take those small increments and queue them up so that it run through the plan one "user story" at a time.
I kicked off this plan last night before I went to bed (it had 7 tracks). I came back this morning to a fully refactored backend with significantly improved performance and cost.
I queued up two additional prompts to execute after the proposed improvement tracks:
Perform another deepdive into application architecture and add to architecture.md.
Implemented all P0 improvements from architecture.md (Phase 1 list).
This gave it a path to checking it's work, and it did that very well.
Vibe-coding is dead.
Every day I use Codex, I am blown away with how impressive it is. One of the things I did today was to ask it to build and end to end test plan using Playwright for my application. I set it to high thinking mode for this task. It took a good 10 minutes and came up with a full testing strategy and then implemented it. Now, all code updates get tested against the critical testing path for compliance, and if/when they fail, Codex reworks them until they pass:
We've gone from vibe-coding to quality end to end applications in a matter of months.
If you're interested in the actual app I'm building (it's a smart family tree social network), sign up for my newsletter to know when it goes live.
-