Миллион клодобезьян: естественный отбор вайбкодинга

На дворе май 2026 года, весь интернет заполнен статьями вида «Я запустил клод и написал свой аналог ОченьИзвестнойПрограммы». Вокруг бегают 100х девелоперы, которые на самом деле больше менеджеры, не имеющие отношения к нормальной разработке софта. Все удивительно продуктивны, гитхаб загибается от миллионов новых гениальных проектов и светлое будущее с косой уже стучится в каждый дом инженеров ПО.

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

И вот, в момент очередной тревожной бессонницы, вместе с мыслями о будущей жизни в коробке из под холодильника вместе с котами, меня посетила идея посчитать насколько все может быть плохо в этом мире. Раз у нас модели — это вероятностная поделка, то и оценивать буду их тем же оружием. Цифры взяты с потолка, никто мне их не предоставит в здравом уме. Но выглядят плюс-минус правдиво, а формулы не меняются. Можно поиграть с входящими вероятностями и подумать.

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

Очень полезный агент, приносящий пользу конкурентам

Есть несколько способов совершить что-то очень деструктивное. Классический rm -rf, который наверняка закрыт во всех агентах даже уже не промптами, но все еще может сработать, find . -delete спрятанный в неожиданном месте, terraform destroy, kubectl delete namespace или скейл в 0, походы в базу с TRUNCATE. Ну еще можно улучшить соединение с работающей VM, прописав в правилах фаерволла доступ для 0.0.0.0/0. Вариантов уничтожения и раскрытия ваших данных очень много. Иногда даже можно удалить все безвозвратно вместе с бекапами.

Значит, надо взять какие-то цифры и посчитать насколько вероятно уничтожить все. Еще раз отмечу, что цифры просто придуманы, но выглядят более-менее правдиво. Итак, что мы имеем: для одного пользователя риск на одну операцию будет равен вероятности галлюцинации модели $P_{fatal}$ умноженную на вероятность деструктивной галлюцинации $P_{err}$ , умноженной на вероятность пропуска ошибки через фильтры $P_{miss}$ , умноженной на вероятность пропуска деструктивной операции оператором $P_{human}$ . При этом отдельно отмечу, что в реальности эти вероятности зависимы, что делает общую вероятность фатальной ошибки выше. Но, для простоты расчетов и уменьшения придумывания цифр, пусть эти отказы будут независимы. Итак, формула:

$P_{fatal} = P_{err} \times P_{destr} \times P_{miss} \times P_{human}$

Допустим глючит модель с вероятностью $P_{err} = 0.03$ , при этом деструктивные глюки бывают с вероятностью $P_{destr} = 0.001$ , обвязка клода пропустит это с вероятностью $P_{miss} = 0.05$ и абсолютно правый, но усталый от нейрослоповых гоблинов оператор, пропустит ошибку с вероятностью $P_{human} = 0.15$ .

Посчитаем (конечно же при помощи нейросетей, кто же в мае 2026 считает на калькуляторе, как животное?) Итоговое число будет $P_{fatal} = 0,000000225$ . Можно расслабить булки, нам ничего не грозит! Ага, как бы не так. Это вероятность фатальной ошибки одной операции. Допустим средний уставший оператор делает около 20 запросов в день. Ну и у клода таких операторов много. Очень много. Но нам хватит всего одного миллиона. Отсюда глобально ожидаемое количество инцидентов в сутки будет считаться как то так: $E = (U * O) * P_{fatal}$ , где — число пользователей клода, — среднее число запросов в сутки. Считаем… . Ой. Кажется раз в сутки у нас происходит 4.5 инцидента среди всех пользователей клода. Уже более пугающе, хотя мы то знаем, что нас это не коснется. Мы не такие и вообще отрицаем эти противные цифры. Это будет с кем-то другим, плохим, но точно не с нами. Но повод задуматься, конечно уже есть.

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

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

Кидаем в кастрюлю по одной макаронине

Допустим Principal SWE, AI Visioner & Innovator Вася или Петя, а лучше пусть будет Сигизмунд Аристархович с тремя месяцами курсов о питоне устроился в Мюнхене в небольшой банк. Ему выдали модный макбук, подписку на клод и сервис по учету рабочего времени уборщиц правого крыла третьего этажа. И сказали: «Герр Сигизмунд, извольте реализовать функциональность учета времени и левого крыла третьего этажа». Что же может быть проще! Закатал рукава, протер кнопки 1, 2, 3 и Enter и сделал запрос в клод. Что-то вышло. Потом еще и еще… и еще… и там уже второй этаж надо добавлять. Работа кипит! 10000х продуктивность, все четыре клавиши уже стерлись до лампочек!

