Самый подробный гайд по Codex: как начать Vibe Coding с нуля

В эти выходные я почти всё время, кроме сна, занимался Vibe Coding.

Писал статью и параллельно кодил. Заваривал лапшу и параллельно кодил. Смотрел кино и всё равно где-то рядом крутил Codex.

Codex вместе с GPT-5.5 оказался слишком удобным.

Раньше некоторые версии Codex были не то чтобы бесполезными. Они просто могли бесить скоростью. Уходишь из дома, оставляешь задачу на кодинг, возвращаешься после ужина через два-три часа, а он всё ещё что-то правит.

Сейчас Codex ощущается иначе.

Он стал заметно быстрее, лимиты стали дружелюбнее, а модель лучше попадает именно в инженерные задачи. По моему опыту, если говорить только про Vibe Coding, это уже очень хороший вход для обычного пользователя.

Если вы когда-то хотели попробовать Vibe Coding, но так и не начали из-за банов Claude, багов в open-source-инструментах, сложных IDE или командной строки, которая отбивает всякое желание жить, я бы сейчас серьёзно посоветовал снова посмотреть на Codex.

Приложение OpenAI Codex плюс GPT-5.5 уже похоже на маршрут, который закрывает и первый вход, и дальнейший рост, и регулярную работу.

Поверьте, если человек вроде меня смог поймать на нём состояние потока, то и у вас, скорее всего, получится. За один уикенд я закрыл четыре-пять задач, которые раньше сам бы просто не вывез.

Если смог я, сможете и вы.

Поэтому я правда советую: начните пробовать AI-кодинг уже сейчас. Неважно, насколько вы новичок. Берёте Codex и делаете что-то для себя, под свою реальную задачу.

И главное: у Codex есть приложение.

Нормальное графическое приложение.

Я много лет занимался пользовательским опытом, и как человек без профессионального программистского бэкграунда скажу честно: мне трудно принять мысль, что почти в 2030 году я всё ещё обязан жить в командной строке, чтобы писать код с AI.

Первый опыт с CLI и TUI у меня был довольно болезненным.

Я даже не понимал, как открыть нужную папку.

А ещё есть вещь, которая для обычного пользователя выглядит совсем против интуиции: копировать и вставлять.

Мы же все знаем, что `Ctrl+C` — это «копировать», да?

Я тоже так думал.

А потом в терминале выделил кусок текста, нажал по привычке `Ctrl+C`, и вместо копирования просто остановил текущий процесс.

Я тогда на секунду замолчал.

Конечно, командная строка нужна. Программисты её любят не просто так. Но для многих непрофессиональных пользователей полноценное приложение с графическим интерфейсом снижает порог входа в разы.

Поэтому я и рекомендую Codex.

Не потому что он идеален. Потому что он наконец-то даёт многим людям шанс начать без лишней боли.

Я люблю разбираться в инструментах, но, честно, не хочу страдать ради самого страдания.

В этот раз я на стороне OpenAI.

В этой статье я хочу спокойно рассказать, что такое Codex и как с ним начать. Надеюсь, больше людей наконец-то попробуют Vibe Coding не как красивое слово из ленты, а как рабочий способ делать свои штуки.

Не обязательно сразу строить большой продукт.

Можно начать с маленького инструмента: скрипта для сортировки файлов, личной страницы, рабочего workflow, бота для таблиц.

Как только один раз что-то сделал сам, остановиться уже трудно.

Сначала короткое объяснение.

Многие уже слышали про Claude Code или другие coding agents.

Их можно воспринимать так: поверх модели лежит инженерный слой, который умеет читать проект, править файлы, запускать команды и держать контекст задачи.

Codex — это агент OpenAI для программирования и инженерной работы.

Сначала он выглядел как чисто coding agent, но постепенно такие инструменты становятся почти универсальными агентами.

Причина простая: последние тридцать лет цифровой мир строился вокруг кода.

Чем сильнее у инструмента инженерные способности, тем ближе он к универсальному исполнителю задач.

Поэтому вокруг и обсуждают, что логика софта меняется.

Codex и Claude Code сами по себе не модели. Это приложения верхнего уровня.

Им нужна модель внутри.

Сейчас в Codex OpenAI продвигает GPT-5.5. Она лучше подходит для кода, рефакторинга, дебага, запуска команд, чтения репозитория и инженерного планирования.

Входов в Codex стало больше, чем раньше.

Можно пользоваться десктопным приложением, CLI, облачными задачами в вебе и расширениями для IDE.

Десктопное приложение уже есть для macOS и Windows.

Для новичка это важно.

Больше не нужно упираться в командную строку с первой минуты.

Начать просто.

Открываете официальный сайт Codex:

Скачиваете приложение, устанавливаете, логинитесь.

Доступные модели и лимиты зависят от вашего плана ChatGPT.

