В двух предыдущих статьях я уже показал две разные стороны одной задачи — как встроить ИИ в обычную работу разработчика.

В первой части — «Laravel Copilot Workspace: как я собрал полный цикл разработки вокруг Copilot-агентов» — я показал, как вокруг GitHub Copilot можно выстроить целый цикл жизни проекта. Там есть отдельные агенты по требованиям, архитектуре, коду, качеству, документации и релизам, а в самом репозитории лежат общие инструкции, по которым они работают. В результате Copilot перестаёт быть одним абстрактным ИИ и превращается в команду цифровых коллег, которая ведёт проект по шагам — от идеи до релиза.

Во второй части — «Как я делаю “снимок” проекта в JSON для ИИ и разворачиваю его обратно» — я решал более приземлённую проблему: как показать модели живой проект целиком. Для этого появился небольшой инструмент scan2json, который один раз аккуратно «фотографирует» нужную часть проекта и превращает её в JSON/JSONL вида {file, content}. Такой снимок уже можно коммитить, прикладывать к задачам, загружать ассистентам GPT или использовать в своих сервисах.

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

сначала в веб-интерфейсе GPT я вместе с моделью прорабатываю идею и превращаю её в техническое задание; потом в Visual Studio Code я отдаю это ТЗ Codex, и он уже выступает в роли «старшего разработчика» с полным доступом к проекту.

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

Ниже расскажу, почему я вообще вынес Codex в отдельный режим, как выглядит стандарт ТЗ, который я подсовываю GPT, как организована работа в два шага и каким образом это потом стыкуется с Copilot-агентами и scan2json.

Зачем мне вообще отдельный «режим Codex»

Причин несколько.

Первая — сама модель. В какой-то момент в Codex появилась более мощная версия, заточенная именно под задачи разработки кода. По ощущениям при живой работе разница действительно заметна: меньше откровенно странных предложений, лучше держится длинная цепочка изменений, быстрее получаются целостные решения, а не набор локальных правок.

Это особенно чувствуется на задачах типа «подготовить набор скриптов для окружения», «собрать консольный инструмент с меню и диагностикой», «пройтись по проекту и везде одинаково поменять конфигурацию». Там, где раньше приходилось делать много коротких итераций — сначала заготовка, потом фиксы, потом ещё немного допиливания — теперь часто хватает одного хорошо проработанного ТЗ и одной-двух крупных сессий.

Вторая причина — люди. Разработчики в моей команде, как и многие, довольно консервативны. Классический Copilot в режиме «дописать мне строчку» большинство уже спокойно принимает. А вот истории про агентов, пайплайны, батчи и отдельные папки под домен и требования у некоторых вызывают ощущение «слишком сложно».

Мне хотелось дать им максимально простой и честный режим: описали задачу нормальным человеческим языком, превратили её в ТЗ, отдали Codex, получили работающий код, который уже можно запускать и тестировать. Без необходимости сразу вникать во внутреннюю кухню workspace’ов, разбираться в агентах и служебных файлах и с ходу запоминать, куда что складывать.

Третья причина — старт новых проектов. Начинать с Copilot-агентов удобно, когда у вас уже есть структура: домен, требования, правила, документация. Но когда у вас пустой или почти пустой репозиторий и идея «сделать X», проще всего зайти так: один раз хорошо проговорить задачу с GPT, получить ТЗ и отдать его Codex. А уже когда проект обрастёт правилами и устоявшимися решениями, можно перевести его на рельсы Copilot Workspace.

Стандарт ТЗ: не промпт, а нормальный документ

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

Полный файл стандарта я вынес в отдельный репозиторий: https://github.com/zabarov/codex-tz-template. Там лежит AI_TZ_Guide_for_Codex.md — тот самый шаблон, который я использую в работе. Его можно просто скачать и загрузить в чат с GPT, чтобы воспроизвести у себя тот же процесс, о котором я рассказываю в этой статье.

У этого файла есть три адресата.

Для меня, как разработчика, это чек-лист: что нужно обязательно описать, чтобы другой человек или ИИ могли реализовать задачу без угадываний. Там разделы про контекст проекта, текущую реализацию, цель изменений, функциональные и нефункциональные требования, сценарии использования, ограничения, критерии приёмки.

Для GPT это инструкция «как вести себя в этом диалоге». В стандарте я описываю, что модель должна сначала задавать вопросы по блокам (про проект, про проблему, про цель, про ограничения), а уже потом собирать итоговый документ. Отдельно фиксирую, что нельзя молча додумывать важные требования: если чёткости не хватает, нужно спросить.

Для Codex это гарантированный формат входа. Я не хочу каждый раз объяснять: «вот здесь цель, вот здесь ограничения, вот тут команды запуска». Гораздо удобнее один раз договориться о структуре и держаться её во всех проектах. Тогда Codex получает всегда примерно одно и то же: раздел о проекте, раздел о текущем состоянии, раздел о желаемом поведении, сценарии, проверки.

Стандарт устроен так: сначала короткое объяснение, зачем всё это, потом перечень вопросов для интервью, потом каркас структуры ТЗ и в конце небольшой чек-лист перед отправкой документа в Codex. В рабочем процессе это выглядит просто: я загружаю файл в чат, пишу одной фразой, по какой задаче мне нужно ТЗ, и дальше отвечаю на вопросы.

Шаг 1. GPT как интервьюер и автор технического задания

Когда этот файл уже загружен в чат, GPT переключается в режим «ассистента по ТЗ». Для меня это обычный разговор.

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

Дальше идёт блок про ограничения: по окружению, по безопасности, по совместимости с другими системами, по времени выполнения. Потом — вопросы про критерии приёмки: что вы будете считать успехом, как будете проверять, что изменение «зашло».

Важно, что на этом этапе я не пытаюсь писать готовый документ — я просто отвечаю на вопросы и, по сути, проговариваю то, что обычно остаётся у автора задачи «в голове». Если где-то я отвечаю слишком общо, модель по стандарту обязана вернуть мяч и уточнить: «что вы имеете в виду под…», «есть ли ограничения по…».

Когда вопросов становится достаточно, я прошу: «Собери, пожалуйста, итоговое ТЗ по нашему стандарту». GPT берёт каркас из файла, подставляет туда все ответы, структурирует их и добавляет недостающие связки. Получается аккуратный документ с разделами и подзаголовками, а не простыня текста.

Дальше мы вместе пробегаемся по чек-листу из стандарта: хватает ли информации, чтобы Codex мог работать без дополнительного допроса, понятна ли цель, есть ли явные критерии приёмки, указаны ли команды и пути. Иногда на этом шаге всплывают вещи, о которых я вообще не думал, пока не увидел ТЗ целиком.

В итоге к моменту, когда я иду к Codex, у меня есть не абстрактная идея вида «сделай что-нибудь удобное», а нормальное техническое задание, которое можно отдать и живому разработчику.

Шаг 2. Codex как «старший разработчик» в IDE

Следующий шаг — перенести ТЗ туда, где пишется код. Здесь в ход идёт Codex в Visual Studio Code.

Я открываю нужный репозиторий, запускаю Codex, создаю новую сессию и вставляю туда получившееся ТЗ. Дальше я отношусь к Codex именно как к разработчику, а не как к «умному автокомплиту».

Сначала я прошу его проговорить, как он собирается это реализовывать. В ответ обычно получаю план: какие файлы нужно создать, какие слои затронуть, какие конфиги поправить, где добавить скрипты, какие зависимости понадобятся. Если план выглядит разумным, я прошу «давай делать». Если нет — мы обсуждаем альтернативы, пока не придём к варианту, который меня устраивает.

Потом начинается привычный цикл: я даю задачу на основе ТЗ, Codex пишет код, я запускаю проект, смотрю на поведение, возвращаюсь к Codex с конкретной обратной связью — что работает не так, что неудобно, где ошибка в логах, чего не хватает в проверках.

При этом я стараюсь держаться на уровне смысла, а не директив. Например, вместо «сделай ещё один if вот здесь» я пишу что-то вроде: «здесь сценарий для пользователя неочевиден, предлагаю такой-то UX, как ты адаптируешь текущую реализацию под это?» или «мы упустили кейс с такими-то входными данными, давай научим систему его корректно обрабатывать».

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

Есть ещё одна важная деталь: я не рассчитываю на «магическую память» одной сессии. Если проект большой, если мы уже работали над ним вчера и позавчера, я подсовываю Codex дополнительный контекст: выдержки из правил, куски старых ТЗ, снимок проекта, если он нужен. Здесь как раз помогает scan2json: можно снять срез интересующей части проекта, передать его ИИ и опираться не только на то, что открыто в IDE.

Как это сочетается с Copilot-агентами и scan2json

Снаружи может сложиться впечатление, что схема с Codex — это что-то параллельное по отношению к Copilot Workspace. На практике у меня это одна линия, просто на разных этапах.

На старте проекта мне удобнее всего идти через GPT + Codex. Есть идея и пустой репозиторий — я готовлю ТЗ по стандарту, отдаю его Codex и вместе с ним собираю первую рабочую версию инструмента. В этот момент мне не нужны ни агенты, ни сложные папки — важно, чтобы появился код, от которого можно оттолкнуться.

По мере работы с проектом начинают проявляться устойчивые решения и правила. Как мы оформляем команды, как организуем структуру каталогов, как называем профили, какие проверки всегда делаем, как показываем ошибки пользователю. Эти вещи я не держу только в голове: прошу GPT оформить их в виде явных правил с примерами и складываю в отдельные файлы.

Дальше эти правила переезжают в .github/copilot-instructions.md. Это тот самый общий «мозг» для Copilot-агентов, про который я писал в первой статье. Там фиксируется, что это за проект, как устроены слои, какие договорённости по коду и архитектуре уже действуют, какой стек мы считаем основным, какие инструменты качества нужно запускать.

Параллельно я почти всегда завожу агента помощи — .github/agents/help.agent.md. Это живой помощник для разработчика: он знает структуру репозитория, понимает базовые концепции проекта, умеет подсказать, с чего начать, где лежат настройки, как устроены типовые сценарии. Его удобно делать уже на базе сложившегося кода: когда проект прошёл через несколько витков работы с Codex и накопил достаточно паттернов.

В какой-то момент становится логично перевести проект на рельсы Copilot Workspace целиком. Появляются агенты по требованиям и домену, архитектуре, батчам, качеству, документации, релизам. Новые задачи начинают формироваться в виде артефактов в inputs/, результаты — складываться в results/, документация — жить в docs/.

scan2json в этой картине остаётся универсальным клеем. Если нужно аккуратно показать ИИ кусок большого legacy-проекта — я снимаю «фотографию» через scan.php, получаю JSONL и дальше решаю, как его использовать. Можно загрузить этот снимок ассистенту GPT для анализа архитектуры и технического долга. Можно использовать его в своих RAG-сервисах. Можно развернуть этот срез в отдельную песочницу и дать туда Codex, чтобы он не ломал основной проект.

В итоге получается не три разрозненных штуки, а связка: быстрый двухшаговый режим с Codex для старта и тяжёлых задач, Copilot-агенты — для долгосрочного процесса, scan2json — для честного обмена контекстом между проектом и ИИ.

Сильные и слабые стороны схемы GPT + Codex

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

Сильная сторона номер один — скорость. Когда у вас есть хороший стандарт ТЗ и вы умеете разговаривать с GPT по делу, Codex действительно позволяет очень быстро пройти путь от идеи до рабочей реализации. Это особенно заметно на инфраструктурных и «обвязочных» задачах, которые руками обычно делаются нехотя и растягиваются.

Второй плюс — низкий порог входа для команды. Разработчики, которым тяжело даются разговоры про агентов и батчи, гораздо спокойнее воспринимают процесс «давай вместе напишем нормальное ТЗ, а дальше отдаём его Codex». Это понятная для любого инженера конструкция: есть спецификация, есть исполнитель. Просто исполнитель в данном случае — не человек.

Третий плюс — возможность заходить в незнакомые области. Когда вы не эксперт в shell, nginx или какой-нибудь специфичной библиотеке, но готовы сформулировать цель и проверочные сценарии, связка GPT + Codex вытаскивает вас туда, куда руками вы бы просто не полезли. Важно не забывать про проверки, но сам факт, что это становится возможным, сильно меняет горизонт.

Минусы тоже есть, и о них стоит говорить честно.

Главный риск — эффект «чёрного ящика». Если большую часть кода пишет Codex, легко оказаться в ситуации, когда проект работает, но никто толком не понимает, как именно. Пока всё хорошо — это не проблема. Но когда прилетает сложный баг в проде или нужно сделать нестандартную интеграцию, отсутствие понимания архитектуры больно бьёт.

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

Третий момент — контекст и амнезия. Даже сильные модели не могут бесконечно держать в голове историю проекта. Нужно сознательно управлять тем, что вы подаёте в контекст: вытаскивать важные правила, обновлять ТЗ, при необходимости подсовывать снимки кода через scan2json. Если пустить это на самотёк, модель начнёт противоречить сама себе.

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

Если всё это собрать вместе, получается довольно простая связка из трёх вещей. Я не пытаюсь продать какой-то «единственно верный» путь — у меня просто со временем сложилось, что лучше всего работают такие роли: Copilot-агенты и workspace — когда нужен долгий, дисциплинированный процесс вокруг проекта; scan2json — когда нужно честно упаковать код в вид, удобный для ИИ и своих инструментов; двухшаговый режим GPT + Codex — когда хочется написать код в два счёта: сначала ТЗ, потом реализация.

В разных ситуациях выстреливает разное, и это нормально. Где-то выгоднее завести полноценный конвейер с батчами и агентами, где-то проще и быстрее один раз написать хорошее ТЗ и отдать его Codex. Важно понимать, какие у вас задачи, какой горизонт жизни у проекта и какую часть работы вы готовы делегировать ИИ: от подсказок в коде до полноценной реализации по спецификации.

Мне самому интересно, как это выглядит у других команд. Если вы уже используете ИИ в разработке — напишите в комментариях, как именно вы это делаете. Работаете через Copilot или Codeium как через автодополнение, строите своих агентов, прикручиваете RAG к репозиторию, держите отдельных ассистентов под проекты, гоняете что-то через Codex или, наоборот, обходите весь вайбкодинг стороной? Какие практики у вас прижились, а какие не взлетели?

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