Главный риск — потратить много итераций на код, который выглядит завершённым, но уже не решает исходную задачу продукта.
UPS: как удерживать требования в длинной разработке с ИИ
В длинной разработке с ИИ легко получить технически аккуратный результат, который уже ушёл от исходной задачи. UPS держит требования отдельно от текущего диалога, даёт Codex только нужный контекст и проверяет результат по репозиторию, тестам и воспроизводимому запуску.
Коротко о кейсеОпределяю назначение системы, границы между требованиями и реализацией и критерии независимой проверки результата.
В проверенной версии проходили 162 теста, Git-проверки и запуск из свежего архива. Следующий шаг — проверить подход на нескольких реальных проектах.
Критерий готовности — не сообщение модели «готово», а проверяемое состояние репозитория и соответствие исходным требованиям.
Кто отвечает за цель, а кто за реализацию
UPS хранит цель и ограничения продукта; Codex отвечает за конкретные изменения внутри этих границ.
UPS: что и зачем строим
Потребность, требования, границы, важные инженерные решения и критерии приёмки.
Codex: как реализовать
Декомпозиция, порядок изменений, код и локальные исправления.
Как в длинной разработке теряется исходная цель
ИИ хорошо решает текущую задачу, но продукт состоит из множества локальных решений. Если текущий контекст начинает подменять исходные требования, можно получить технически исправную систему, которая решает уже другую задачу.
UPS хранит зафиксированные требования и критерии приёмки отдельно от текущего шага разработки.
Как проходит работа
Сначала фиксируем, что должно получиться, затем даём Codex ограниченную задачу и отдельно проверяем результат.
Потребность и границы
Зафиксировать задачу продукта, границы и критерии приёмки.
Варианты и инженерные решения
Исследовать способы реализации и сохранить важные решения отдельно от текущего диалога.
Требования и нужная экспертиза
Передать только те требования и знания, которые нужны этой задаче.
Ограниченная задача для Codex
Дать достаточно контекста для реализации, но не позволить текущему шагу переписать цель продукта.
Результат и независимая проверка
Сопоставить изменения в Git с требованиями, тестами и воспроизводимым состоянием проекта.
Что уже работает воспроизводимо
Проверяем не только отчёт модели, а конкретное состояние проекта.
Репозиторий
Чистое состояние Git и проверка fsck привязывают результат к конкретной версии.
Автоматические проверки
В одной из проверенных версий проходили 162 теста.
Воспроизводимость
Проверяется рабочий репозиторий и запуск из свежего архива.
Почему система остаётся компактной
Не добавляю отдельные базы задач и сессий, фоновые наблюдатели и дополнительные оркестраторы, пока они не нужны конкретному продукту.
Контекст и измерение
- Контекст
- Личный исследовательский проект
- Масштаб / период
- Проверенная базовая версия · 162 теста
Следующий этап
Проверить подход на нескольких реальных проектах и сравнить качество передачи требований, количество возвратов и устойчивость результата.
Есть похожая задача?
Расскажите, где SEO упирается в продукт, разработку или данные.