Codex від OpenAI — це не просто «автодоповнення на стероїдах». Це модель, здатна розуміти завдання, писати тести, рефакторити код і виконувати команди в терміналі в рамках автономних агентів. Але між «здатна» і «робить це добре» — велика прірва, яку визначають не технічні обмеження, а типові помилки в роботі з нею.
Більшість проблем, з якими стикаються AI-білдери при інтеграції Codex у свої pipelines, не є унікальними. Вони повторюються знову й знову: розмиті промпти, відсутність контексту, ігнорування виходу за межі вікна. Ця стаття — практичний розбір найпоширеніших із них, щоб ви не наступали на ті самі граблі.
Надто загальні інструкції без прив'язки до коду
Перша і найпоширеніша помилка — давати Codex інструкції на кшталт «додай авторизацію» або «виправ баг». Без конкретики модель змушена робити припущення — і часто робить їх неправильно.
Що реально працює:
- Вказувати конкретний файл, функцію або рядок: «у файлі auth.py, функція validate_token(), рядок 47 — замінити JWT decode на python-jose»
- Описувати очікувану поведінку через тести: «після виправлення test_token_expiry має проходити без mock»
- Давати мінімальний відтворюваний приклад помилки — traceback, не словесний опис
Codex не має телепатії. Якщо ви залишаєте простір для інтерпретації, модель заповнить його власним «здоровим глуздом», який може суттєво відрізнятися від вашого задуму.
Ігнорування контексту файлової структури
Codex, як і будь-яка LLM, обмежений вікном контексту. Але проблема глибша: навіть якщо контекст формально вміщується, модель не завжди «бачить» зв'язки між файлами, якщо ви не надали їй явно.
Типові помилки тут:
- Передача одного файлу без залежностей — модель не знає про типи з інших модулів
- Ігнорування tsconfig.json, pyproject.toml, package.json — Codex може генерувати код для іншої версії бібліотеки
- Відсутність README або коротких інструкцій про архітектуру — модель не розуміє, чому проєкт побудовано саме так
Практичне правило: перед складним запитом завжди додавайте «мінімальний граф залежностей» — не весь код, а лише заголовки та сигнатури функцій файлів, з якими пов'язане завдання. Це різко підвищує якість виходу без марного витрачання токенів.
Сліпе довір'я до результату без верифікації
Codex генерує код, який виглядає правильно. Це його найнебезпечніша риса.
Найчастіші патерни «тихих помилок»:
- Згенерований код компілюється та запускається, але логіка неправильна — особливо у крайніх випадках
- Модель «галюцинує» методи API, яких не існує — особливо для нових бібліотек або рідкісних SDK
- Рефакторинг видаляє «зайвий» код, який насправді обробляє важливий сценарій
Хороша практика — завжди запитувати Codex не лише про реалізацію, але й про тести: «напиши unit-тест, який перевіряє цю функцію для граничних випадків: пустий масив, null, рядок замість числа». Якщо модель не може написати переконливий тест — це сигнал, що вона сама не впевнена у правильності коду.
Інший підхід — двоетапна верифікація: спочатку Codex генерує код, потім той самий промпт подається іншій інстанції з завданням знайти помилки в цьому коді. Так ви отримуєте простий adversarial review без суттєвих додаткових витрат.
Спроба вирішити все одним промптом замість ітерацій
Розробники, які звикли до детермінованих інструментів, часто намагаються «упакувати» все завдання в один запит: «перепиши цей модуль, додай логування, виправ race condition і оптимізуй запити до БД». Codex може видати щось у відповідь — але якість буде значно нижчою, ніж при покроковому підході.
Розбивайте завдання так:
- Спочатку: «проаналізуй цей код і перелічи потенційні проблеми»
- Потім: «виправ race condition у функції process_queue()»
- Далі: «додай структуроване логування для кроків X, Y, Z»
Ітеративний підхід дозволяє перевіряти кожен крок перед рухом далі — і відкочуватися, якщо модель пішла не в той бік. Ще одна пов'язана помилка — не зберігати вдалі промпти. Codex чутливий до формулювань, і той самий запит, перефразований по-іншому, може дати кардинально різний результат. Якщо щось спрацювало добре — зафіксуйте шаблон.
Висновок AiiN
Codex — зрілий інструмент з реальними можливостями для автономних агентів і CI/CD pipelines. Але його якість прямо пропорційна якості вашого контексту й структурованості запитів.
Якщо зводити все до трьох правил: будьте конкретні у промптах, надавайте мінімально необхідний контекст без зайвого та завжди верифікуйте через тести. Модель не замінює code review і не знімає з вас відповідальність за код. Але за умови правильної роботи — різко прискорює весь цикл розробки.
