Writing Clear Codex Prompts

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 an Express project.

Let's start with a backend example. Imagine you have an Express project with a TypeScript interface for Task, and you want to add a new property called createdAt to track when each task was created.

If you just say:

Add createdAt field to tasks

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 interface

Start by telling Codex exactly where to make the change:

In src/types/task.ts, add a createdAt property to the Task interface

This tells Codex the file (src/types/task.ts) and the interface (Task) to update.

Step 2: Describe the property type

You can add more detail about the property type. For example, if you want a timestamp:

In src/types/task.ts, add a string property called createdAt to the Task interface to store ISO timestamp strings

Step 3: Request follow-up actions

After changing a TypeScript interface, you might need to update the data store functions that create tasks. You can include this in your prompt:

In src/types/task.ts add createdAt property of type string to the Task interface, and update the createTask function in src/data/tasksStore.ts to set createdAt to new Date().toISOString() when creating new tasks

This is a clear, complete prompt. Codex now knows exactly what to do: open the right files, update the right interface, and modify the data store function to handle the new property.

By being specific, you help Codex:

• Find the right place in your code.
• Make the correct change.
• Handle any required follow-up steps.

You might be wondering: "These specific prompts are great, but what if I don't know where things are in an unfamiliar project?"

This is where the exploration techniques from Unit 1 become essential. Before you can write highly specific modification prompts, you need to understand the project structure. Here's the recommended workflow:

Step 1: Explore First (Unit 1 Techniques)

When working with an unfamiliar codebase, start by using exploratory questions to build your mental map:

Explain the project structure of this Express TypeScript application. Where are the data models defined? Where are the API routes and controllers located?

Or ask specific discovery questions:

If I want to add a new field to my Task model in this project, which files would I need to modify? List the file paths and explain what each file does.

Step 2: Modify with Precision (Unit 2 Techniques)

Once you know the file locations and project structure, use the specific prompting techniques from this lesson:

In src/types/task.ts add createdAt property of type string to the Task interface, and update the createTask function in src/data/tasksStore.ts to set createdAt to new Date().toISOString()

Why This Two-Step Approach Works

1. Exploration prevents wasted time: Without understanding the project structure, you might give Codex incomplete or incorrect file paths, forcing it to search the entire codebase.
2. Specificity speeds up execution: Once you know where things are, specific prompts help Codex work 5-10x faster by avoiding unnecessary exploration.
3. You build project knowledge: The exploration phase helps you understand why files are organized the way they are, making you more effective on future tasks.

When to Use Each Approach

• First time in a project or new area? → Start with Unit 1 exploration techniques
• Already familiar with the structure? → Jump directly to Unit 2 specific modification prompts
• Unsure if you know enough? → Ask a quick discovery question first, then proceed with specific modifications

Now, let's look at a frontend example. Suppose you want to show the creation date of each task in your task list view. You also want the date to appear in a lightweight gray font below the task's title.

If you just say:

Show createdAt in the view

Codex might not know which file 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 view file

Tell Codex which file to edit:

In public/index.html, show the createdAt field for each task

Step 2: Describe the placement

Say where the date should appear:

In public/index.html, in the renderTasks function, display the createdAt field below the task title

Step 3: Describe the style

Add details about how it should look:

In public/index.html, in the renderTasks function, add a date display below the task title showing the createdAt field in a lightweight gray font

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:

In public/index.html, in the renderTasks JavaScript function, add code after the titleSpan to display task.createdAt in a lightweight gray font below the task name. The createdAt field is a string containing an ISO timestamp. Don't validate this before making changes.

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!