А я, как старый зануда, решил посчитать.

Допустим галлюцинирует клод с вероятностью . Это не деструктивное действие и код выглядит как настоящий ~~, но радости не приносит~~, пишется жадным нейрослоповым образом, с комментариями, питоновским кодом в шелл скриптах и сотней повторов, но без маркетинговой шелухи, что главное. И это очень даже консервативная оценка, так как у Сигизмунда ОКР и он весьма аккуратен. Итак, пишет промпты, болтает с клодом о гремлинах, а код пишется шаг за шагом. Вероятность ошибки на каждом новом шаге все та же - каждый шаг добавляет еще 0.0001 к шансу следующего сбоя. Только вот проблема - этот код строится на всем предыдущем коде. Можно привести аналогию с башней из кубиков: нулевой стоит твердо и четко, второй тоже, десятый уже менее устойчив, а к 50 башня таки падает. В целом, так как код чуть сложнее кубиков, то количество связей будет расти квадратично относительно размера. Но мы добрые, поэтому рост будет линеен, а значит каждый следующий шаг привносит ошибку с вероятностью $p_k = k \cdot q_0$ . Итоговая вероятность выживания проекта после шагов — это произведение вероятностей успеха на каждом шаге:

$P_{survival}(n) = (1 - p_1) \cdot (1 - p_2) \cdot \dots \cdot (1 - p_n) = \prod_{k=1}^{n} (1 - k \cdot q_0)$

Очень страшно, да и считать такое неохота, поэтому слегка упростим жизнь. Поскольку $k \cdot q_0$ — величина малая, можно использовать логарифмическое приближение:

$\ln(P_{survival}(n)) = \sum_{k=1}^{n} \ln(1 - k \cdot q_0) \approx -q_0 \sum_{k=1}^{n} k$

Вспомним школу и сумму арифметической прогрессии и получим что для шагов логарифм вероятности выжить будет (опять же приблизительно)

$\ln(P_{survival}(n)) \approx -q_0 \frac{n^2}{2}$

Дальше долго и упорно высчитываем на каком шаге вероятность проекта остаться в живых составит 0.001 (да, мы верим в Сигизмунда Аристарховича и чудеса и что проект при вероятности выжить в 0.1 еще хорошо работает, а вот при 0.001 уже нет). Подставляем значения в формулу

$\ln(0.001) \approx -0.0001 \cdot \frac{n^2}{2}$

Запихиваем в нейросеть, она пишет пару скриптов, считает и получает $n \approx 372$ . Таким образом, среднее время жизни системы — около 372 итераций. Упс. Ну можно еще позанудствовать и прикинуть, что до примерно 118 итерации будет все более-менее хорошо, если клод не решит переписать всю кодовую базу. А вот дальше накопление макаронин в кастрюле уже перестанет быть набором отдельных макаронин, а станет лапшой. Которую невозможно не то что поддерживать, ее понять становится невозможно ни Сигизмунду Аристарховичу, ни клоду с его бесконечными md файликами, скиллами и spec driven development. В общем, все радостно и с грохотом разваливается под собственным весом. Если брать все те же 20 правок в день, то через неделю проект начнет растекаться, еще через полторы недели он будет работать только при помощи ежеутренней молитвы Сигизмунда Аристарховича. Причем на этом этапе любая попытка поправить учет времени в левом крыле приводит к самопроизвольному увольнению уборщиц в правом. Так что получив первую зарплату за месяц наш герой ударяется в бега, дабы злые уборщицы его не нашли и не побили. Ну а проект переименуют в FUBAR и отправят навсегда в бекап.

Конечно все это мои выдумки: тесты, линтеры и прочие злые типизаторы не дадут проекту превратиться в FUBAR за месяц. На это потребуется слегка больше времени. Но, итог един — это все равно не спасет от того, что зарплата младшего заведующего по пыли станет зависеть от цвета шрифта в логах, внесенное в очередном приступе решения задачи клодом.

Мораль? Да нет никакой морали, каждый решает лично для себя как писать код и что делать с вездесущим ИИ. А что будет дальше — покажет только время, чай не первый раз прорывные технологии заменяют людей.

推荐订阅源

Все публикации подряд на Хабре