본문 바로가기
AI/Codex

What Does OpenAI Codex Do?

by Pokaa 2026. 9. 7.

한국어

PART 0 — AI Coding Agent와 Codex 이해
Course ID: 0-3

OpenAI Codex는 무엇을 하는가

Lesson Summary
OpenAI Codex가 codebase의 맥락을 확인하고, 필요한 변경을 만들고, command와 test를 실행하고, 결과를 검증하는 과정을 살펴본다. 사용자가 software-development task를 위임할 때 Codex와 사람이 각각 어떤 역할을 맡는지도 이해한다.

작성일:
기술 검증일:

앞 단원에서는 AI Coding Agent가 단순히 답변하는 AI를 넘어 도구와 여러 단계를 사용해 software-development work를 수행할 수 있다는 개념을 살펴봤다. 그렇다면 OpenAI Codex는 실제 software-development task에서 무엇을 할까?

1. Codex는 단순한 code 생성기보다 넓은 역할을 한다

OpenAI Codex는 software development를 위한 coding agent다. 새 code를 작성하는 일뿐 아니라 기존 code를 살펴보고, 변경하고, 관련 도구를 실행하고, 결과를 확인하는 작업까지 이어서 도울 수 있다.

예를 들어 “버튼을 눌렀을 때 잘못된 안내 문구가 표시되는 문제를 고쳐 줘”라는 task를 맡겼다고 하자. Codex가 곧바로 임의의 code를 만들어 내는 것만으로는 충분하지 않다. 먼저 어느 파일과 로직이 관련 있는지 확인하고, 필요한 범위만 변경한 뒤, test나 check를 실행하고, 결과가 요구사항과 맞는지 살펴봐야 한다.

여기서 task는 달성해야 할 하나의 작업을 뜻한다. task는 짧은 질문일 수도 있지만, 여러 단계를 연결해야 끝나는 개발 작업일 수도 있다. Codex는 이런 task를 위임받아 처리할 수 있지만, 결과가 언제나 자동으로 정답이 되는 것은 아니다.

2. 읽기: 현재 codebase의 맥락을 확인한다

Codebase는 프로그램을 이루는 code와 관련 파일의 모음이다. Repository는 이런 파일과 변경 기록을 함께 관리하는 작업 공간을 가리키는 경우가 많다. 처음에는 두 용어를 엄격히 구분하기보다, “현재 프로그램이 들어 있는 작업 공간”으로 이해해도 충분하다.

Codex는 task와 관련된 파일, code, 폴더 구조를 살펴보며 필요한 context, 즉 작업 맥락을 파악할 수 있다. 예를 들면 다음을 확인할 수 있다.

  • 어느 파일이 요청과 관련 있는가?
  • 현재 code는 어떤 방식으로 동작하는가?
  • 이미 사용 중인 이름, 구조, 규칙은 무엇인가?
  • 변경하면 함께 영향을 받을 부분이 있는가?

모든 task에서 repository 전체를 처음부터 끝까지 읽는다는 뜻은 아니다. 좋은 작업은 요청에 필요한 범위를 찾고, 그 범위를 이해하는 데서 시작한다. 사용자의 요구와 현재 code 상태를 함께 보는 이유도 여기에 있다.

3. 수정: 필요한 범위에 집중해 변경한다

맥락을 확인한 뒤에는 새 code를 작성하거나 기존 code를 수정할 수 있다. 중요한 것은 많이 바꾸는 것이 아니라, goal을 달성하는 데 필요한 focused change, 즉 필요한 범위에 집중한 변경을 만드는 것이다.

앞의 안내 문구 문제라면 관련 문구만 고치면 될 수도 있다. 반대로 문구가 잘못 표시되는 원인이 조건 처리에 있다면 그 로직과 관련 test를 함께 수정해야 할 수도 있다. 같은 요청처럼 보여도 현재 code와 요구사항에 따라 적절한 변경 범위는 달라진다.

