Как не дать Codex случайно выбрать стек: правила проекта и ревью зависимостей
Codex ускоряет разработку, но без правил проекта может незаметно начать принимать архитектурные решения вместо команды. Он видит задачу, ищет быстрый путь и может сам выбрать библиотеку, пакетный менеджер, фреймворк или обходную реализацию. Иногда это помогает. Иногда через месяц в проекте появляется зависимость, которую никто сознательно не выбирал.
Проблема не в том, что агент "плохой". Проблема в пустом месте, где должны быть правила. Если проект не говорит, какой стек считается нормой, какие зависимости можно добавлять, где нужен вопрос человеку и какие команды обязательны после изменения, Codex будет достраивать это из контекста. Для черновика это терпимо. Для живого продукта уже риск.
Публичное исследование Amplifying про то, как coding agent влияет на выбор пакетных менеджеров, хорошо показывает сам класс проблемы: агентный инструмент может становиться не только исполнителем, но и каналом выбора технологических решений. Для Codex практический вывод простой: стек надо описывать как часть задания, а не надеяться, что он угадается.
Что здесь меняется
Раньше разработчик сам открывал документацию, выбирал библиотеку и писал код. Теперь агент может сделать несколько шагов подряд: найти решение, добавить пакет, поменять конфиг, переписать компонент и запустить тест. В этом режиме "маленькая зависимость" уже не маленькая. Она становится решением, которое влияет на сборку, безопасность, поддержку и будущие задачи.
У OpenAI для Codex есть отдельная идея проектных инструкций через AGENTS.md. В практическом смысле это место, где репозиторий говорит агенту: вот как здесь работать, вот команды проверки, вот стиль правок, вот зоны, где нужно остановиться. Для управления стеком такой файл особенно полезен, потому что правила лежат рядом с кодом, а не живут только в голове владельца проекта.
Главное:Codex не должен сам выбирать стек там, где выбор влияет на поддержку проекта. Если библиотеку, пакетный менеджер или фреймворк можно добавить только после явного правила, агент становится исполнителем решения, а не скрытым архитектором.
Что закрепить в проекте
Политика стека не должна быть большой. Нужна короткая карточка, которую можно прочитать за минуту и использовать в каждом запуске Codex.
| Что закрепить | Зачем | Где хранить |
|---|---|---|
| Основной язык и версия | чтобы агент не тащил параллельный стек | AGENTS.md, README, конфиги |
| Пакетный менеджер | чтобы не смешивались npm, pnpm, yarn или другие варианты | AGENTS.md и lock-файл |
| Разрешенные библиотеки | чтобы агент использовал уже принятые решения | раздел "dependencies policy" |
| Запрет тихих зависимостей | чтобы новый пакет требовал объяснения | правило ревью |
| Команды проверки | чтобы изменение не считалось готовым без теста | AGENTS.md |
| Зоны без автоправок | чтобы агент не трогал платежи, миграции, деплой | отдельный список запретов |
Такой слой нужен не только большим командам. В одиночном проекте он даже важнее: человек часто дает Codex задачу голосом или коротким сообщением, а потом забывает уточнить ограничения. Файл правил компенсирует эту усталость.
Как выглядит хорошее правило
Плохое правило звучит так: "пиши аккуратно". Codex не может надежно проверить аккуратность. Хорошее правило звучит конкретно: "не добавляй новые npm-пакеты без отдельного объяснения причины; если зависимость нужна, сначала предложи вариант без нее; после изменения запусти npm test и покажи diff".
Это превращает размытое ожидание в рабочий коридор. Агент понимает, что можно делать сразу, а где нужен вопрос. Человек получает не спор о вкусе, а проверяемое изменение: вот почему нужна зависимость, вот где она добавлена, вот чем проверено.
Рабочая карточка
Когда использовать: когда Codex работает в репозитории, где есть живой продукт, команда, сборка, деплой или поддержка.
Что подать на вход: цель задачи, текущий стек, разрешенные библиотеки, запреты, команды проверки и правило для новых зависимостей.
Что сделать по шагам:
- Создать или обновить AGENTS.md в корне проекта.
- Записать основной стек: язык, пакетный менеджер, фреймворк, тесты.
- Отдельно написать: "новые зависимости без объяснения не добавлять".
- Добавить команду проверки, которую Codex должен запускать после правки.
- В задаче просить не только результат, но и diff с объяснением архитектурных решений.
- Для спорных изменений оставлять статус "нужно решение человека".
Какой результат получить: Codex делает правку внутри принятого стека, а не расширяет проект по своему вкусу.
Как проверить качество: нет неожиданных библиотек, lock-файл изменился только осознанно, тесты пройдены, diff узкий, в ответе есть причина выбора.
Когда не использовать: если это одноразовый прототип, где стек действительно можно выбирать свободно.
Какой навык из этого собрать: навык управления технологическими решениями агента. Человек учится давать Codex не только задачу, но и границы выбора.
Где здесь связь с безопасностью
Безопасность Codex часто представляют как вопрос прав доступа: можно ли запускать команду, можно ли писать файл, можно ли выходить в сеть. Это важно, но есть еще мягкая безопасность архитектуры. Проект может не сломаться сразу, но стать тяжелее, дороже и менее понятным из-за тихих решений.
В статье про безопасный доступ Codex мы уже разбирали права, песочницу и ревью. Политика стека добавляет еще один слой: агенту можно доверять выполнение, но не обязательно доверять выбор направления. Лучший режим такой: человек задает технологические рамки, Codex быстро работает внутри них, а выход за рамки оформляется как явное предложение.