Free, Go, Plus, Pro, Team, Enterprise — у разных планов разные возможности и лимиты. В начале не нужно держать в голове все детали. После входа просто посмотрите, какие модели и квоты доступны именно в вашем аккаунте. Интерфейс покажет точнее любого чужого пересказа.

Если оформить подписку GPT не получается или под рукой нет VPN, можно подключаться через стороннего API-провайдера вроде bettertoken.ai. Для работы Codex в России в таком сценарии не нужна отдельная подписка ChatGPT и не нужен VPN: вы меняете `API Key` и `Base URL`, а привычный workflow, plugins и skills продолжают работать.

Когда вы установите Codex и войдёте в аккаунт, увидите интерфейс, похожий на рабочее место проекта.

Тут есть важное понятие: Thread.

Но в логике Codex лучше сначала разделить всё на два уровня.

Первый уровень — папка, то есть workspace.

Её можно воспринимать как директорию проекта или тематическую коробку.

Например:

- учебные материалы; - статьи и заметки; - реальные dev-проекты; - песочница для тестов; - общие скрипты и небольшие инструменты.

Папка хранит код, материалы и файлы.

Второй уровень — Thread.

Открываете папку и видите внутри отдельные диалоги. Каждый Thread — отдельная линия задачи.

Связь такая:

в одной папке может быть много Thread.

Каждый Thread работает в одном workspace, но ведёт одну конкретную задачу.

Самая приземлённая аналогия:

папка похожа на проектный чат;

Thread — на отдельную тему внутри этого чата.

В одной теме вы обсуждаете задачу, Codex в этом же контексте меняет файлы, запускает команды и фиксирует ход работы.

Перешли в другую тему — переключились на другую линию.

Для новичка это очень удобно.

Потому что две вещи, которые легко смешать, разделены:

папка хранит код и материалы;

Thread хранит ход мысли и процесс.

Так вы не попадаете в классический кошмар: утром просите написать страницу, днём посчитать Excel, вечером поправить текст, потом всё это перемешивается в одну кашу, контекст загрязняется, AI начинает фантазировать, а вы уже не понимаете, где лежат файлы.

В Codex достаточно держаться простого правила.

В одной папке — одно большое направление.

В одном Thread — одна конкретная задача.

Так обычно получается лучше всего.

Файлы и ресурсы внутри проекта общие, но диалоги и цели не мешают друг другу. И всегда можно вернуться к задаче с того места, где остановились.

Поэтому советую с самого начала продумать структуру.

У меня, например, на компьютере есть папка `dev`.

Внутри:

- `Learning`: учебные материалы; - `notes`: статьи и заметки; - `Projects`: реальные проекты; - `sandbox`: временные эксперименты; - `tools`: переиспользуемые скрипты, маленькие утилиты и компоненты.

Если реальных проектов больше, можно дробить дальше.

Например, в `Projects` лежат сайт, боты, сервисы для сбора данных, внутренние инструменты.

Внутри каждого проекта — свои функциональные папки.

На старте такая классификация кажется занудством, но она правда важна.

Хорошая структура — это половина удовольствия от дальнейшей работы с Codex.

Не открывайте новый диалог под каждую мысль, как в обычном чат-боте.

Папки проекта и Thread нужно вести аккуратно.

Когда локальная структура готова, добавьте нужную папку в Codex как workspace.

Например, хотите делать сайт — добавляете папку сайта, открываете Thread и начинаете задачу.

Тут уже можно писать первое сообщение.

Но я знаю, вы торопитесь.

Не спешите.

Лучше сначала пройти несколько настроек и функций.

Codex уже довольно зрелый продукт.

У него есть функции, которые особенно полезны новичкам.

Первая — scheduled tasks, то есть задачи по расписанию.

Смысл простой: Codex может выполнять какие-то действия в заданное время.

Допустим, у вас несколько проектов крутятся на облачном сервере, а в серверной части вы разбираетесь плохо.

Можно попросить Codex настроить ежедневную проверку.

Утром он смотрит, нет ли ошибок, не заканчивается ли диск, не упали ли фоновые задачи.

Если что-то не так, сначала диагностирует проблему, потом даёт сводку.

Для непрофессионального разработчика это очень полезно.

Не нужно каждый день заходить на сервер и вспоминать команды.

Вы автоматизируете сам факт проверки.

Вторая важная функция — Skills.

Если коротко, это как пакеты способностей для AI.

Один Skill может объяснить агенту:

- какой стиль кода у проекта; - какой тон нужен в статьях; - какой визуальный IP использовать для обложек; - как оформлять сообщения для Telegram; - по какому сценарию работать с локальным деплоем.

Раньше всё это приходилось каждый раз пересказывать заново.

Теперь можно упаковать правила в Skill, установить один раз и переиспользовать.

И главное: в Codex есть графический интерфейс для управления Skills.

