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