Codex가 파일을 변경할 수 있다는 사실과 그 변경이 반드시 옳다는 것은 서로 다르다. 빠르게 만들어진 변경도 요구사항을 놓치거나 다른 동작에 영향을 줄 수 있으므로, 다음 단계에서 실제 결과를 확인해야 한다.

4. 실행: code를 쓴 뒤 필요한 도구를 사용한다

Code를 작성하는 것과 그 code가 실제로 기대대로 동작하는지 확인하는 것은 별개의 일이다. Codex는 필요한 경우 작업 환경에서 command를 실행하고, test·lint·format·type check 같은 점검 도구를 사용할 수 있다.

모든 task에 같은 command나 test가 필요한 것은 아니다. 문서의 오탈자 수정처럼 실행할 test가 거의 없는 작업도 있고, 작은 code 변경이라도 여러 check가 필요한 작업도 있다. 무엇을 실행할지는 repository의 구성, task의 성격, 사용자의 지시에 따라 달라진다.

이 Lesson에서는 특정 command를 입력하는 법을 배우지 않는다. 핵심은 Codex가 “code를 제안하는 단계”에서 멈추지 않고, 허용된 범위에서 실제 도구를 사용해 결과를 확인하는 단계까지 이어갈 수 있다는 점이다.

5. 검증: 실행 결과와 변경 내용을 비교한다

검증(verification)은 변경이 요구사항과 맞는지 근거를 확인하는 과정이다. Codex는 다음과 같은 정보를 살펴볼 수 있다.

  • test 또는 check의 성공·실패 결과
  • command가 출력한 내용
  • 변경 전후의 차이를 보여 주는 diff
  • 예상과 다른 동작이나 오류 메시지

Test가 실패하거나 output이 예상과 다르거나 요구사항과 맞지 않는 부분이 보이면, 관련 context를 다시 확인하고 변경을 고친 뒤 필요한 check를 다시 실행할 수 있다. 이처럼 한 단계의 결과를 다음 판단에 사용하는 것이 coding agent 작업의 multi-step 성격이다.

6. 위임: 질문이 아니라 task를 맡긴다

사용자는 Codex에게 설명을 요청할 수도 있고, 작은 software-development task를 맡길 수도 있다. 이때 위임(delegate)은 판단과 책임을 모두 넘겨 버린다는 뜻이 아니다. Codex가 허용된 범위에서 작업 단계를 수행하도록 맡기고, 사용자는 목표와 경계를 정하며 결과를 확인하는 관계다.

좋은 위임에는 다음 정보가 도움이 된다.

  • Goal: 무엇을 달성해야 하는가?
  • Context: 어떤 codebase와 상황을 봐야 하는가?
  • Constraints: 무엇을 바꾸지 말아야 하고 어떤 규칙을 따라야 하는가?
  • Done criteria: 어떤 상태가 되면 작업이 끝났다고 판단하는가?

예를 들어 “오류를 고쳐 줘”보다 “로그인 실패 시 빈 화면 대신 기존 오류 message를 보여 주고, 관련 test가 통과해야 한다. 로그인 방식 자체는 바꾸지 않는다”가 task의 범위를 더 분명하게 만든다. 다만 이 Lesson의 목적은 prompt 작성 기법을 깊게 배우는 것이 아니라, 사용자가 task의 방향과 완료 기준을 제공한다는 역할을 이해하는 데 있다.

7. Codex와 사용자의 역할

단계 Codex가 맡을 수 있는 역할 사용자가 확인할 것
읽기 task와 관련된 file, code, 구조, 규칙을 살펴본다. 필요한 context와 접근 범위가 맞는가?
수정 새 code를 작성하거나 기존 code를 필요한 범위에서 바꾼다. 요구사항 밖의 변경이나 예상하지 못한 영향은 없는가?
실행 필요한 command, test, check를 허용된 범위에서 실행한다. 실행 권한과 대상이 적절한가?
검증 output, test/check 결과, diff, failure를 확인한다. 근거가 충분하며 결과를 받아들일 수 있는가?
위임 여러 단계를 연결해 task를 진행하고 review-ready result를 준비한다. goal, constraints, done criteria를 제시하고 최종 결과를 review했는가?

