Claude as planner, Codex as executor: how I doubled my productivity in Android dev with agents

Before AI agents, I did all of my AI coding in chat windows. I would ask questions, paste in code and patches, review the result, and then copy it back to our code repository. While this was sometimes useful for debugging problems or learning about APIs, the AIs would often hallucinate and make beginner-level mistakes, and copy/pasting the code back and forth added a lot of friction.

Like many others, I first started experimenting with Claude Code over the holiday break. It was almost addictive: I could just feed in a spec to my agent, and then watch it spin away. I quickly burned through tokens as I gave it task after task. However, I didn’t end up merging most of this work as it was experimental, not fully reviewed or implemented with the best UI, and I just wanted to see what the agents were capable of.

It’s now a few months later, and we’re now making much more extensive use of agents in production. The releases of Opus 4.7, 4.8, and GPT 5.5 have increased our productivity even further by making fewer mistakes and requiring less hand-holding from us during design and code review.

One risk of using agents is that the busywork of chatting with them in the terminal can sometimes feel more productive than it really is¹. I’ve run into this situation a few times, myself: I’ve spent a few hours-long sessions going back-and-forth with an agent to implement something that I probably could have done faster with a script or by coding it myself.

Our gains in productivity

I decided to compare my velocity in 2026 to what I was shipping in 2025. In 2025, I spent much of my time working on a large refactor of Easy Voice Recorder from a legacy Java codebase with XML views and fragments toward a Compose-based UI written in Kotlin. This means that a significant amount of my commits in 2025 contained a lot of churn simply from converting Java code to Kotlin, or refactoring code to be organized in a different way.

In spite of this, the results are clear: I’m now writing more than twice as much code in 2026 as I was in 2025 (by lines of code changed). From a PR perspective, my velocity is more than five times as much. If I looked at PRs alone, that would probably overstate it, but if I look at our cadence of new feature releases, I can comfortably say that my productivity has more than doubled.

I’ve always loved coding and software development, but even a career that you have passion for can have its down days and rough patches. AI agents have brought back a certain level of joy for me. I genuinely enjoy being able to plan out new features and architect solutions, while having the agents deal with more of the plumbing and execution. As others have attested to, this can be addicting, and sometimes it also needs a lot of concentration to manage well. I find I’m personally most adept at doing this in the mornings (with some coffee, of course).

Here’s how we use these agents in production:

Planning and execution

As of right now, I get the best use from Claude Code and Codex when I use Claude Code as the planner, and Codex as the executor:

1. First, I’ll discuss the problem and the requirements with Claude, and go back and forth until we have a reasonably solid-looking plan with /plan mode.
2. I’ll then ask Codex to review the plan and point out any flaws or other issues that Claude may have missed. I’ll do this by pasting in the file path that Claude provides, instead of pasting in the actual plan, so I can just ask Codex to re-read the plan instead of copy/pasting in the changes over and over.
3. I’ll feed in Codex’s output back to Claude, and repeat these steps over a few iterations.
4. Once we’re ready to execute, I’ll have Codex execute the actual plan and wait for the plan to complete. /goal can be used in conjunction with a plan when the plan has a defined, measurable outcome, such as performance optimization or benchmarking work.
5. At the end, I’ll ask the agents to do a code review. There’s value to doing the code review both with the plan context and in new, separate instances with clean contexts, so I’ll do both.

I find that Claude has better design taste and judgement in following what you want, while Codex is more detail-oriented and will find flaws that Claude may have overlooked. I’ll also manually review the plan and Codex’s suggestions to ensure that we don’t go down the wrong path or land too far into nitpicking territory.

The past month or two have seen an extreme increase in demand for Anthropic’s models, with the result being that Claude is sometimes demand-limited or saturated. With that in mind, it’s even more valuable to do the planning with Claude, while taking advantage of Codex’s much faster turnaround times for reviewing and executing the plan.

Improving code quality with skills

Skills can greatly improve agent performance with domain-specific knowledge². In EVR, we created a couple of skills that help us with Compose development. For our Compose state patterns skill, we started with the official developer docs as well as blog posts by engineers on the Compose team. We then refined these by having Codex point out the flaws and iterating back and forth between Claude Code and Codex. For our TalkBack skill, we also added evals to double-check that the skill is triggering in the way that we expect. The agent itself can help you write these evals and structure them in the right way³.

