Прототип держал одного человека, а на пятидесяти лёг — что ломается в навайбкоженном проекте

Прототип держал одного человека, а на пятидесяти лёг — что ломается в навайбкоженном проекте

Проект, собранный в Claude Code за выходные, обычно работает идеально. Ровно до того дня, когда им начинают пользоваться не только автор и двое коллег.

Дальше происходит одно и то же. Бот перестаёт отвечать половине людей. Кнопки крутят вечный индикатор. Заявки из формы то приходят, то нет, и закономерности не видно. Владелец открывает агента, просит починить, агент чинит, а через день всё повторяется в другом месте.

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

Мест, где это ломается, три. Первые два ломаются одинаково у любого кода, включая безупречный человеческий.

Чем прототип отличается от продукта

Прототип отвечает на вопрос «а так вообще можно?». Ему достаточно один раз сработать на одном пользователе, который знает, куда нажимать, и который сам же эту кнопку и заказал.

Продукт отвечает на вопрос «а если так будут делать каждый день и не только я?». Всё это появляется от количества: люди приходят одновременно, делают одно и то же по многу раз, ошибаются и вводят не то.

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

Почему пятьдесят

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

Проверить прототип на одновременность, сидя за ним в одиночку, невозможно физически. Агент её тоже не проверяет, потому что просьба «а теперь пусть пятьдесят человек нажмут одновременно» в заказе не звучала.

Из-за этого граница ощущается как обрыв. Вчера работало, сегодня нет, изменилось только количество людей.

Первое: внешние сервисы начинают отказывать

Первой обычно отказывает платформа, к которой проект подключён. У каждой такой платформы есть задокументированные лимиты, и на одном пользователе в них упереться невозможно.

Telegram, например, прямо пишет в документации для ботов: в одном чате нельзя отправлять больше одного сообщения в секунду, в группе — больше 20 сообщений в минуту, а массовая рассылка ограничена примерно 30 сообщениями в секунду. Платная рассылка поднимает потолок до тысячи.

Тестовый бот в эти лимиты не упирается никогда. Бот, которым пользуются пятьдесят человек и который в конце дня рассылает им всем сводку, упирается в них с первой же рассылки. Telegram при этом не ломается и ничего не сообщает пользователю, он просто перестаёт принимать часть сообщений, и сводка доходит не всем.

Так же устроены платёжные шлюзы, почтовые сервисы и сервисы рассылки кодов. Лимиты у всех разные, поведение одинаковое: до порога всё идеально, за порогом часть запросов молча теряется.

Код здесь ни при чём. Разработчик с двадцатью годами опыта написал бы то же самое, если бы ему не сказали про рассылку на пятьдесят человек.

Второе: база данных встаёт в очередь

Агент почти всегда предлагает SQLite. Она не требует отдельного сервера, лежит одним файлом рядом с проектом и не требует настройки вообще, так что для прототипа это правильный выбор.

Ограничение у неё написано в официальном FAQ. Читать базу могут сколько угодно процессов одновременно, а менять её в каждый момент времени может только один. Когда второй процесс обращается к заблокированному файлу, он получает ошибку SQLITE_BUSY.

На одном пользователе записи в базу идут по очереди сами собой, и до блокировки дело не доходит. На десятках запись становится параллельной, и часть операций начинает возвращать эту ошибку. Снаружи это выглядит как «заявка не сохранилась», без всякого сообщения, потому что обрабатывать SQLITE_BUSY агента никто не просил.

Чинится это переездом на базу с сервером, вроде PostgreSQL, где параллельная запись заложена в саму базу. Данные при этом переносятся целиком, а весь код, который к базе обращается, приходится проверить заново — агент делает и то и другое, если ему сказать, куда переезжаем.

Третье: код перестаёт поддаваться правкам

Третье место ломается по свойству того способа, которым код писали.

Компания GitClear разобрала 623 миллиона изменений в репозиториях за 2023-2026 годы и опубликовала сравнение по восьми признакам качества. Дублирование блоков кода за это время выросло на 81% — с 40,3 до 73,0 на миллион изменённых строк. Копирование внутри одного коммита выросло на 41%. Конструкции, маскирующие ошибку вместо её обработки, — на 47%. А доля строк, связанных с рефакторингом, то есть признак того, что код приводят в порядок, упала с 21% до 3,8%.

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

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

Как отличить одну поломку от другой

Снаружи все три выглядят одинаково — «перестало работать». Отличить их можно по тому, кого задело, когда задело и что видно в логах.

Лимит платформы накрывает всех сразу и всегда в один и тот же момент: при массовом действии, обычно рассылке или уведомлении. Пользователи жалуются все разом и в одну минуту. В логах при этом ошибка приходит от чужого сервиса, и в ней стоит Too Many Requests или код 429.

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

От дублирования логики страдает тот, кто ходит нестандартным путём: заходит через другую кнопку, возвращается назад, начинает с середины. Симптом самый неприятный из трёх, потому что ошибок в логах нет вообще — код сработал как написан, просто это был не тот код.

Разобраться по этим трём признакам быстрее, чем чинить наугад. Агент чинит ровно то, что ему назвали, и первым делом переписывает то место, куда ткнули.

Отказы такого рода предприниматели разбирают между собой обычно уже после того, как починили — с точными симптомами и с тем, что в итоге оказалось причиной.

Что из этого чинится без программиста

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

База чинится переездом, и это тоже посильно. PostgreSQL поднимается на том же сервере, а перенос данных агент напишет сам. Не поймёт он только одного — что переезжать пора.

Дублирование не чинится, пока проект растёт. Помогает привычка: перед каждой правкой просить агента сначала найти все места, где встречается та же логика, и только потом менять. Это добавляет одну строчку в запрос и убирает большую часть сюрпризов.

Привычка эта закладывается на первой неделе работы с агентом, про которую у нас есть отдельный чек-лист.

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

Заметить, что пора чинить, при этом придётся самому. Ни лимит платформы, ни блокировка базы, ни расхождение копий не пишут владельцу письмо — все три проявляются как жалоба пользователя на то, что «не работает», и только после этого превращаются в задачу.

FAQ

На скольких пользователях ломается навайбкоженный проект?

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

Это проблема нейросети или любого кода?

Два из трёх мест ломаются у любого кода. Лимиты внешних платформ и однопользовательская база не зависят от того, кто писал проект. Третье место, дублирование логики, усиливается именно при работе с агентом, и это подтверждается цифрами GitClear.

Что чинить в первую очередь?

Лимиты внешних сервисов. Отказ проходит тише всего и накрывает всех пользователей разом.

Нужен ли программист, чтобы это починить?

Для первых двух мест — нет, если известно, в чём дело. Диагностика здесь сложнее починки. Агент почти всегда чинит то, что ему назвали, и почти никогда не находит причину сам.

Заключение

Навайбкоженный проект ломается на переходе от одного пользователя к полусотне, и ломается в трёх местах: внешние лимиты, база данных и собственное дублирование кода. Первые два — свойство любой системы, третье — плата за скорость, с которой проект собрали.

Все три отказа известны заранее и не требуют переписывать проект с нуля. Хуже другое: ни один из трёх не сообщает о себе сам, и владелец узнаёт о поломке от пользователей.

Такие переходы предприниматели проходят примерно в одном порядке. Забирай эти три места заранее, если не хочешь узнавать про них от своих пользователей.