사용자는 instruction과 scope를 제시하고, 영향이 큰 행동에는 필요한 approval을 결정하며, 진행과 결과를 supervision하고 review한다. Codex는 허용된 작업 공간과 권한 안에서 task를 수행한다. 실행 환경과 설정에 따라 Codex가 행동 전에 승인을 요청해야 할 수도 있다.

따라서 “Codex가 task를 수행한다”와 “사용자가 판단에서 사라진다”는 같은 말이 아니다. 무엇을 맡길지, 어떤 권한을 허용할지, 결과를 받아들일지는 여전히 사람의 책임이다.

8. Agent loop: 결과를 보고 다음 단계를 정한다

이번 Lesson에서 Agent loop는 다음과 같은 교육적 workflow model을 뜻한다.

  1. Task와 관련 context를 확인한다.
  2. 필요한 change를 판단한다.
  3. Code나 file을 수정한다.
  4. 필요한 test 또는 check를 실행한다.
  5. 결과와 diff를 확인한다.
  6. 문제가 있으면 context와 change를 다시 살펴보고 correction한다.
  7. 사용자가 review할 수 있는 결과와 확인 근거를 정리한다.

이것은 Codex의 비공개 내부 reasoning을 보여 주는 설명도, 모든 task가 반드시 따르는 고정 알고리즘도 아니다. Task에 따라 일부 단계가 필요 없을 수 있고, 순서가 바뀌거나 같은 단계가 여러 번 반복될 수도 있다. 핵심은 한 번의 답변으로 끝내기보다, 현재 결과를 확인하고 필요하면 다음 행동으로 이어갈 수 있다는 점이다.

실패도 loop의 일부가 될 수 있다. Test failure, 예상과 다른 output, requirement mismatch가 발견되면 실패를 숨기거나 성공으로 단정하는 대신, 그 정보를 다음 correction의 근거로 사용해야 한다. 물론 다시 수정했다고 해서 자동으로 정답이 되는 것은 아니므로 마지막 review가 필요하다.

9. 데모에서는 무엇을 관찰할까?

이 Lesson에서는 직접 명령을 따라 치기보다, 실제 Codex가 하나의 작은 task에서 repository context 확인 → focused edit → command/test 실행 → 결과 검증으로 이어지는 화면을 관찰한다.

화면에서 볼 것은 CLI 사용법이 아니라 작업의 연결이다. Codex가 어떤 파일을 확인했는지, 무엇을 바꿨는지, 어떤 check를 실행했는지, 그리고 결과를 어떤 근거와 함께 정리했는지를 살펴본다. 아래 Screenshot 0-3-SS01에서 이 연결을 관찰한다.

승인된 인사말 변경을 확인하고 python -B check.py를 실행해 PASS 결과와 종료 코드 0을 보고한 Windows의 interactive Codex CLI 화면
Codex가 관련 파일과 승인된 변경을 확인하고 결정적 검사를 실행한 뒤 결과를 요약한 실제 runtime 화면입니다. 이 PASS는 해당 인사말 요구사항만 검증하며 일반적인 소프트웨어 정확성을 보장하지 않습니다.

10. 핵심 정리

  • OpenAI Codex는 software development를 위한 coding agent다.
  • Codex는 단순한 code 생성에 그치지 않고 task에 필요한 codebase context를 확인할 수 있다.
  • 새 code를 작성하거나 기존 code를 필요한 범위에서 수정할 수 있다.
  • 필요한 command, test, check를 실행하고 output과 diff를 바탕으로 결과를 검증할 수 있다.
  • 실패나 불일치가 발견되면 context를 다시 보고 correction을 이어갈 수 있다.
  • 사용자는 goal, context, constraints, done criteria를 제공해 task를 위임할 수 있다.
  • Test와 검증은 오류 가능성을 줄이는 과정이지 완벽함을 보장하지 않는다.
  • 사용자는 instruction, scope, approval, supervision, review에 대한 책임을 유지한다.
  • 이 Lesson의 Agent loop는 이런 여러 단계를 이해하기 위한 교육적 모델이며 고정 내부 알고리즘이 아니다.

