Один продукт на Codex: як довести ідею до живого URL, не потонувши в коді

Між «попросив ШІ написати код» і «у мене в інтернеті працює продукт» лежить десяток кроків, на яких новачки стабільно застрягають: як розбити ідею на зрозумілі агенту шматки, де вести роботу — у терміналі чи в хмарі, як не пустити секрет у чужі руки і як викотити все це на живу адресу. Codex від OpenAI закриває саме цю дистанцію: він не просто пише функції, а сам читає проєкт, править файли, запускає тести і вміє задеплоїти результат.

У цьому гайді ми пройдемо повний шлях одного невеликого продукту з Codex — від ідеї до деплою — на загальному каркасі, який підійде під ваш проєкт: вебзастосунок, бот, внутрішній інструмент. Розберемо метод, а не набір кнопок: де Codex працює локально, де віддає задачу в хмару, і чому наскрізне складання продукту — це про декомпозицію та дисципліну, а не про магічне «напиши мені стартап».

Коротко: що зберемо і що потрібно

Підсумок гайда — робочий продукт, викладений на живий URL, зібраний руками агента під вашим керуванням. Що знадобиться:

• Акаунт ChatGPT з планом, де є Codex (Plus, Pro, Business, Edu, Enterprise) — Codex входить у підписку без окремої плати. Дані на 17 липня 2026: Plus коштує $20/міс, тариф Pro 5x — $100/міс; у 2026 році Codex перейшов на оплату за токенами-кредитами.
• Codex CLI — термінальний агент; ставиться однією командою (нижче).
• Акаунт GitHub — репозиторій і деплой зручніше вести через нього.
• Ідея розміром на вечір — не «маркетплейс», а один зрозумілий сценарій: форма заявок, трекер звичок, лендинг із генерацією тексту.

Досвід у програмуванні для старту не потрібен, але одна установка обовʼязкова: ви розумієте, що робить агент, і ухвалюєте рішення — Codex виконавець, а не автопілот без керма. Якщо сам підхід «будую продукт із ШІ» для вас новий, почніть із розбору, що таке вайб-кодинг і де в нього межі.

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

Крок 1. Ідея та межі: що саме робимо

Головна причина, через яку продукт із Codex перетворюється на кашу, — розпливчаста ідея. Агент чудово виконує чітке і буксує на «зроби красиво та зручно». Тому перший крок — без жодного рядка коду.

Codex для не-програміста: як зібрати перший робочий продукт

AGENTS.md: інструкція, яку агент Codex справді читає перед роботою

AMD Instinct Coder: стійка на вісьмох MI325X обіцяє мінус 70% до ціни токенів

Codex під контролем: як пісочниця і схвалення вирішують, що агенту можна

Codex — не чат-бот, а агент: як формулювати завдання, щоб він робив їх правильно

Сформулюйте продукт у трьох реченнях: що він робить, для кого і що вважається готовим. Приклад: «Телеграм-міні-трекер звичок. Користувач відмічає виконання кнопкою, раз на день бачить статистику. Готово — коли дані зберігаються між перезапусками і є екран статистики». Останнє речення — це ваш definition of done, критерій, за яким ви приймете роботу. Без нього і агент, і ви рухатимете ціль нескінченно.

Одразу окресліть межі першої версії і винесіть за них усе зайве: реєстрація через соцмережі, оплати, гарний дизайн — у «другу версію». Продукт, доведений до деплою, завжди бʼє продукт із десятьма недоробленими фічами.

Крок 2. Як розбити задачу для агента Codex

Друга типова помилка — прохання «напиши застосунок цілком». Агент видасть стіну коду, у якій ви не розберетесь, а перша ж помилка заведе в глухий кут. Правильно — розбити задачу для агента Codex на 3–5 кроків, кожен із яких можна перевірити окремо.

Для трекера звичок декомпозиція має такий вигляд:

1. Каркас проєкту і залежності (порожній запускний скелет).
2. Зберігання даних (модель «звичка» + збереження у файл або БД).
3. Основний сценарій (відмітити виконання).
4. Екран статистики.
5. Підготовка до деплою (змінні середовища, файл залежностей).

Офіційна порада OpenAI щодо промптингу така сама: для багатокрокових задач спершу попросити план, а не одразу код. У Codex CLI для цього є команда /plan — вона «досліджує і пропонує підхід до правок»; після того як план затверджено, /goal утримує ціль між запусками. Ви читаєте план, правите — і лише потім реалізуєте по одному пункту. Це й відрізняє агента від чату: він веде цілісну роботу над проєктом, а не відповідає на разове питання. Різниця докладно розібрана в матеріалі чим агент відрізняється від чату.

Крок 3. Доступ, встановлення і вибір моделі

Codex CLI ставиться однією командою — вона працює всюди, де є Node.js (Windows, macOS, Linux):

BINANCEДосі дивишся збоку?Ринок працює без вихідних. Рахунок на Binance відкривається за 2 хвилини.Почати зараз

npm install -g @openai/codex

