Write Your First Codex Request Like This: Practical Coding Prompt Examples

Summary: “Make this input produce this result” establishes clearer work criteria than “make it good however you think best.” Include the problem and verification method in your first request.

1. Define the Completed Experience Before Requesting

Before delegating code work, describe in one sentence what users should be able to do on which screen. “Improve search” is a direction; “show guidance instead of a blank screen when no search results exist” is checkable behavior. The latter lets you compare results after editing.

OpenAI's Codex prompting guide also emphasizes desired behavior, relevant code or reproduction steps, preserved conditions, and validation methods. These self-created examples apply that principle to fictional blog search. Focus on information affecting the result rather than filling every field formally.

2. Briefly Provide Four Types of Information

Problem: Describe the inconvenience and when it occurs. Location: Identify the relevant screen or file. Conditions: Specify features that must not change. Validation: State what checks establish completion. These four are often sufficient to start a small task.

“Mobile search is strange” does not identify whether the issue is input size, speed, or result display. Describe observations, such as “At phone width, the search button wraps and overlaps the input.” If unsure of the cause, do not insist it is CSS. Separating symptoms from suspected causes allows investigation.

3. A First Request You Can Copy and Adapt

블로그 검색 화면에서 결과가 0개일 때 안내가 없습니다.
검색어가 입력되어 있고 결과가 없으면
'검색 결과가 없습니다. 다른 검색어를 입력해 보세요.'를 보여 주세요.
검색어가 비어 있으면 기존 화면을 유지해 주세요.
대상은 src/search 폴더이며, API 응답 형식은 바꾸지 마세요.
기존 테스트 방식에 맞춰 필요한 검증을 수행해 주세요.
완료 후 변경 파일, 확인한 동작, 실행 명령과 결과를 알려 주세요.
직접 확인하지 못한 사항은 별도로 표시해 주세요.

The important point is distinguishing an empty query from zero results, not guidance length. Missing that condition may display “no results” immediately on opening the page. Including one or two boundary cases communicates intent more precisely.

4. Give Only Observed Differences in Follow-Up Requests

When the first result differs from expectations, describe the difference rather than pasting the whole original request again. “The no-results message briefly appears while searching. Hide it during loading and show it only after the response completes” provides a clear criterion for the next edit.

Mention your own file edits too: “I changed the guidance text. Preserve it and change only display conditions.” Base the request on actual current files rather than an earlier conversational design. After editing, also check that browser cache or running-server state is not showing an old screen.

5. Checklist When Work Goes Off Track

• Has scope grown? Request reasons for edited files outside the search screen.
• Are execution and suggestions mixed? Ask to separate commands actually run from execution instructions.
• Was the environment a blocker? Identify required tools, inaccessible paths, or failed installation stages.
• Are success criteria vague? Define comparison cases such as normal search, zero results, and loading.

Do not immediately conclude code is wrong when permissions prevent commands. Conversely, command execution alone does not validate desired behavior. The answer should reveal which cases were checked and what remains. If judging results is difficult, ask how each change addresses a condition in the original request.

6. Request Search Behavior Using a State Table

Explaining only normal results omits important interface states. Initial opening, typing, waiting for a response, no results, and server failure differ. Even adding “no search results” needs these distinctions to reduce incorrect messages during loading. The table below gives fictional blog requirements; adapt it to actual product policy.

State	Display	Result to avoid
Before searching	Existing guidance screen	Showing no results immediately
Request in progress	Existing loading indicator	Empty-result guidance appears first
Success with results	Search-results list	Mixing old and new results
Success with zero results	No-results guidance	Displaying it like an error
Request failed	Failure guidance and retry method	Mistaken for a normal empty result

After making the table, decide only unclear cells. For whitespace-only queries, choose whether to send no request or retain previous results. Search-on-type differs from requiring the search button. Specify preservation of existing behavior if established. A user-perspective state table communicates behavior precisely without prescribing implementation code.

7. Structure Small and Large Requests Differently

A Small Request Suitable for Immediate Implementation

검색 결과 없음 안내를 구현해 주세요.
완료된 응답이 성공이고 결과 배열이 비었을 때만 표시합니다.
요청 중·요청 실패·아직 검색하지 않은 상태에서는 표시하지 않습니다.
기존 로딩과 오류 안내, API 형식, 검색 실행 시점은 유지하세요.
프로젝트의 기존 스타일과 테스트 도구를 사용하세요.
새 라이브러리 추가가 필요한지 먼저 현재 코드에서 판단하세요.
변경 내용과 상태별 검증 근거를 정리해 주세요.