이제 Codex가 실제 software-development workflow에서 맡을 수 있는 역할을 설명할 수 있다. 다음 Lesson에서는 Codex와 Claude Code의 공통점과 차이를 객관적인 관점에서 살펴본다.

KO Official Sources

KO Course Navigation

Previous Current Next
0-2 — 생성형 AI에서 AI Coding Agent까지 0-3 — OpenAI Codex는 무엇을 하는가 0-4 — Codex와 Claude Code의 공통점과 차이

English

PART 0 — Understanding AI Coding Agents and Codex
Course ID: 0-3

What Does OpenAI Codex Do?

Lesson Summary
This lesson explains how OpenAI Codex can inspect the context of a codebase, make the necessary changes, run commands and tests, and verify the results. It also explains the respective roles of Codex and the user when a software-development task is delegated.

Authoring date:
Technical verification date:

In the previous lesson, we learned that an AI Coding Agent can go beyond simply answering questions: it can use tools and connect multiple steps to perform software-development work. So what does OpenAI Codex actually do in a software-development task?

1. Codex has a broader role than a simple code generator

OpenAI Codex is a coding agent for software development. It can help not only by writing new code, but also by inspecting existing code, changing it, running relevant tools, and checking the results.

Suppose you delegate this task: “Fix the problem that shows the wrong message when the button is clicked.” It is not enough for Codex to immediately produce arbitrary code. It first needs to identify the relevant files and logic, make only the necessary change, run an appropriate test or check, and examine whether the result matches the requirement.

Here, a task means one piece of work to complete. A task can be a short question, but it can also be a development job that requires several connected steps. Codex can take on such a task, but its result does not automatically become correct every time.

2. Read: inspect the context of the current codebase

A codebase is the collection of code and related files that make up a program. A repository often means a workspace that manages those files together with their change history. At this stage, it is enough to understand both as concepts related to “the workspace containing the current program,” without treating them as exactly the same term.

Codex can examine files, code, and folder structure related to the task to understand the necessary context. For example, it can investigate:

  • Which files are relevant to the request?
  • How does the current code work?
  • What names, structures, and rules are already in use?
  • Which other areas could be affected by a change?

This does not mean that Codex always reads an entire repository from beginning to end for every task. Good work begins by finding the scope needed for the request and understanding that scope. This is why the user’s requirement and the current state of the code need to be considered together.

3. Modify: make a focused change within the necessary scope

After inspecting the context, Codex can write new code or modify existing code. The important point is not to change a large amount, but to make a focused change: a change limited to what is needed to achieve the goal.

For the message problem above, changing only the related text may be enough. However, if the wrong message is caused by conditional logic, that logic and its related test may need to be changed together. Even similar requests can require different scopes depending on the current code and requirements.

The fact that Codex can change files does not mean that the change is necessarily correct. A quickly produced change can miss a requirement or affect other behavior, so the actual result needs to be checked in the next step.

4. Execute: use the necessary tools after writing code

Writing code and confirming that it actually works as expected are separate activities. When needed, Codex can run commands in the working environment and use checking tools such as tests, linting, formatting, or type checks.

Not every task needs the same command or test. A documentation typo may require almost no executable test, while a small code change may require several checks. What to run depends on the repository setup, the nature of the task, and the user’s instructions.

This lesson does not teach the syntax of a specific command. The key point is that Codex can go beyond “suggesting code” and, within the allowed boundaries, use real tools to check the result.

5. Verify: compare execution results and changes

