Автор Habr назвал пять решений, которые инженер принимает до кода от AI

Один из самых неприятных багов в платёжной логике выглядит безобидно: проверить, что операция в статусе PENDING, перевести её в SUCCESS и начислить баланс. Если два webhook'а приходят одновременно, оба видят PENDING, оба проходят проверку, и пользователь получает деньги дважды. Автор свежего материала на Habr нашёл такую ошибку в собственном маркетплейсе. Код он писал сам, без AI.

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

Где спецификация молчит

Агент хорошо выполняет то, что описано. Фраза «при успешном webhook'е начислить баланс» формально выполняется и в корректной, и в уязвимой реализации. Разница проявляется только под параллельной нагрузкой, а в тестах на одном потоке её не видно.

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

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

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

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

Как это обычно решается

Для истории с webhook'ами типовой набор мер известен. Уникальный ключ события или идемпотентный ключ запроса. Атомарное условное обновление вида «перевести в SUCCESS, только если статус всё ещё PENDING» и проверка числа затронутых строк. Блокировка записи на время транзакции. Любая из этих мер превращает «проверил, потом записал» в одну неделимую операцию.

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

Как использовать на практике

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

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

Наконец, тесты. Для платёжных путей нужен хотя бы один тест с одновременными запросами, иначе проверка корректности остаётся на уровне «выглядит правильно». Именно так выглядел обработчик в истории автора: логика читалась как верная и ломалась только при гонке.

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