This separates desired actions from preserved conditions. A strict “do not use a new library” alone may force unsuitable implementation where existing code cannot solve the problem. Ask whether the current structure can support it and explain why unnecessary dependencies should be avoided. Prioritize important product outcomes over prescribing every implementation choice.

Start with Investigation When Choices Remain

검색어 자동 완성 기능을 추가하려고 합니다.
현재 검색 실행 방식, 데이터 크기, 관련 화면 구조를 조사해 주세요.
클라이언트 검색과 서버 검색 중 현재 프로젝트에 맞는 선택지를 비교하세요.
선택지마다 수정 범위, 필요한 데이터, 검증 방법을 설명하세요.
사용자 입력 전송 방식이나 API 변경이 필요한 결정은 분명히 표시하세요.
아직 구현하지 말고 현재 자료로 판단할 수 없는 조건을 남겨 주세요.

For design-variable features such as autocomplete, starting implementation without knowing data location or size may expand scope later. Review alternatives, choose a direction, then request implementation. Conversely, one wording change needs no lengthy design document. Decide on investigation by how many conditions remain undecided rather than how difficult the task sounds.

8. Four Follow-Up Requests for Incorrect Results

Send observed differences instead of expressions of dissatisfaction. Including screen, input, and action sequence makes reproduction easier. “It doesn't work” cannot distinguish saving from messaging problems, but “Immediately after pressing Search, no-results text appears, then changes to a list when the response arrives” points to display conditions.

표시 조건 보완:
검색 버튼을 누른 직후 빈 결과 문구가 먼저 나타납니다.
요청 중에는 기존 로딩만 보이도록 표시 조건을 조정하세요.
이미 바뀐 안내 문구와 정상 결과 목록은 유지하세요.

범위 보완:
검색 화면 수정 외에 공통 레이아웃도 바뀌었습니다.
공통 변경이 이번 요구사항에 필요한 이유를 설명하세요.
필요하지 않은 변경만 분리해 되돌리는 방안을 제시하세요.
다른 사람이 만든 변경은 보존하세요.

검증 보완:
테스트 통과라고 보고했지만 실행 명령이 없습니다.
실제로 실행한 명령과 결과를 알려 주세요.
실행하지 않았다면 미실행으로 정정하고 가능한 검증을 수행하세요.

현재 파일 보완:
안내 문구는 제가 방금 수정했습니다.
현재 파일의 문구를 기준으로 표시 조건만 보완하세요.
이전 답변의 문구로 덮어쓰지 마세요.

Each follow-up should address one difference. Asking again for wording, states, design, and data formats simultaneously makes earlier mistakes hard to trace. Resolve behavior first, then delegate wording and layout separately if useful. For reversions, distinguish unrelated changes instead of restoring entire files so current work is preserved.

9. Read the Completion Report and Choose the Next Action

A good report connects requirements to evidence. “Three files edited” alone does not show whether the pre-search state remains. Request a summary connecting each state with code and validation. Copying the following format helps distinguish performed from remaining work.

결과를 다음 표 형식으로 정리해 주세요.
요구사항 | 대응 파일 또는 로직 | 실제 확인한 근거 | 남은 확인
검색 전 화면 유지
요청 중 빈 결과 문구 숨김
성공 응답의 결과 0개 안내
요청 실패 시 기존 오류 안내 유지
정상 검색 결과 유지
검증 명령은 실제 실행한 것만 적고, 실패와 미실행을 구분하세요.

If an actual command fails, use the log's first cause to choose the next request. “Command not found” concerns tools or environment; “expected text differs from actual text” may concern behavior or test expectations. Do not treat both as one generic test failure. If diffs are difficult to read, ask for plain sentences and sample inputs explaining each changed condition.

Interface features may need automated checks and direct use together. Open the page, inspect the pre-search state, and enter queries with and without results in turn. Check request-failure states using project-provided tests or development mock responses. Arbitrarily changing live network conditions or production data need not be the default procedure.

Finally, carry forward only new facts learned in this task. Once related paths and commands are known, long background need not be repeated. Do not turn every task condition into a permanent rule. Put recurring project agreements in AGENTS.md and feature requirements in requests or work records to keep prompts concise.

10. Frequently Asked Questions

Do prompts need to be long? Information affecting results matters more than length. Begin small edits in a few sentences and add context through follow-ups.

Must I specify every file? Provide known related locations first. If the file is unknown, give the screen name and reproduction steps and ask for investigation.

Should I always request a plan first? Plans help with broad changes or design choices. Simple wording edits need no long plan. However, always clarify whether you want explanation or actual editing.

Official Sources and Date Checked: OpenAI official documentation: Prompting. Checked October 3, 2026. Adapt example paths and commands to your project.