Verification is the process of checking evidence to see whether a change matches the requirement. Codex can examine information such as:

  • success or failure from a test or check
  • output produced by a command
  • a diff showing the change between before and after
  • unexpected behavior or an error message

If a test fails, the output differs from what was expected, or part of the result does not match the requirement, Codex can inspect the relevant context again, correct the change, and run the necessary check again. Using the result of one step to guide the next decision is part of the multi-step nature of coding-agent work.

6. Delegate: assign a task, not just ask a question

A user can ask Codex for an explanation, or delegate a small software-development task to it. Here, delegation does not mean transferring all judgment and responsibility. Codex is asked to perform work steps within allowed boundaries, while the user sets the goal and boundaries and checks the result.

The following information can help make a delegation clearer:

  • Goal: What needs to be achieved?
  • Context: Which codebase and situation need to be examined?
  • Constraints: What must not be changed, and which rules must be followed?
  • Done criteria: What must be true for the task to be considered complete?

For example, “Fix the error” is less specific than “When login fails, show the existing error message instead of a blank screen, and make sure the related test passes. Do not change the login method itself.” The second request defines the task boundaries more clearly. However, the purpose of this lesson is not to become a detailed prompt-engineering tutorial; it is to understand the user’s role in providing direction and completion criteria.

7. The roles of Codex and the user

Stage Role Codex can take What the user should check
Read Inspect files, code, structure, and rules related to the task. Are the necessary context and access scope correct?
Modify Write new code or change existing code within the necessary scope. Are there out-of-scope changes or unexpected effects?
Execute Run necessary commands, tests, and checks within the allowed boundaries. Are the execution permissions and targets appropriate?
Verify Inspect output, test/check results, diffs, and failures. Is the evidence sufficient, and is the result acceptable?
Delegate Connect multiple steps and prepare a review-ready result. Did the user provide the goal, constraints, and done criteria and review the final result?

The user provides the instruction and scope, decides the necessary approval for actions with greater impact, and supervises and reviews the work and its result. Codex performs the task within its permitted workspace and permissions. Depending on the environment and settings, Codex may need to ask for approval before it acts.

Therefore, “Codex performs the task” does not mean “the user disappears from the decision-making process.” The person remains responsible for deciding what to delegate, what permissions to grant, and whether to accept the result.

8. Agent loop: use the result to decide the next step

In this lesson, an Agent loop means the following educational workflow model:

  1. Inspect the task and its relevant context.
  2. Decide what change is needed.
  3. Modify the code or files.
  4. Run a necessary test or check.
  5. Inspect the result and diff.
  6. If there is a problem, inspect the context and change again and make a correction.
  7. Organize a result and its supporting evidence so that the user can review it.

This is not a description that reveals Codex’s hidden internal reasoning, nor is it a fixed algorithm that every task must follow. Depending on the task, some stages may be unnecessary, their order may change, or the same stage may repeat several times. The key idea is that Codex can inspect the current result and, when needed, continue to the next action instead of ending with a single response.

Failure can also be part of the loop. When a test failure, unexpected output, or requirement mismatch is found, that information should become evidence for the next correction rather than being hidden or declared a success. A new correction still does not automatically guarantee correctness, so a final review remains necessary.

9. What will we observe in the demo?

In this lesson, instead of following along by typing commands, we observe a real Codex screen in which one small task moves from inspecting repository context → making a focused edit → running a command/test → verifying the result.

The point of the screen is not to teach CLI usage, but to observe how the work is connected. We will look at which files Codex inspected, what it changed, which check it ran, and what evidence it included when summarizing the result. The screenshot 0-3-SS01 below shows this connection.

Windows interactive Codex CLI verifying the approved greeting change, running python -B check.py, and reporting a PASS result with exit code 0
An actual runtime view of Codex inspecting the relevant files and approved change, running a deterministic check, and summarizing the result. This PASS verifies only the greeting requirement; it does not guarantee general software correctness.

