Learning path · 5 steps
Make a code change with an assistant
If you have a bug to fix or an unfamiliar function to change, you already have a useful reason to try a coding assistant. This path follows that job from understanding the code to checking the edit. Codex, Claude Code and Pi can all take part; the important comparison is whether the assistant makes the work easier to understand and finish.
In this guide 6 sections
Use a project you’re allowed to work on, and keep the first change easy to undo. Check what the tool proposes before applying it, and don’t send private data you aren’t allowed to share.
Start with the access you already have
Choose an assistant that fits the project’s data requirements, your operating system and the account available to you. Codex and Claude Code are straightforward candidates when you already use the corresponding service. Pi is worth a look when provider choice or customization is part of the requirement. You do not need to install all three to learn whether this way of working helps.
Give the change a clear starting point
Use a disposable branch in a project whose tests run, save the starting revision and keep credentials or disallowed files out of the material the service can process. Inspect the assistant’s file and command permissions before asking it to work. These steps make it possible to see what changed, reproduce the checks and discard the edit cleanly if needed.
Ask about the behavior you want to change
Describe the bug or intended behavior and name the part of the project involved. Ask the assistant to follow it through the source and tests, explaining what each relevant check covers. Read the cited files alongside the answer. If the explanation skips a step or contradicts the code, resolve that question before asking for an implementation.
Work out how the test will distinguish the two behaviors
A useful test should separate the behavior you have from the behavior you want. Ask the assistant to explain the input and expected result, then add or adapt the test once the explanation makes sense. For a bug fix, reproduce the failure before applying the fix where practical. Review the entire diff and rerun the relevant checks so unrelated edits do not slip through.
Decide whether the help was worth it
Keep the change when you understand it and can reproduce the result. Also consider the work around it: did the assistant find the relevant code sooner, explain something you had missed or leave you untangling its assumptions? That answer suggests the next use. You may want help with another change, a narrower question or better project instructions rather than more automation.
Tool guides for this path
An illustrative workflow based on the linked tool documentation. It has not been run as a product test or benchmark.
Browse all learning paths