Почему идеальный ИИ-код превратит ваш сервер в пепелище

[Antonbb]

Разберем очередной высер из Твиттера: "Забудьте про людей-программистов, ИИ пишет код лучше".
Ага, конечно. Менеджеры начитались этих сказок, поувольняли нормальных бэкендеров, насажали джунов промптить Cursor, а потом прибегают к админам с горящей задницей: "Ой, у нас платежный шлюз молча теряет транзакции, а пользователи качают платный софт бесплатно, почини!".

Почему ИИ-код горит зеленым на тестах, но дохнет в реальном продакшене? Потому что все эти хваленые кодинг-бенчмарки выдают моделям награду за бинарный результат: прошел тест или свалился. Модель вообще не думает про архитектуру, лимиты памяти или race conditions. Ей плевать. Чтобы пройти тест, она тупо пихает дикие костыли, бездумные касты типов и классика жанра - пустые блоки catch {}, которые молча замалчивают системные ошибки.

В итоге ты получаешь в репозиторий внешне "глянцевый", идеальный код, который работает... пока сеть на хостинге не моргнет на полсекунды. Поймал ИИ-скрипт таймаут от API платежки, сработал его кривой внутренний декоратор retry_on_timeout, который модель нагуглила в своих весах, вернул None вместо ошибки, и бэкенд посчитал, что заказ оплачен за 0 рублей. Юзеры счастливы, фаундер банкрот.

В исследовании "To Retry or Not to Retry" Грамли четко показал: когда сервер выдает ошибку 503 и просит подождать, 6 из 8 топовых моделей слепо спaмят ретраями, рискуя списать бабло с клиента дважды, потому что у них в башке нет понятия об идемпотентности и логике распределенных систем.

Настоящий бэкенд-инженер ценен не тем, сколько строк кода он намолотил в минуту. Он ценен своей инженерной мудростью и способностью НЕ писать код там, где можно без него обойтись. Любая строчка кода в вашем репозитории это потенциальная уязвимость, баг и налог на дисковое пространство и память сервера.

Настоящий сеньор решает проблему тремя строчками в конфиге Nginx, а ИИ-скрипт нахерачит под это дело прожорливый микросервис на Node.js.

ИИ это нормальный автоматический молоток для рутины, но он никогда не заменит архитектора. Если вы отдадите управление кодовой базой на откуп моделям, вы просто захлебнетесь в нечитаемом легаси-мусоре, который никто не сможет отрефакторить.
Кто уже разгребал ночные краши после того, как "идеальный" ИИ-код тихо замалчивал таймауты в проде?

[teraferma]

Antonbb, в примере с retry_on_timeout корень в платёжном флоу без идемпотентности, модель его только подсветила. Таймаут на оплате означает «статус неизвестен». Ретраить её можно только с ключом идемпотентности, как Idempotency-Key у Stripe, а потом сверять статус платежа или ждать вебхук. «Поймал таймаут и вернул None» при этом не увидит ни линтер на голые except, ни mypy, если wrapper декоратора не типизирован через ParamSpec и TypeVar. Надёжнее тест, который роняет платёжку по таймауту и проверяет, что заказ не стал оплаченным.