10. Key takeaways

  • OpenAI Codex is a coding agent for software development.
  • Codex can go beyond simply generating code and inspect the codebase context needed for a task.
  • It can write new code or modify existing code within the necessary scope.
  • It can run necessary commands, tests, and checks, then verify the result using output and diffs.
  • When a failure or mismatch is found, it can inspect the context again and continue with a correction.
  • The user can delegate a task by providing the goal, context, constraints, and done criteria.
  • Tests and verification reduce the possibility of errors; they do not guarantee perfection.
  • The user remains responsible for instruction, scope, approval, supervision, and review.
  • The Agent loop in this lesson is an educational model for understanding these connected stages, not a fixed internal algorithm.

You can now explain the role Codex can take in a real software-development workflow. In the next lesson, we will objectively examine the similarities and differences between Codex and Claude Code.

EN Official Sources

EN Course Navigation

Previous Current Next
0-2 — From Generative AI to AI Coding Agents 0-3 — What Does OpenAI Codex Do? 0-4 — Similarities and Differences Between Codex and Claude Code

Русский

PART 0 — Понимание AI Coding Agent и Codex
Course ID: 0-3

Что делает OpenAI Codex?

Краткое содержание урока
В этом уроке мы разберём, как OpenAI Codex может изучать контекст codebase, вносить необходимые изменения, выполнять команды и тесты и проверять результаты. Мы также рассмотрим роли Codex и пользователя при делегировании задачи по разработке программного обеспечения.

Дата написания:
Дата технической проверки:

В предыдущем уроке мы узнали, что AI Coding Agent может не только отвечать на вопросы, но и использовать инструменты и связывать несколько этапов для выполнения работы по разработке программного обеспечения. Что же OpenAI Codex делает в реальной задаче разработки?

1. Роль Codex шире, чем у простого генератора кода

OpenAI Codex — это coding agent для разработки программного обеспечения. Он может помогать не только писать новый код, но и изучать существующий код, изменять его, запускать необходимые инструменты и проверять результаты.

Предположим, пользователь делегирует задачу: «Исправь проблему, из-за которой при нажатии кнопки отображается неправильное сообщение». Codex недостаточно сразу создать произвольный код. Сначала необходимо определить связанные с задачей файлы и логику, изменить только необходимую часть, запустить подходящий тест или проверку и убедиться, что результат соответствует требованию.

Здесь задача (task) означает отдельную работу, которую нужно завершить. Задача может быть коротким вопросом, а может быть работой по разработке, для которой требуется связать несколько этапов. Codex способен принять такую задачу, но его результат не становится автоматически правильным во всех случаях.

2. Чтение: изучение контекста текущего codebase

Codebase — это совокупность кода и связанных файлов, из которых состоит программа. Repository часто означает рабочее пространство, в котором эти файлы хранятся вместе с историей изменений. На начальном этапе достаточно понимать оба понятия как связанные с «рабочим пространством, где находится текущая программа», не считая их полностью одинаковыми терминами.

Codex может изучать связанные с задачей файлы, код и структуру папок, чтобы понять необходимый контекст (context). Например, он может выяснить:

  • Какие файлы относятся к запросу?
  • Как работает текущий код?
  • Какие имена, структуры и правила уже используются?
  • На какие другие части может повлиять изменение?

Это не означает, что Codex всегда полностью читает весь repository от начала до конца для каждой задачи. Качественная работа начинается с поиска области, необходимой для запроса, и понимания этой области. Поэтому требования пользователя нужно рассматривать вместе с текущим состоянием кода.

3. Изменение: точечное изменение в необходимой области

Изучив контекст, Codex может написать новый код или изменить существующий. Важно не изменить как можно больше, а сделать точечное изменение (focused change) — ограничиться тем, что необходимо для достижения цели.

В примере с неправильным сообщением может быть достаточно изменить только соответствующий текст. Но если причина заключается в условной логике, может потребоваться одновременно изменить эту логику и связанный с ней тест. Даже похожие запросы могут требовать разного объёма изменений в зависимости от текущего кода и требований.

