Управляемая разработка с Codex

Проверено: 20 июля 2026 года.

Цель — сохранить скорость «вайбкодинга», но заменить доверие к правдоподобному ответу проверяемым инженерным циклом. Чем выше риск, тем меньше допустима работа «по ощущению».

1. Сначала понять среду

До правок Codex должен:

• определить корень проекта и стек по реальным файлам;
• прочитать ближайшие AGENTS.md, README и документацию разработки;
• проверить состояние рабочего дерева и не затрагивать чужие изменения;
• найти штатные команды тестирования, анализа, сборки и запуска;
• отметить неизвестные факты, особенно версии, внешние сервисы и production.

Не начинать с генерации нового каркаса, если проект уже задаёт архитектуру и соглашения.

2. Сформулировать контракт задачи

Хорошая постановка содержит четыре части:

Цель: какой наблюдаемый результат нужен.
Контекст: где менять и что уже известно.
Ограничения: что нельзя менять, требования совместимости и безопасности.
Готово, когда: тесты, поведение и артефакты, подтверждающие результат.

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

До предложения собственной инфраструктурной реализации проверить существующий код, возможности фреймворка и зрелые библиотеки по REUSE.md.

3. Планировать пропорционально риску

• Малая локальная правка: кратко определить файл, изменение и проверку.
• Несколько компонентов: вести план с одним активным шагом и критериями завершения.
• Миграции, auth, платежи, безопасность, инфраструктура: отдельно описать риски, совместимость, резервную копию и откат.
• Долгая работа: хранить утверждённый план в проектном docs-файле, если это принято в репозитории.

План — не церемония. Он должен уменьшать неопределённость и обновляться при появлении фактов.

Для сложной задачи отделять роли: быстрый Explorer собирает факты, сильный Planner принимает архитектурные решения, Worker реализует утверждённый срез, независимый Reviewer проверяет результат. Модельный маршрут и границы параллельности описаны в ORCHESTRATION.md.

4. Реализовывать узкими вертикальными срезами

• Сначала минимальное изменение, которое можно проверить целиком.
• Использовать существующие абстракции и стиль проекта.
• Не смешивать исправление с попутным рефакторингом.
• После каждого значимого среза запускать ближайшую дешёвую проверку.
• Внешние зависимости добавлять только при доказанной необходимости.
• Не маскировать ошибку отключением теста, анализа или защитного механизма.

5. Проверять доказательствами

Последовательно использовать применимые уровни:

1. Целевой тест или воспроизведение дефекта.
2. Связанные тесты модуля.
3. Formatter, lint, static analysis и type checking.
4. Сборка или контейнерный smoke-check.
5. Проверка итогового diff и поведения на границах.

Фраза модели «должно работать» не является проверкой. Если проверку невозможно выполнить, в отчёте явно разделить проверенное и непроверенное.

При дефекте сначала воспроизвести его и сделать среду наблюдаемой. Использовать готовые трассы, browser/devtools, query plans и framework-инструменты по DEBUGGING.md, а не перебирать правки вслепую.

6. Завершать коротким отчётом

Отчёт должен отвечать на четыре вопроса:

• что изменено и где;
• почему выбран этот вариант;
• какие проверки фактически выполнены и с каким результатом;
• что осталось непроверенным, какие есть риски или ручные действия.

Не выдавать создание кода за завершение задачи, если обязательные проверки не пройдены.

7. Превращать ошибки в инфраструктуру

Если одна и та же проблема повторилась:

• проектное соглашение кратко закрепить в ближайшем AGENTS.md;
• подробное объяснение поместить в docs;
• повторяемый workflow оформить как skill;
• механически проверяемое правило перенести в тест, линтер, CI или hook.

Это согласуется с практикой OpenAI: давать агенту карту репозитория, а не огромную инструкцию, и усиливать среду наблюдаемостью и обратной связью (Harness engineering).