Є й альтернативи: brew install --cask codex для macOS, скрипт curl -fsSL https://chatgpt.com/codex/install.sh | sh для Mac/Linux або PowerShell-інсталятор irm https://chatgpt.com/codex/install.ps1 | iex для Windows. На 17 липня 2026 актуальна версія CLI — 0.144.5 (випущена 16 липня), ліцензія Apache-2.0, вихідний код відкритий.

Запустіть codex у теці проєкту і виберіть Sign in with ChatGPT — вхід за вашою підпискою. За замовчуванням CLI працює на моделі gpt-5.6-sol medium (дані на 17 липня 2026); змінити її можна командою /model. Для наскрізного складання продукту це розумний дефолт: Sol — швидка робоча конячка, а легші моделі знадобляться, коли впертеся в ліміти (про це нижче). Глибоко в тарифи та ліміти тут не заглиблюємось — це окрема тема, тут нам важливо, що доступ є і агент запускається.

Крок 4. AGENTS.md: правила проєкту і критерій готовності

Щоб агент не вигадував стиль і не забував про безпеку на кожному кроці, дайте йому постійні інструкції. Codex читає файл AGENTS.md перед початком будь-якої роботи — це його памʼять про ваш проєкт. Покладіть AGENTS.md у корінь репозиторію:

# Правила проєкту

- Стек: Python 3.11, бібліотека aiogram для бота.
- Секрети — тільки зі змінних середовища (os.getenv), ніколи не в коді.
- До кожної нової функції — тест. Перед здаванням проганяй лінтер.
- Definition of done: дані зберігаються між перезапусками, є екран статистики.

Codex підтримує шари: глобальні вподобання — у ~/.codex/AGENTS.md, а правила проєкту — у його корені; файли ближче до поточної теки перевизначають загальніші. Загальний ліміт одного набору — 32 KiB за замовчуванням, тож тримайте інструкції короткими і по суті. Фактично AGENTS.md — це ваш definition of done, зафіксований у файлі: агент звіряється з ним, а не з вашим настроєм. Тема налаштування AGENTS.md заслуговує на окремий розбір, тут нам вистачить робочого мінімуму.

Крок 5. Codex CLI чи хмара: де вести роботу

Codex — не один інтерфейс. На шляху продукту ви перемикатиметесь між локальним CLI та хмарними задачами (codex cloud із термінала переносить роботу в хмару, стежить за задачами і застосовує результат назад локально). Питання «codex cli чи хмара» вирішується не смаком, а типом кроку:

Офіційна рекомендація OpenAI збігається: локально — онбординг, розбір незнайомого коду, ітеративне прототипування; у хмару делегують «довгі задачі, які можна ганяти паралельно», після того як план затверджено. Хмарна задача виконується в ізольованому середовищі і повертає summary + diff; ви дивитесь підсумок і, якщо все добре, відкриваєте pull request. Доступ такої задачі в інтернет налаштовується окремо для кожного середовища — це важливо, коли крок потребує встановлення залежностей або звернення до зовнішнього API.

Крок 6. Тести і ревʼю: не приймати код наосліп

Тут — місце, заради якого варто читати саме наскрізний гайд, а не «10 команд Codex». Агент може видати впевнено неправильний код — зовні правильний, але зламаний у деталях; особливо на незнайомому йому стеку. Тому тести, лінтери та перевірка типів — не опція, а обовʼязковий крок до приймання.

Практичний цикл на кожному кроці декомпозиції:

1. Агент реалізує пункт плану і пропонує дифф.
2. Ви просите прогнати тести і лінтер (це ж прописано в AGENTS.md).
3. Запускаєте локальне ревʼю командою /review.
4. Вносите правки за зауваженнями і перезапускаєте /review, доки зауважень не залишиться.

Читайте дифф і приймайте зміни свідомо, а не тисніть «прийняти все» наосліп. Не розумієте рядок — спитайте агента прямо в чаті, що він робить. Дисципліна «крок → тест → ревʼю → наступний крок» — саме те, що відрізняє доведений до деплою продукт від коду, який потім неможливо лагодити.

Крок 7. Деплой застосунку через Codex: до живого URL

Локально працює — половина справи зроблена, але продукт живе, поки відкритий ваш термінал. Фінальний крок — деплой застосунку через Codex на постійну адресу.

Для вебзастосунків у Codex є готовий маршрут через плагіни: @build-web-apps збирає і перевіряє застосунок (React, деплой, платежі, база даних), а @vercel деплоїть превʼю і повертає живий URL. Стартовий промпт із документації має такий вигляд:

«Use @build-web-apps, щоб перетворити [репозиторій/скриншот/ідею] на робочий сайт. Потім через @vercel задеплой превʼю і поверни мені живий URL. Контекст: [призначення, джерела даних, обмеження].»

Codex сам прожене локальну збірку, переконається, що деплой готовий, викладе превʼю і відзвітує: що змінилося, яка команда збірки виконана і чи готовий деплой. Під капотом деплой на Vercel влаштований просто: пуш у підключений Git-репозиторій автоматично запускає збірку, є середовища Preview і Production, а секрети зберігаються в Environment Variables проєкту, а не в коді. Тут увесь цей маршрут — збірка, локальна перевірка, деплой превʼю і живий URL — веде сам Codex; вам лишається прочитати звіт і прийняти результат.