Для новичка это прям подарок.

Не нужно гадать, какие Skills установлены, где они лежат и что вообще делают.

Всё видно в интерфейсе.

Codex также встроил Skill Creator.

Можно нажать `New Skill` и обычным языком объяснить, какой Skill вы хотите получить.

Он соберёт базовую структуру, а дальше вы уже докрутите детали.

Для непрофессионального программиста это особенно хорошо.

Не нужно сначала понять половину инженерного мира, чтобы начать собирать собственные рабочие процессы.

Кроме крупных функций, есть несколько мелких настроек, которые стоит пройти.

В настройках сначала посмотрите `General`.

Если часто запускаете длинные задачи, включите опцию, которая не даёт компьютеру уснуть. Иначе задача может остановиться посреди работы.

Follow-up behavior настройте под свой стиль.

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

Дальше — `Personalization`.

Тут можно прописать глобальные правила.

Это похоже на `AGENTS.md` или общие рабочие договорённости в CLI, просто OpenAI вынесла их в отдельный раздел настроек.

Для новичка я бы дал такой шаблон:

```md

Global rules for Codex

Operating principles - Prefer small, reviewable diffs. Avoid sweeping refactors unless explicitly requested. - Before editing, identify the file(s) to change and state the plan in 3-6 bullets. - Never invent APIs, configs, or file paths. If unsure, search the repo first. - Keep changes consistent with existing style and architecture.

Safety and secrets - Never paste secrets, tokens, private keys, .env values, or credentials into code or logs. - If a task requires secrets, ask me to provide them via environment variables. - Do not add analytics, telemetry, or network calls unless I ask.

Code quality bar - Add or update tests for behavior changes when the project has tests. - Prefer type safety and explicit error handling. - Add comments only when the intent is non-obvious.

Build and run etiquette - If you need to run commands, propose the exact command and why. - When you make changes that may break build, run the fastest relevant check first.

Output formatting - For code changes: include a short summary + list of files changed. - For debugging: include hypotheses, experiments run, and the minimal fix.

My preferences - I like concise explanations, concrete steps, and copy-pastable commands. - Default language for explanations: Russian.

```

Смысл этих правил не в том, чтобы AI стал многословным.

Они заставляют его работать аккуратнее.

Особенно важны пункты «сначала назвать файлы», «не выдумывать пути», «не светить секреты», «делать небольшие правки».

Для новичка это страховка.

Ещё один важный пункт — права.

Codex умеет читать файлы, менять файлы и запускать команды.

В этом его сила.

Но новичку я бы не советовал сразу давать максимальный доступ во всех проектах.

Более спокойный вариант:

- новые проекты, незнакомые репозитории и скачанный код сначала открывать с ограниченными правами; - в своих полностью доверенных проектах постепенно давать больше доступа; - перед удалением файлов, массовым переименованием, деплоем, сетевыми запросами и установкой зависимостей просить Codex объяснить, что он собирается сделать; - с ключами, аккаунтами, серверами и оплатами быть особенно осторожным.

Если вы хорошо знаете проект и понимаете, что в нём происходит, расширенные права делают работу гораздо плавнее.

Но на старте лучше идти спокойнее.

В поле диалога Codex можно ввести `/` и открыть специальные команды.

Для новичка особенно полезны две.

Первая — Plan mode.

Он делает ровно то, что нужно: планирует, но не пишет код.

Я очень советую включать Plan mode перед любой задачей, которая хоть немного сложнее мелкой правки.

Например, когда вы:

- делаете веб-страницу; - пишете бота; - меняете существующий проект; - создаёте Skill; - подключаете сторонний API; - готовите деплой.

Такие задачи плохо начинать с команды «сразу делай».

Сначала агент должен понять запрос, прочитать проект, написать план, назвать риски и разбить работу на шаги.

Когда план понятен, можно запускать реализацию.

Допустим, вы хотите сделать Skill для управления источниками сайта.

У каждого сайта своя логика парсинга. Если сразу отправить Codex править код, он легко начнёт путаться по дороге.

Лучше открыть Plan mode, попросить его прочитать кодовую базу, описать текущую структуру источников, предложить дизайн Skill и только потом писать.

Когда план готов, Codex обычно спрашивает, выполнять ли его.

Если направление вас устраивает, подтверждаете.

Эта пауза сильно снижает шанс, что всё поедет не туда.

Вторая команда — Status.

Она показывает использование за текущий период, остаток лимитов и связанные статусы.

Для активной работы это полезно.

Vibe Coding легко затягивает в режим «ещё чуть-чуть поправлю».

Потом смотришь — лимит закончился.

Так что привычка иногда открывать Status точно не лишняя.

Отдельно скажу про модель и уровень reasoning.

В Codex у GPT-5.5 обычно есть разные режимы или уровни рассуждения.