Способность Codex изменять файлы не означает, что изменение обязательно правильно. Быстро подготовленное изменение может не учесть требование или повлиять на другое поведение, поэтому на следующем этапе нужно проверить фактический результат.

4. Выполнение: использование необходимых инструментов после написания кода

Написать код и подтвердить, что он действительно работает ожидаемым образом, — разные действия. При необходимости Codex может выполнять команды в рабочей среде и использовать такие средства проверки, как тесты, lint, format или type check.

Не для каждой задачи нужны одинаковые команды или тесты. Для исправления опечатки в документации запуск тестов может почти не требоваться, тогда как небольшое изменение кода может потребовать нескольких проверок. Выбор зависит от устройства repository, характера задачи и инструкций пользователя.

В этом уроке мы не изучаем синтаксис конкретных команд. Главное — понять, что Codex может не останавливаться на «предложении кода», а в разрешённых границах использовать реальные инструменты для проверки результата.

5. Проверка: сопоставление результата выполнения и изменения

Проверка (verification) — это процесс, в котором по доступным свидетельствам определяется, соответствует ли изменение требованию. Codex может изучать, например:

  • успешный или неуспешный результат теста или проверки
  • output, выведенный командой
  • diff, показывающий разницу до и после изменения
  • неожиданное поведение или сообщение об ошибке

Если тест завершился неудачно, output отличается от ожидаемого или часть результата не соответствует требованию, Codex может снова изучить связанный контекст, исправить изменение и повторно выполнить необходимую проверку. Использование результата одного этапа для следующего решения отражает многоэтапный характер работы coding agent.

6. Делегирование: передача задачи, а не только вопроса

Пользователь может попросить Codex что-либо объяснить или делегировать ему небольшую задачу по разработке программного обеспечения. Здесь делегирование (delegation) не означает передачу всех решений и всей ответственности. Codex поручают выполнить этапы работы в разрешённых границах, а пользователь задаёт цель и границы и проверяет результат.

Для ясного делегирования полезна следующая информация:

  • Goal: Чего нужно достичь?
  • Context: Какой codebase и какую ситуацию нужно изучить?
  • Constraints: Что нельзя менять и каким правилам нужно следовать?
  • Done criteria: Какие условия должны выполняться, чтобы задача считалась завершённой?

Например, запрос «Исправь ошибку» менее конкретен, чем «Если вход не удался, показывай существующее сообщение об ошибке вместо пустого экрана; связанный тест должен проходить. Сам способ входа не меняй». Второй вариант точнее задаёт границы задачи. Однако цель этого урока — не подробное изучение prompt engineering, а понимание роли пользователя в задании направления и критериев завершения.

7. Роли Codex и пользователя

Этап Какую роль может выполнять Codex Что должен проверить пользователь
Чтение Изучать связанные с задачей файлы, код, структуру и правила. Верны ли необходимый контекст и область доступа?
Изменение Писать новый код или изменять существующий в необходимой области. Нет ли изменений вне scope или неожиданных последствий?
Выполнение Выполнять необходимые команды, тесты и проверки в разрешённых границах. Подходят ли разрешения на выполнение и целевые объекты?
Проверка Изучать output, результаты тестов/проверок, diff и сбои. Достаточно ли свидетельств и можно ли принять результат?
Делегирование Связывать несколько этапов и подготавливать результат к review. Задал ли пользователь goal, constraints и done criteria и проверил ли итоговый результат?

Пользователь задаёт instruction и scope, определяет необходимость approval для действий с более значительными последствиями, контролирует (supervision) ход работы и выполняет review результата. Codex выполняет задачу в пределах разрешённого рабочего пространства и предоставленных прав. В зависимости от среды и настроек Codex может потребоваться запросить approval перед действием.

Таким образом, «Codex выполняет задачу» не означает, что «пользователь исчезает из процесса принятия решений». Человек по-прежнему отвечает за то, что делегировать, какие разрешения предоставить и можно ли принять результат.

