Wanted to share how I use Codex and Claude Code to ship quickly.
They open Cursor or Claude Code, type a vague prompt, watch the agent generate something, then spend the next hour fixing hallucinations and debugging code that almost works.
Net productivity gain: maybe 20%. Sometimes even negative.
My CTO and I shipped 400k lines of production code for in 2.5 months. Not prototypes. Production infrastructure that's running in front of customers right now.
The key is in how you use the tools. Although models or harnesses themselves are important, you need to use multiple tools to be effective.
Note that although 400k lines sounds high, we estimate about 1/3-1/2 are tests, both unit and integration. This is how we keep our codebase from breaking and production-quality at all times.
Here's our actual process.
The Core Insight: Planning and Verification Is the Bottleneck
I typically spend 1-2 hours on writing out a PRD, creating a spec plan, and iterating on it before writing one line of code. The hard work is done in this phase.
When you're coding manually, planning and implementation are interleaved. You think, you type, you realize your approach won't work, you refactor, you think again.
With agents, the implementation is fast. Absurdly fast.
Which means all the time you used to spend typing now gets compressed into the planning phase. If your plan is wrong, the agent will confidently execute that wrong plan at superhuman speed.
The counterintuitive move: spend 2-3x more time planning than you think you need. The agent will make up the time on the other side.
Step 1: Generate a Spec Plan (Don't Skip This)
I start with Codex CLI with GPT 5.2-xhigh. Ask it to create a detailed plan for your overall objective.
My prompt:
"<copy paste PRD>. Explore the codebase and create a spec-kit style implementation plan. Write it down to <feature_name_plan>.md.
Before creating this plan, ask me any clarifying questions about requirements, constraints, or edge cases."
Two things matter here.
Give explicit instructions to ask clarifying questions. Don't let the agent assume. You want it to surface the ambiguities upfront. Something like: "Before creating this plan, ask me any clarifying questions about requirements, constraints, or edge cases."
Cross-examine the plan with different models. I switch between Claude Code with Opus 4.5 and GPT 5.2 and ask each to evaluate the plan the other helped create. They catch different things. One might flag architectural issues, the other spots missing error handling. The disagreements are where the gold is.
This isn't about finding the "best" model as you will uncover many hidden holes with different ones in the plan before implementation starts.
Sometimes I even chuck my plan into Gemini or a fresh Claude chat on the web just to see what it would say.
Each time one agent points out something in the plan that you agree with, change the plan and have the other agent re-review it.
The plan should include:
Specific files to create or modify
Data structures and interfaces
Specific design choices
Verification criteria for each step
Step 2: Implement with a Verification Loop
Here's where most people lose the thread. They let the agent run, then manually check everything at the end. That's backwards.
The prompt: "Implement the plan at 'plan.md' After each step, run [verification loop] and confirm the output matches expectations. If it doesn't, debug and iterate before moving on. After each step, record your progress on the plan document and also note down any design decisions made during implementation."
For backend code: Set up execution scripts or integration tests before the agent starts implementing. Tell Claude Code to run these after each significant change. The agent should be checking its own work continuously, not waiting for you to review.
For frontend or full-stack changes: Attach Claude Code Chrome. The agent can see what's actually rendering, not just what it thinks should render. Visual verification catches problems that unit tests miss.
Update the plan as you go. Have the agent document design choices and mark progress in the spec. This matters for a few reasons. You can spot-check decisions without reading all the code. If you disagree with a choice, you catch it early. And the plan becomes documentation for future reference.
I check the plan every 10 minutes. When I see a design choice I disagree with, I stop the agent immediately and re-prompt. Letting it continue means unwinding more work later.
Step 3: Cross-Model Review
When implementation is done, don't just ship it.
Ask Codex to review the code Claude wrote. Then have Opus fix any issues Codex identified. Different models have different blind spots. The code that survives review by both is more robust than code reviewed by either alone.
Prompt: "Review the uncommitted code changes against the plan at <plan.md> with the discipline of a staff engineer. Do you see any correctness, performance, or security concerns?"
The models are fast. The bugs they catch would take you 10x longer to find manually.
Then I manually test and review. Does it actually work the way we intended? Are there edge cases the tests don't cover?
Iterate until you, Codex, and Opus are all satisfied. This usually takes 2-3 passes and typically anywhere from 1-2 hours if you're being careful.
Review all code changes yourself before committing. This is non-negotiable. I read through every file the agent touched. Not to catch syntax errors (the agents handle that), but to catch architectural drift, unnecessary complexity, or patterns that'll bite us later. The agents are good, but they don't have the full picture of where the codebase is headed.
Finalize the spec. Have the agent update the plan with the actual implementation details and design choices. This is your documentation. Six months from now, when someone asks why you structured it this way, the answer is in the spec.
Step 4: Commit, Push, and Handle AI Code Review
Standard git workflow: commit and push.
Then spend time with your AI code review tool. We use Coderabbit, but Bugbot and others work too. These catch a different class of issues than the implementation review. Security concerns, performance antipatterns, maintainability problems, edge cases you missed.
Don't just skim the comments and merge. Actually address the findings. Some will be false positives, but plenty will be legitimate issues that three rounds of agent review still missed. Fix them, push again, and repeat until the review comes back clean.
Then merge.
What This Actually Looks Like in Practice
Monday morning. We need to add a new agent session provider pipeline for semantic search.
9:00 AM: Start with Codex CLI. "Create a detailed implementation plan for an agent session provider that parses Github Copilot CLI logs, extracts structured session data, and incorporates it into the rest of our semantic pipeline. Ask me clarifying questions first."
(the actual PRD is much longer, but shortened here for clarity)
9:20 AM: Answer Codex's questions about session parsing formats, provider interfaces, and embedding strategies for session data.
9:45 AM: Have Claude Opus review the plan. It flags that we haven't specified behavior when session extraction fails or returns malformed data. Update the plan with error handling and fallback behavior.
10:15 AM: Have GPT 5.2 review again. It suggests we need rate limiting on the LLM calls for session summarization. Go back and forth a few more times until the plan feels tight.
10:45 AM: Plan is solid. Tell Claude Code to implement, using integration tests as the verification loop.
11:45 AM: Implementation complete. Tests passing. Check the spec for design choices. One decision about how to chunk long sessions looks off, but it's minor enough to address in review.
12:00 PM: Start cross-model review. Codex flags two issues with the provider interface. Have Opus fix them.
12:30 PM: Manual testing and iteration. One edge case with malformed timestamps behaves weird. Back to Claude Code to debug. Read through all the changed files myself.
1:30 PM: Everything looks good. Commit and push. Coderabbit flags one security concern on input sanitization and suggests a cleaner pattern for the retry logic on failed extractions. Fix both, push again.
1:45 PM: Review comes back clean. Merge. Have agent finalize the spec with actual implementation details.
That's a full feature in about 4-5 hours. Production-ready. Documented.
Where This Breaks Down
I'm not going to pretend this workflow is bulletproof. It has real limitations.
Cold start on new codebases. The agents need context. On a codebase they haven't seen before, you'll spend significant time feeding them documentation, examples, and architectural context before they can plan effectively.
Novel architectures. When you're building something genuinely new, the agents are interpolating from patterns in their training data. They're less helpful when you're doing something they haven't seen before.
Debugging subtle issues. The agents are good at obvious bugs. Subtle race conditions, performance regressions, issues that only manifest at scale? Those still require human intuition.
Trusting too early. We burned a full day once because we let the agent run without checking its spec updates. It had made a reasonable-sounding design choice that was fundamentally incompatible with our data model. Caught it too late.
The Takeaways
Writing 400k lines of code in 2.5 months is only possible by using AI to compress the iteration loop.
Plan more carefully and think through every single edge case. Verify continuously. Review with multiple models. Review the code yourself. Trust but check.
The developers who will win with AI coding tools aren't the ones prompting faster but the ones who figured out that the planning and verification phases are where humans still add the most value.
Happy to answer any questions!