Упрощённо:

чем выше уровень, тем больше токенов модель тратит на анализ и самопроверку перед ответом.

Ответ часто получается стабильнее и полнее, но задача идёт медленнее и расходует больше лимита.

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

Но если задача тяжёлая:

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

Тогда есть смысл включить более высокий reasoning.

В таких задачах важнее всего шанс успеха и время.

Лишние токены на размышление могут окупиться.

Теперь можно наконец-то кодить.

Здесь нет особой магии.

Просто описываете задачу словами.

В Codex есть микрофон в правом нижнем углу. Я часто нажимаю его и просто говорю.

Мой текущий сценарий такой.

Сначала открываю Plan mode в Codex.

Потом голосом или текстом описываю задачу.

Если речь про frontend, отдельно прошу сначала продумать интерфейс: адаптивность, иерархию информации, состояния взаимодействия.

Если задача касается сервера или деплоя, прошу сначала проверить существующие настройки и не строить догадки из воздуха.

Когда появляется план, я его читаю.

Если направление нормальное, запускаю разработку.

После реализации сразу смотрю frontend или запускаю минимальную проверку.

Если страница выглядит нормально, продолжаю правки прямо в Codex.

Если результат плохой, я не прошу снести всё целиком. Я объясняю, какая часть не работает, и прошу переделать именно её.

Это важный момент.

Новички часто делают одну ошибку: если результат не нравится, просят AI переписать всё с нуля.

Так проект легко становится всё более хаотичным.

Лучше сказать:

- какая часть плохая; - почему плохая; - какой результат нужен; - какие места трогать нельзя.

AI — не волшебный колодец желаний. Скорее сильный исполнитель, которому нужно постоянно калибровать направление.

Чем точнее вы говорите, тем лучше он работает.

Есть ещё один приём.

В Codex можно вести несколько Thread параллельно.

Один Thread правит frontend.

Другой пишет тесты.

Третий собирает документацию.

Четвёртый разбирает проблему с деплоем.

Все они работают в одной папке проекта, но цели разные.

Для Vibe Coding это очень удобно.

Вы запускаете несколько задач, отходите, потом возвращаетесь и проверяете результат.

Но тут тоже нужна дисциплина: чем больше параллельности, тем важнее управлять областью изменений.

Не заставляйте два Thread одновременно править одни и те же файлы.

Конфликты потом будут неприятными.

В конце дам пару советов тем, кто ещё ни разу не начинал.

Первое: не начинайте с большого проекта.

Многие сразу хотят сделать полноценное приложение, коммерческий продукт или сложный сайт.

Это классно.

Но лучше начать с маленькой штуки, которой вы сами будете пользоваться.

Например:

- автоматически сортировать папку загрузок; - массово переименовывать скриншоты; - приводить статьи к нужному формату; - сделать личную страницу-навигацию; - написать инструмент для картинок к Telegram-постам; - автоматизировать любую повторяющуюся работу.

У маленьких инструментов есть плюс: задача настоящая, обратная связь быстрая, а если что-то сломается, не страшно.

Второе: всегда просите AI сначала написать план.

Можно прямо так:

```text Пока не пиши код. Сначала прочитай структуру проекта, отталкиваясь от первых принципов, составь план реализации, перечисли файлы для изменения, риски и способ проверки. ```

Эта фраза очень помогает.

Она заставляет AI сначала понять, а потом делать.

Третье: после разработки проводите adversarial review.

Можно написать:

```text Проведи adversarial review: представь, что пытаешься сломать эту функцию через ошибочные действия пользователя, странные входные данные, пограничные условия, риски безопасности и сбои деплоя. Проверь по пунктам, что ещё может пойти не так. ```

Так AI переключается из режима «помочь закончить» в режим «найти слабые места».

Многие скрытые баги всплывают именно так.

Четвёртое: не бойтесь, что не понимаете код.

Это нормально.

Я тоже не профессиональный программист.

Но это не мешает создавать вещи с AI.

На старте вам не нужно читать весь код как инженер. Гораздо важнее научиться описывать задачу, разбивать её на шаги, проверять результат и задавать уточняющие вопросы.

В будущем умение писать код с AI, скорее всего, станет базовым навыком вроде Excel.

Это большой сдвиг.

Для программистов AI — ускоритель.

А для многих людей, которые не умели писать код, AI убирает барьер, через который раньше было не перепрыгнуть.

Поэтому я давно думаю, что Vibe Coding для непрограммистов может быть даже важнее, чем для программистов.

Он даёт обычному человеку новую способность создавать.

Вам не нужно сначала стать инженером, чтобы получить право сделать свою идею.

Можно начать.

Делать и учиться.

Учиться и просить AI подготовить следующий шаг.

Это правда приятно.

Надеюсь, вы тоже попробуете.

Удачного кодинга.