Welcome back! In the previous lesson, you learned how to use the Codex interface to help with your coding tasks. Now, let’s focus on how to make local code changes efficiently using Codex.
When you want Codex to update your code, the way you write your prompt is very important. Clear and specific prompts help Codex understand exactly what you want, which leads to faster and more accurate results. If your description is vague, you will make Codex "think" for 5-10 minutes or more. In this lesson, you will see how to guide Codex step by step for backend and frontend changes in a Django project.
Let’s start with a backend example. Imagine you have a Django project with a Task model, and you want to add a new field called created_at to track when each task was created.
If you just say:
The Codex will take a long time to think whenever it is required to find something in the file's structure.
To avoid this, you should be specific about the following things in your prompt:
- The file to change
- The locations of files with required context OR the context itself
- Specifically ask not to double-check your context if you are sure it is correct
Let’s build a better prompt step by step.
Step 1: Specify the file and model
Start by telling Codex exactly where to make the change:
This tells Codex the file (core/models.py) and the model (Task) to update.
Step 2: Describe the field
You can add more detail about the field type. For example, if you want a timestamp:
Step 3: Request follow-up actions
After changing a Django model, you need to make migrations. You can include this in your prompt:
This is a clear, complete prompt. Codex now knows exactly what to do: open the right file, update the right model, and run the necessary commands to apply the change.
By being specific, you help Codex:
- Find the right place in your code
- Make the correct change
- Handle any required follow-up steps
There is a natural question: if I already know what to change, why do I even need to use Codex?
- Sometimes you might not remember the exact syntax, and Codex can make adjustments faster than if you were to search for the correct syntax.
- Changes can be much more complex in an actual project than in this example. In such cases, Codex might be extremely helpful
Another question is: What if I don't know the location of the changes? Just ask Codex! You can start by asking a general question, like this:
And then proceed to a specific request. It is a common prompt engineering approach.
Now, let’s look at a frontend example. Suppose you want to show the creation date of each task in your task list template. You also want the date to appear in a lightweight gray font under the task’s name.
If you just say:
Codex might not know which template to update, where to put the date, or how it should look.
Let’s build a better prompt step by step.
Step 1: Specify the template file
Tell Codex which file to edit:
Step 2: Describe the placement
Say where the date should appear:
Step 3: Describe the style
Add details about how it should look:
You make it much more likely that Codex will get it right the first time.
Step 4: Solving the "Long Thinking" problem
Make the context clearer, so Codex doesn't go into project structure exploration:
To sum up, when you want Codex to make local code changes, always be clear and specific. Tell Codex:
- Which file to edit
- What to change or add
- How the change should look or behave
- Any follow-up steps needed
This approach helps Codex work faster and with fewer mistakes.
Now, you’ll get a chance to practice writing your own prompts for local code updates. Try to be as clear and detailed as possible, just like in the examples above. Good luck!