Якщо ваш продукт — не веб, а, наприклад, бот, принцип той самий: агент готує файл залежностей і змінні середовища, ви заводите проєкт на хостингу (Railway, Render, VPS) і задаєте секрети в налаштуваннях сервісу. Ключове правило деплою — токен чи ключ потрапляє в середовище сервера, але ніколи в git.

Після першого деплою не закривайте задачу: тримайте її відкритою і просіть точкові правки, посилаючись на живий URL — поправити верстку, оновити текст, подивитися логи збірки. Контекст деплою лишається під рукою, і цикл «правка → передеплой → перевірка» іде швидко. Саме так продукт із «працює в мене» перетворюється на «працює у всіх», а ви нарощуєте його по одній фічі за раз, не ламаючи вже викладене.

Типові помилки, ризики та ліміти

Наскрізне складання продукту агентом дає швидкість, але має свої слабкі місця — їх варто знати заздалегідь. Граблі, про які зазвичай дізнаються вже в бою:

Про ліміти докладніше: на плані Plus (дані на 17 липня 2026) обсяг роботи в 5-годинному вікні обмежений, і важкий паралелізм упирається у квоти. Якщо продукт великий, розумно чергувати моделі: Sol для складних кроків, легші Terra/Luna — для рутини, де потужна модель не потрібна.

Codex у CI: headless-режим і авто-рев’ю дифу

Коли базовий цикл опановано, є чим підсилити наскрізне складання:

• codex exec у CI. Неінтерактивний headless-режим запускає Codex як крок конвеєра — наприклад, авто-ревʼю диффа перед деплоєм або генерація скриптів міграції. Продукт отримує вбудовану перевірку якості без ручної участі.
• Паралельні хмарні задачі — але з дисципліною. Кілька агентів пришвидшують роботу, лише якщо в кожного заданий чіткий deliverable і куди він пише результат; інакше отримаєте конфліктні правки поверх одного файлу. Правило просте: одна задача — одна гілка — один зрозумілий підсумок.
• Підключення зовнішніх інструментів. Якщо продукту потрібен вебпошук, база чи сторонній сервіс, агент працює з ними через інструменти та API — за тими самими принципами, що й будь-який ШІ-агент із зовнішніми API. Доступ хмарної задачі в мережу при цьому налаштовується окремо в середовищі.
• Специфікація і тести як метод. Підходи «спочатку специфікація» і «спочатку тест» не залежать від інструмента й однаково добре лягають на Codex — це спосіб тримати агента в межах на великих продуктах.

Чек-лист «ідея → прод»

Пройдіть продукт за цим списком — і він доїде до деплою, а не застрягне на середині:

• [ ] Ідея сформульована в 3 реченнях + записаний definition of done.
• [ ] Межі першої версії окреслені, зайве винесено в «другу версію».
• [ ] Задача розбита на 3–5 перевірюваних кроків.
• [ ] AGENTS.md у корені: стек, правило секретів, вимога тестів, критерій готовності.
• [ ] Кожен крок: план (/plan) → код → тести → ревʼю (/review).
• [ ] Секрети — тільки у змінних середовища, жодного ключа в git.
• [ ] Довгі задачі винесені в codex cloud, локально — правки та відлагодження.
• [ ] Застосунок задеплоєний на живий URL, перевірений у проді.

Поширені запитання

Чи треба вміти програмувати, щоб зібрати продукт із Codex? Для невеликого першого продукту — ні. Код пише агент, а ваша задача — чітко ставити ціль, декомпонувати її та приймати роботу свідомо. Але базове розуміння того, що відбувається в коді, сильно пришвидшує шлях і допомагає ловити помилки агента.

Codex CLI чи хмара — що обирати? За типом кроку, а не за смаком. Локально зручно розбирати ідею, вести дрібні правки та відлагодження зі швидким циклом. У хмару (codex cloud) віддають довгі задачі на багато файлів і паралельні гілки — вони працюють у фоні й повертають готовий diff та pull request.

Як задеплоїти застосунок через Codex? Для вебу — через плагіни @build-web-apps і @vercel: агент збирає застосунок, проганяє перевірки, деплоїть превʼю і повертає живий URL. Для бота чи сервісу агент готує залежності та змінні середовища, а ви заводите проєкт на хостингу і задаєте там секрети.

Чи можна довіряти коду, який написав агент? Не наосліп. Codex може видати впевнено неправильний результат, тому тести, лінтери та перевірка типів обовʼязкові до приймання кожного кроку. Читайте дифф і приймайте зміни свідомо — це правило важливіше за швидкість.

Скільки коштує зібрати продукт із Codex? Codex входить у план ChatGPT без окремої плати (дані на 17 липня 2026: Plus — $20/міс, Pro 5x — $100/міс). Одного продукту-«вечора» зазвичай вистачає в межах квот Plus; при важкому паралелізмі впертеся в 5-годинне вікно і захочете вищий план або легшу модель.