I use Codex and Claude to investigate code, work through implementation options, and prepare changes. The most useful sessions start with a specific question: where does this value come from, which component owns this state, or what would reproduce the reported behavior?
Giving an agent a clear starting point usually matters more than writing a long prompt. I include the relevant repository, the behavior I expect, and the constraints that need to hold. When those details are still unclear, the first task is to investigate them.
Ask for the path through the code
Before a change, I want to understand the path from the interface to the service and back. An agent can help find the files, follow the types, and identify the tests covering that path.
I read the important parts myself. A plausible explanation may refer to a similar component or a branch that the current application never uses. File references and a reproducible example make that easier to catch.
For unfamiliar work, I prefer a small first change that I can run and inspect. It gives me a concrete basis for deciding whether the approach makes sense.
Split work where the boundaries are clear
Parallel agents help when their tasks can be reviewed separately. One might trace an API while another checks how the client handles its errors. Two agents editing the same component create more coordination work.
I try to specify the expected output for each task: a short investigation, a proposed interface, or a change within named files. Once the pieces come back, I check how they fit together. Separate test results do not establish that the combined behavior works.
The same principle applies to tools exposed through MCP. The connection gives an agent a way to call a tool. The application still needs to control the tool’s permissions, inputs, and effects. A successful tool response also needs to be interpreted in the context of the task.
Review the behavior as well as the diff
An agent can produce a tidy patch that solves the wrong problem. I compare the result with the original request, run the relevant checks, and look at the behavior where someone will actually encounter it.
For a bug fix, a useful regression test reproduces the failure and passes with the correction. For interface work, I also check the rendered page, keyboard interaction, and a smaller screen. These checks answer questions that a successful build leaves open.
I keep changes small enough to understand and ask for another review when the consequences justify it. The time saved on searching, repetitive edits, and test setup gives me more room for that work. I still own the decision to ship the result.