A skill can also include a reference to a Python script when you need deterministic logic. We do this for various localization checks. This increases reliability and also saves on tokens by running deterministic code, rather than having the agent interpret the data subjectively.

Sandboxing and permissions

Codex runs with sandboxing on by default⁴. Claude Code also has the ability to enable sandboxing, and it can be done with either regular permissions or “auto-allow” permissions⁵. I personally prefer not to grant overly permissive permissions or to use auto-allow; there have been rare, but real reports of the agents deleting important data⁶.

I find that Codex is better at dealing with permissions prompts. Claude Code with regular permissions can be very painful; you’ll be asked over and over for things like “command-line substitutions” or for slight variations on a command. I’m not sure where the specific difference lies, but Codex feels so much more ergonomic here: I only get prompted for commands like adb or gradle, and I can approve the general command rather than one exact invocation of it.

It’s possible to use auto-allow or to manually edit the permissions config, but this is an area where I prefer to not have to mess around with the configuration too much. OpenAI and Anthropic themselves don’t recommend granting overly permissive permissions unless you use exterior isolation of some kind (such as: Docker, a VM, a dev container, or something else).

Additional best practices

Context:

• One of the biggest strengths of Claude Code and Codex is that you can liberally fork conversations, send new messages while the agent is working on something, and easily backtrack to earlier points in a conversation.
• /btw can be used to ask side questions without injecting them into the context.
• Both agents defer many tasks to subagents, so that the main agent only gets the results, saving on context. You can also ask them to explicitly do this when you need to work through a lot of data, and that data doesn’t all need to be in the main context.
• New tasks should always be done with a clear, fresh context. If the agent is going off-track, you can also backtrack to an earlier point in the conversation and try again, rather than correcting it over and over.⁷
• I’ve wasted a LOT of tokens by trying to do more than one task at the same time, in the same session. Claude Code will only delegate things so far, so a lot of tokens might end up being used on expensive models running in parallel, rather than by subagents. As of right now, I get much better results by orchestrating parallel work in completely different sessions.

Sharing data between Claude Code and Codex:

• I started off by having a separate CLAUDE.md and AGENTS.md and having each agent decide how to initialize each one, but it turns out that you can just use a symlink, or you can set the contents of CLAUDE.md to: @AGENTS.md.
• You can also symlink skills in the same way by symlinking the specific skill folder. For example: .agents/skills/compose-state-patterns can be symlinked to .claude/skills/compose-state-patterns, and then both Claude Code and Codex will be able to automatically load and use the same skill.

Drafting up documents, bug reports, and feature requests:

• When drafting up a bug report or feature request for Trello, I find it very helpful to paste in all of the context from Slack, customer and bug reports, Crashlytics and so on, and have the LLMs distill this into actionable feedback for a dev or QA. The LLMs tend to be verbose, so I ask them to make a “TL;DR” or I sometimes rewrite it myself.
• The agents can prepare handoff documents that allow important context to be preserved between sessions. This is most valuable when working on a larger feature that requires several agent passes to implement. Another great use is saving investigation and benchmark data when evaluating performance regressions, memory leaks, and other issues like this.
• While I used agents to help me design this website, I don’t currently use LLMs for directly writing prose or content, and I don’t use them to directly communicate with the team other than through bug reports or feature drafts as mentioned above. As AI content becomes more commonplace, the human voice, for all of its foibles and inconsistencies, becomes more unique.

Where are we going from here?

I find that I’m starting to become part of the agent feedback loop, myself. It’s becoming more interesting and rewarding than playing video games (for example), and I’m always looking for the next feature to work on or bug to fix.

Where are we going from here? At what point do the agents take on more and more of the workload, and we become simply the reviewer or the point of authority that gives the final OK? We’re a small team, and if anything, I need the humans on my team more than ever. Agents are helping us to execute faster, and we are the ones that are becoming the bottleneck. Someone needs to be in the loop to express judgement, taste, and refinement, and agents allow us to spend more of our time on that. Things are still moving fast, and I’m excited to see what the future brings.

Additional references and reading

This post by Vôva Ignátov covers coding agents on iOS: Coding agents for production iOS: a senior engineer’s setup for 2x the output. He also goes over a lot of topics that I didn’t mention here; I highly recommend giving it a read.

Additional reading:

• Harness engineering
• How we monitor internal coding agents for misalignment
• Subagents in Claude Code

Footnotes: