Я использую Codex как цифрового сотрудника. Вот где он реально экономит время, а где без человека всё разваливается

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

Когда говорят об ИИ для программирования, разговор обычно сводится к одному вопросу: «Он уже может заменить разработчика?»

На практике этот вопрос почти бесполезен.

Меня гораздо больше интересует другое: какую часть реальной работы можно отдать агенту сегодня, чтобы завтра не разгребать последствия?

Я делаю игры на Unity и использую Codex не как генератор отдельных функций. Я даю ему доступ к проекту, формулирую задачу, разрешаю изучить архитектуру, внести изменения, запустить проверки и показать результат. Иногда он действительно работает как сильный технический исполнитель. Иногда — очень убедительно доказывает, что всё готово, хотя до готовности ещё один полноценный этап.

Официально OpenAI описывает Codex как инструмент, который умеет разбираться в кодовых базах, создавать и исправлять функциональность, запускать проверки и готовить изменения к отправке. В целом это совпадает с моим опытом. Но между «умеет выполнить операцию» и «несёт ответственность за продукт» лежит огромная дистанция.

Плохая задача для агента звучит так:

Сделай систему прокачки персонажа.

Хорошая задача больше похожа на постановку сотруднику:

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

Разница принципиальная. В первом случае я прошу получить код. Во втором — пройти контролируемый маршрут от неизвестного проекта к проверяемому изменению.

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

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

Это была не одна функция. Изменения проходили через несколько компонентов, конфигурационный asset и игровые условия. После работы проект скомпилировался без C#-ошибок, а статические проверки не нашли проблем в diff.

На этом очень хочется сказать: «Готово».

Но это было бы неправдой.

Компиляция подтверждает, что код собирается. Она не подтверждает, что игрок действительно получает нужное улучшение в нужный момент, что баланс не сломан, что объект назначен в сцене и что вся цепочка работает на устройстве. Полноценный runtime-тест тогда оставался отдельной задачей.

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

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

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

Выяснилось, что:

- в Android используется рабочий провайдер мобильной рекламы; - в редакторе — мгновенная заглушка для тестирования; - баннер, interstitial и rewarded-видео имеют разные условия показа; - release-сборка блокируется, пока не заполнены production ID; - вознаграждение выдаётся только после подтверждённого завершения ролика.

Самое ценное: агент ничего не стал менять, потому что задача была на аудит. Он отделил факты от рекомендаций и показал реальный блокер релиза.

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

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

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

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

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

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

Если можно запустить компиляцию, он запустит компиляцию. Если runtime-сценарий требует устройства, аккаунта или ручного взаимодействия, возникает соблазн закончить на ближайшей зелёной метрике. Поэтому критерий готовности я формулирую заранее.

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

Сейчас я стараюсь выдавать Codex задачи по одной схеме:

1. Контекст. Что это за проект и зачем нужна задача. 2. Границы. Что разрешено менять, а к чему нельзя прикасаться. 3. Критерий готовности. Как выглядит результат, который можно принять. 4. Проверки. Компиляция, тесты, runtime, визуальный осмотр, состояние Git. 5. Честный остаток. Что после работы всё ещё не доказано.

Последний пункт — самый важный. Хороший результат агента должен заканчиваться не словом «готово», а границей достоверности.

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

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

Главная ошибка — покупать этот рычаг вместе с иллюзией автономности.

Я больше не спрашиваю: «Может ли ИИ написать этот код?»

Я спрашиваю:

Могу ли я так поставить задачу и построить проверки, чтобы результат агента было безопасно принять?

И вот на этот вопрос Codex всё чаще позволяет ответить «да».

Больше практических разборов ИИ, open source и инструментов — в Telegram: @faktosborka

Источник о возможностях Codex: официальная документация OpenAI