Skip to content

How to Plan Before Using Codex CLI for Coding

Developer planning before coding

Problem

When I first tried Codex CLI, I gave it a brief prompt and expected production-ready code. But what happened was frustrating - I spent a whole week fixing and adjusting the generated code.

The pattern looked like this:

  • 1 hour planning
  • 3 hours “coding” with Codex
  • 1 week (40+ hours) fixing and adjusting

I was treating Codex as a magic solution instead of an accelerator for well-planned work.

What happened?

I jumped straight into implementation without clear specifications. Codex invented solutions on-the-fly, and I ended up with:

  1. Inconsistent architecture choices (different auth patterns in different files)
  2. Technical debt accumulating rapidly
  3. Multiple revision cycles consuming my token budget
  4. Growing frustration with AI tools

Here’s what my vague prompt looked like:

My original prompt
Build me a user management system with authentication

Codex generated something, but it didn’t match what I actually needed. The auth system used sessions while I wanted JWT. The database schema was missing fields I care about. Each “fix” created more problems.

How to solve it?

I changed my workflow after reading tips from experienced Codex users. Now I spend significant time planning BEFORE invoking Codex.

Step 1: External Specification Development

Instead of rushing to Codex, I develop specs outside first. For complex problems, I use ChatGPT with Deep Research to:

  • Explore architectural patterns
  • Research best practices for my domain
  • Identify potential pitfalls
  • Gather reference implementations

Step 2: Tech Stack Pre-Decisions

I explicitly define my tech choices before coding:

Tech Stack Decision Document
Framework: Next.js 14 (App Router)
Database: PostgreSQL with Prisma ORM
Auth: NextAuth.js
Styling: Tailwind CSS + shadcn/ui
State: Zustand for client state

This prevents Codex from inventing choices I don’t want.

Step 3: Detailed Specifications

Now my prompts include actual specs:

Better prompt with specs
Build a product catalog page using these specifications:
Tech Stack: Next.js 14, Tailwind CSS, Prisma
Components to create:
1. ProductCard - card with product image, name, price, add to cart button
2. ProductGrid - responsive grid (3 cols desktop, 2 tablet, 1 mobile)
3. FilterSidebar - filters for category, price range
Data model: Product has id, name, description, price, category, images[]
API endpoints:
- GET /api/products returns { products: Product[], total: number }
Use shadcn/ui components.
Include loading states and error boundaries.

The New Time Ratio

After adopting this workflow:

Time comparison
Approach A (minimal planning):
- Planning: 1 hour
- Coding: 3 hours
- Fixing: 1 week (40+ hours)
- Total: ~44 hours
Approach B (thorough planning):
- Planning: 2 days (16 hours)
- Coding: 5 hours
- Fixing: minimal (2-4 hours)
- Total: ~23-25 hours

That’s nearly 50% time savings.

The reason

I think the key reason is that AI performs best as an executor of well-defined plans, not as an architect making decisions.

When I skip planning:

  • Codex guesses at fundamental choices
  • Each guess might be wrong
  • Wrong foundations compound into bigger problems
  • Fixing foundation requires rewriting dependent code

When I plan thoroughly:

  • Codex implements against clear specifications
  • Implementation matches my actual requirements
  • Fewer revisions needed
  • Consistent architecture throughout

Common mistakes to avoid

1. Letting AI choose your architecture

Don’t accept what Codex invents. Pre-decide your auth system, database, framework.

2. Writing vague specifications

“Build a user dashboard” is too vague. Include specific UI elements, data sources, interactions.

3. Not using research tools

For complex problems, use ChatGPT Deep Research before coding. Don’t reinvent wheels.

4. Treating all planning equally

Focus planning on: data flow, integrations, edge cases. These have the biggest impact on code quality.

Summary

In this post, I showed how planning before using Codex CLI transformed my workflow. The key point is that upfront investment in specifications and tech stack decisions saves hours of frustrating fixes later.

Try this on your next project: spend time outlining specifications before opening Codex CLI. Two days of planning plus five hours of coding beats one hour of planning plus a week of fixing.

Final Words + More Resources

My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me

Here are also the most important links from this article along with some further resources that will help you in this scope:

Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!

Comments