8. Agent loop: результат определяет следующий этап

В этом уроке Agent loop означает следующую учебную модель workflow:

  1. Изучить задачу и связанный с ней контекст.
  2. Определить необходимое изменение.
  3. Изменить код или файлы.
  4. Выполнить необходимый тест или проверку.
  5. Изучить результат и diff.
  6. Если обнаружена проблема, снова проверить контекст и изменение и внести исправление.
  7. Подготовить результат и подтверждающие его данные так, чтобы пользователь мог выполнить review.

Это не описание, раскрывающее скрытый внутренний reasoning Codex, и не фиксированный алгоритм, которому обязана следовать каждая задача. В зависимости от задачи некоторые этапы могут быть не нужны, их порядок может меняться, а один этап может повторяться несколько раз. Главное — Codex может проверить текущий результат и при необходимости перейти к следующему действию, а не завершать работу единственным ответом.

Неудача также может стать частью loop. Если обнаружены test failure, неожиданный output или requirement mismatch, эту информацию следует использовать как основание для следующего исправления, а не скрывать или объявлять успехом. Повторное исправление всё равно не гарантирует автоматическую правильность, поэтому окончательный review остаётся необходимым.

9. Что мы будем наблюдать в демонстрации?

В этом уроке вместо самостоятельного ввода команд мы наблюдаем реальный экран Codex, где одна небольшая задача проходит путь: изучение контекста repository → точечное изменение → выполнение команды/теста → проверка результата.

Цель экрана — не обучение работе с CLI, а наблюдение за связью этапов. Мы посмотрим, какие файлы изучил Codex, что он изменил, какую проверку выполнил и какими данными подтвердил итог. Screenshot 0-3-SS01 ниже показывает эту связь этапов.

Интерактивный Codex CLI в Windows проверяет утверждённое изменение приветствия, запускает python -B check.py и сообщает результат PASS с кодом выхода 0
Реальный экран выполнения Codex: он проверяет связанные файлы и утверждённое изменение, запускает детерминированную проверку и подводит итог. Этот результат PASS подтверждает только требование к приветствию и не гарантирует общую корректность программы.

10. Главное

  • OpenAI Codex — coding agent для разработки программного обеспечения.
  • Codex может не ограничиваться генерацией кода и изучать контекст codebase, необходимый для задачи.
  • Он может писать новый код или изменять существующий в необходимой области.
  • Он может выполнять необходимые команды, тесты и проверки, а затем проверять результат по output и diff.
  • При обнаружении сбоя или несоответствия он может снова изучить контекст и продолжить исправление.
  • Пользователь может делегировать задачу, задав goal, context, constraints и done criteria.
  • Тесты и verification снижают вероятность ошибок, но не гарантируют идеального результата.
  • Пользователь сохраняет ответственность за instruction, scope, approval, supervision и review.
  • Agent loop в этом уроке — учебная модель для понимания связанных этапов, а не фиксированный внутренний алгоритм.

Теперь вы можете объяснить, какую роль Codex может выполнять в реальном процессе разработки программного обеспечения. В следующем уроке мы объективно рассмотрим сходства и различия между Codex и Claude Code.

RU Official Sources

RU Course Navigation

Previous Current Next
0-2 — От генеративного ИИ к AI Coding Agent 0-3 — Что делает OpenAI Codex? 0-4 — Сходства и различия между Codex и Claude Code
728x90
300x250
저작자표시 비영리 동일조건 (새창열림)

'AI > Codex' 카테고리의 다른 글

Local vs Cloud Work in Codex: Where Files and Tasks Live  (0) 2026.09.14
Where to Use Codex: A Map of Its Environments  (0) 2026.09.11
Codex and Claude Code: Similarities and Differences  (0) 2026.09.09
From Generative AI to AI Coding Agents  (0) 2026.09.06
What Are Programming and Software Development?  (0) 2026.09.04

관련글

티스토리툴바