Нейрохрючево на бэке не видно. Пока не придёт счёт

Александр Доведин написал громкий пост про «эпидемию нейрохрючева» во фронте: одинаковые скругления, кнопки, которые висят, забытые состояния ошибок. И там мимоходом проскочило: API делают «лишь бы отвечал». Вот за эту фразу я и зацепился. Фронтовое нейрохрючево хотя бы видно. Открыл экран, увидел контейнер в контейнере, поморщился. У плохого бэкенда нет цвета и скруглений. У него есть 200 OK. Эндпоинт отвечает, тесты зелёные, демо прошло, все довольны. А потом у клиента моргает сеть, запрос приходит дважды, и деньги списываются два раза. Воркер падает на одном кривом сообщении и тихо ретраит его до утра. Запрос, который летал на сотне строк, на живой таблице превращается в N+1 и кладёт базу. Ничего из этого не видно на скриншоте. Об этом узнают, когда прилетает счёт или жалоба. Виолетта Данилова там же в комментариях заметила, что бэк это не только круды. Я 3,5 года пишу на PHP/Laravel, и по-моему круды как раз самая простая часть. Сложное начинается там, где их нет: идемпотентность, таймауты, что делать с сообщением, которое не обработалось, и кто узнает, если очередь встала. Модель всё это напишет, если ты знаешь, что попросить. Если не знаешь, она напишет красивый эндпоинт, который отвечает. Мне кажется, на бэке ИИ ускоряет не разработку, а появление долга, которого никто не видит. Татьяна Сергеевна в том же треде пишет, что починка сломанного продукта уже стоит почти как сделать нормально. На бэке, думаю, выйдет дороже: тихо испорченные данные обратно не склеишь. Пост Александра: https://setka.ru/posts/01a119b3-4a5b-74c3-913f-be43c568b336 P.S. Длинных тире в этом тексте нет, я проверил. Вопрос к тем, кто ревьюит код: по какому признаку вы сразу понимаете, что бэкенд писали «лишь бы отвечал»? Мой первый подозреваемый: catch, который ловит всё подряд и пишет в лог одно слово «error».