Operating note
Notes on Using Gemini 3 and GPT-5-Codex
An archived account of choosing between a responsive editing loop and a more deliberate pass through repository context.
Historical workflow note. First published 19 November 2025 and edited in August and September 2026. The revisions are not a new model evaluation.
When I tried Gemini 3 alongside GPT-5-Codex, I was looking for a useful place for each in my work. Codex had been my default for changes that needed repository context. Gemini’s responsiveness made me interested in using it for shorter editing loops.
My notes describe preferences. I did not preserve comparable task runs, timings, exact model versions, or settings, so they cannot establish which model performed better. The distinction worth keeping is what I wanted from each interaction.
Two kinds of work
| Work I was doing | What I valued | My preference in these notes |
|---|---|---|
| Copy edits, small component changes, and exploring options | A quick response that I could inspect and correct immediately | Gemini 3 |
| Refactors and changes involving several files or conventions | An initial pass that kept the constraints together | GPT-5-Codex |
Gemini felt useful when I could keep each request short and judge the result myself. For a component change, I might ask for three possible ways to remove repeated copy, choose one, and then request the edit. The value was being able to steer each step while the surrounding code stayed in view.
Codex felt steadier when I needed the tool to read callers, understand a module’s responsibility, and make a coherent change across files. I sometimes waited longer for useful output, but preferred the shape of the result for that work.
“Felt steadier” is a description of that experience. Without saved runs, I cannot separate the model’s contribution from the prompts, available context, interface, or tasks I gave it.
The choice was partly about my role
For a small edit, I was actively following the implementation. I could spot a poor suggestion, reject it, and keep moving.
For a change spread across a repository, I was delegating more of the investigation. I needed the result to explain which files mattered, what behaviour had to stay the same, and what had been checked. A fast answer without that account could create more work for me.
That is the question I would carry into a future comparison: how much effort does it take to reach a change I can understand and accept?
To answer it, I would save the task, tool and model versions, instructions, final diff, corrections, and check results. I would also distinguish time spent waiting from time spent reviewing. That would turn a preference into something another person could inspect.
These notes helped me describe two ways of working. They do not support a current model ranking. For a more concrete example of evaluating a large AI-assisted change, read The Velocity Paradox.
Revised 5 September 2026: reframed the comparison as a historical operating note, made the missing evaluation details explicit, and removed present-tense model recommendations.