08.05.2026 18:33
Ansud 26 13000 Источник

На дворе май 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}, где U = 10^6 — число пользователей клода, O = 20 — среднее число запросов в сутки. Считаем… E = 4.5. Ой. Кажется раз в сутки у нас происходит 4.5 инцидента среди всех пользователей клода. Уже более пугающе, хотя мы то знаем, что нас это не коснется. Мы не такие и вообще отрицаем эти противные цифры. Это будет с кем-то другим, плохим, но точно не с нами. Но повод задуматься, конечно уже есть.

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

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

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

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

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

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

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

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

\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 за месяц. На это потребуется слегка больше времени. Но, итог един — это все равно не спасет от того, что зарплата младшего заведующего по пыли станет зависеть от цвета шрифта в логах, внесенное в очередном приступе решения задачи клодом.

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

Комментарии (26)


  1. Android1983
    08.05.2026 18:51
    #29946928

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


    1. Yevgeny_VS
      08.05.2026 18:51
      #29946952

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


    1. hssergey
      08.05.2026 18:51
      #29947828

      Как научиться программировать так чтобы данные с которыми я работаю не утекали и сколько примерно времени нужно чтобы этому научиться?

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


    1. Astrowalk
      08.05.2026 18:51
      #29948424

      Ну вот, есть самое главное – осознание, что ты криворучка (кстати, почему вы пишете «задачь», но не «криворучька»? Выглядит недоработкой ☺). А значит, надо выпрямлять руки, то есть учиться. И учиться долго, систематически. Нет царского пути в геометрию.


    1. rPman
      08.05.2026 18:51
      #29948584

      Ответ душнилы - ты не можешь.

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

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


  1. Gutt
    08.05.2026 18:51
    #29947220

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


    1. Ansud Автор
      08.05.2026 18:51
      #29950570

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


  1. vitalist84
    08.05.2026 18:51
    #29947756

    У Вас вероятность, что человек глючит - 0.15, а что нейронка - 0.03. Все дальше можно не считать. Человека на пенсию, он и есть главный багодел тут, обезьяна с гранатой. Причем оно ведь и в реальности так - разработчики пишут код с ошибками, потом долго сидят под отладчиком и хмурят брови, потом пишут тесты, потом отдают в отдел QA, потом в отдел проверки безопасности, потом переделывают. И вот тогда получается более менее надежный код.

    И на каждом этапе тоже есть вероятность допустить ошибку. Вот задача Anthropic сделать вероятность ошибок Claude Code < вероятности ошибок человека.

    Цепочку разработки с проверкой качества вайбкодеры не освоили в этом их проблема. Решений может быть два на этот случай:

    1. Это нужно активно продвигать на курсах вайбкодинга.

    2. Вшить проактивные навыки проверок качества на уровне Claude code и сделать их обязательными.

    Пока до этого далеко, но со временем придут к какому-то решению.


    1. gabirx
      08.05.2026 18:51
      #29948266

      а пустые тесты которые всегда проходят это и есть проверка качества от llm


      1. pomponchik
        08.05.2026 18:51
        #29948828

        Пустые тесты ловятся машинерией на базе мутационного тестирования.


    1. Ansud Автор
      08.05.2026 18:51
      #29950596

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


    1. HardlinePeak936
      08.05.2026 18:51
      #29950836

      Зато человек лучше пишет не-ошибочный код, что уже перевешивает провал по ошибочному. Разве нет? Зависит от ситуации, но в общем случае?

      И проверяет ошибочный и не-ошибочный тоже качественнее. Впрочем, медленнее, тут не поспоришь. А насчёт дешевизны нужно считать — сколько в мире уходит на людей / сколько в мире людей — и сравнивать — сколько в мире уходит на ИИ X / сколько в мире экземпляров (пользователей?) этого ИИ. В долларах.

      К слову, вовсе не интересно, сколько там уходит на электроэнергию у ИИ — нам важны токены/подписки в сравнении с ЗП, а не сколько и на что из этой прибыли тратиться (человек тоже себе покушать покупает ;).


  1. pilot114
    08.05.2026 18:51
    #29949044

    В те стародавние времена, когда ИИ не использовалось в разработке) мы много раз были свидетелями маштабных факапов, когда разработчик перепутал терминалы, на автомате скопировал не ту команду, просто по усталости или запарке не протестировал новый код. Мы видели это в публичном поле, на примерах коллег и собственном опыте. То что вы рассчитали в статье как 4.5 критические ошибки на миллион программистов, которые пишут по 20 коммитов в день - это неимоверный, непостижимый уровень качества. Сравните с любыми открытыми отчётами по качеству кодовых баз.

    Хватит пороть чушь про общую деградацию. Есть отдельно безответственность, которая вкупе с некомпетентностью является главной причиной ошибок ПО. И есть просто инструменты. ИИ это инструмент. Да, кода стало больше. Но я ответственно заявляю, что среднее качество этого кода ВЫШЕ среднего качества кода 10-20 лет назад. Именно среднего, раз уж мы берем общую температуру по индустрии.

    Давайте уже наберемся мужества признать, что всеобщая доступность такого инструмента - это не проблема новичков, которым снизили порог входа. Это не проблема пользователей, которые получают результат сразу. Это проблема опытных разработчиков. На них (на нас?) ответственность задавать планку качества и внятно определять критерии этой планки. Не ныть в духе "хоспаде, нас завалят нейрослопом", а обучать новичков, показывать проблемные места коде, развивать инструменты валидации. Надо принять достойно смерть профессии в её первоначальном понимании.

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

    p/s/ извиняюсь за излишнюю эмоциональность, я тут обращаюсь не лично к автору, а скорее к устоявшемуся мнению, которые расцениваю как в корне неверное


    1. rPman
      08.05.2026 18:51
      #29949424

      повышение количества низкокачественной рабочей силы породило невероятно неэффективный код.

      что сделает повышение количества сгенерированного кода? умножит неэффективность на два? возведет в степень? или наоборот


      1. pilot114
        08.05.2026 18:51
        #29949802

        повышение количества низкокачественной рабочей силы породило невероятно неэффективный код

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

        что сделает повышение количества сгенерированного кода? 

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


        1. rPman
          08.05.2026 18:51
          #29949884

          Заметьте, я не давал оценки, я просто констатировал факт.

          B ваше - 'не нравится, не пользуйтесь', не аргумент. Выбора фактически нет, есть только его иллюзия.


    1. smt_one
      08.05.2026 18:51
      #29950096

      Да, я гордо зову себя луддитом. В оригинальном смысле, не в ругательном. Да, существуют технологии, которые не решают реальные проблемы, а только создают новые (часто в виде эрозии трудовых прав).


    1. Gnomus09
      08.05.2026 18:51
      #29950600

      Цитата на египетской стеле из гробницы Хепи (ок. 3000 лет до н.э., найденной в Гизе)

      "Мы отказались от традиций наших предков... дети больше не слушаются... всё рушится, и нет того, кто бы возродил порядок".

      Существует множество примеров из истории, в которых можно найти такой же страх. Автомобили заменили лошадей, лампы заменили свечи, телефон - письма, интернет - книги и т.д.
      Сейчас, как и тогда, многие люди боятся признать новую эру, но она реально наступает. ИИ внедряется не только в нашу жизнь, делая её проще, но и в производство, бизнес или сельское хозяйство. ИИ заменяет целые профессии. Страшно... нет. Мир изменился, надо к нему приспосабливаться, находить новые ниши.
      P.S. Развивать голову никто не отменял)


      1. mckeenly15
        08.05.2026 18:51
        #29951156

        ИИ заменяет целые профессии.

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

        Развивать голову никто не отменял

        Да, учитесь думать своей головой, а не просто верить обещаниям продавцов лопат, которые рекламируют лопаты)


  1. gybson_63
    08.05.2026 18:51
    #29949228

    Перестать писать код надо было еще лет 15 назад. Совсем. А то удивляются, что "Hello world" "гигабайты" весит. Уже и так писали одно и то же по сотому кругу. Ну вот теперь это ИИ будет делать.


  1. Dron007
    08.05.2026 18:51
    #29949702

    Цифры с потолка, методика ещё из какой-то части тела, но результаты почему-то нравятся и обсуждаются всерьёз. С чего бы вдруг проекту расползаться куда-то, а уборщицам увольняться? Что мешает покрывать тестами, ревьюить ревьюерами и рефакторить проект не за месяцы, как это сделала бы команда программистов, а за часы с LLM-кой? И это, учитывая, что те LLM, что есть сейчас это самые тупые LLM из всех, что будут созданы в будущем. Firefox поддерживается большой командой, благо Google спонсирует, но LLM нашла за месяц (а реальное время работы, думаю, измеряется в нескольких днях) дырок больше, чем они все за год. Но вот откуда-то идея про расползающиеся проекты. Конечно, пока ими занимаются жертвы курсов по успешному успеху, ожидать чего-то серьёзного от проектов не стоит. Но этот этап быстро проходит и максимум, что может развалить менеджер - проект по учёту калорий в съеденной еде, то бишь личные проекты.


    1. DanielKross
      08.05.2026 18:51
      #29949788

      Когда будут "самые умные", программисты уже точно не будут нужны.


    1. Ansud Автор
      08.05.2026 18:51
      #29950610

      Да, нашло дырки и не только в firefox. Только вот если начать делать “plz fix”, то дырок станет больше. LLM не умеет думать и решает проблему самым простым способом, не рассчитывая на то, что это еще и поддерживать потом надо. Код постоянно дублируется, потом в этих дублях находится ошибка, а фиксится только в части из них. Вынести дубли в отдельную функцию? Выносить куски в отдельные модули? Не, надо все в один файл сложить и норм. Работает же, тесты проходит…


      1. Dron007
        08.05.2026 18:51
        #29950818

         Код постоянно дублируется

        Бывало раньше, но давно такого уже не наблюдаю. В любом случае, один промпт (если его уже не добавили в системном промпте или где-то в обвязке) и модель найдет и поулучшает что надо. Возможно, не всё будет идеально, но и люди не пишут идеально. А вообще по большому счёту важно да, чтоб работало и какие-то неоптимальности кода, ни на что особо не влияющие, не так и важны. Вот я писал себе телеграм юзербота на Пайтоне, которого особо и не знаю и Telethon именно исходя из того, чтобы он просто выполнил мне нужную задачу. Под 100 килобайт кода, 2650 строк и довольно удобная чисто практическая утилита анализирующая группы по заданным правилам и собирающая нужную информацию. В коде не вижу явных дублирований и струкрура на вид простая, если прям сильно надо будет, разберусь. Но мне нужна выполняемая кодом работа, а не код. В рабочем коде, конечно, всё контролирую, иногда вижу неоптимальности, избыточности, уточняю что это реально ненужные вещи, а не что-то чего я не понимаю, прошу удалить лишнее. Вполне нормальное выходит.


  1. sdramare
    08.05.2026 18:51
    #29950382

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

    А давайте допустим не 0.03, а 0.99. Или 0.0000000001. Что это "аналитика" на случайных числах? И этот человек еще жалуется на LLM.


  1. Xumuk76
    08.05.2026 18:51
    #29951932

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