28.04.2026 06:54
DragorWW 181 89000 Источник

В каком-то смысле у всех снова обнулился опыт

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

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

Параллельно с этим очень заметно набирает силу разработка маленькими командами

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

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

И вот тут начинается самое интересное. Чтобы это работало, тебе нужны не идеальные процессы. Тебе нужна автономия, право быстро тестировать гипотезы, доставлять их и ошибаться не умирая от этого.

Бюджет на ошибки как часть системы

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

А что это вы так засиделись, где более радикальные эксперименты?

И это очень здравая мысль. Потому что движение компании это и есть жизнь. Как только она закрывается в старых процессах, она начинает стагнировать. Развитие почти всегда происходит через эксперименты.

Я вообще не устану повторять, что все самые крутые вещи, которые я видел внутри компаний, обычно рождались не из процессов, а в свободное время от процессов.

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

Даже далеко ходить не надо.

Тот же Claude Code у Anthropic, который взорвал рынок агентской разработки, по сути вырос из внутреннего эксперимента, нишевой инициативы, которая просто начала вирусно распространяться по компании. И теперь это один из их флагманских продуктов.

Вот как такое заранее спланировать? Как искусственно вырастить инновацию? Может, как-то и можно. Но я пока не знаю другого пути, кроме такого: ограничения, цель, свободное время, право на ошибку, процессы, которые этому помогают, и люди, которым это реально интересно.

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

Смешно, что недавно у Anthropic утёк исходный код Claude Code

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

Тут очень в тему старая мысль Маска

Самая частая ошибка в том, что люди начинают автоматизировать то, что сначала надо было упростить или вообще удалить.

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

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

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

Добро пожалость в NG+, введи любой промт что бы начать. Удачи!

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


  1. NeoNN
    28.04.2026 07:09
    #29896452

    Золотое, да, прям золотой дождь.


    1. BloodHunterD
      28.04.2026 07:09
      #29896744

      Я хотел оставит тоже коммент :( А вообще думаю основная проблема в том что может сейчас и золотое время для кого-то, а для кого-то нет. Надо по такой метрике смотреть а не приводить рассуждение как докозателтсво статистики.


      1. 87z6mD
        28.04.2026 07:09
        #29897822

        "Что вы волнуетесь за этих людей? Ну, вымрет тридцать миллионов. Они не вписались в рынок. Не думайте об этом — новые вырастут"(с)


        1. AuroraBorealis
          28.04.2026 07:09
          #29902224

          И ведь действительно - 18, кажется, миллионов не вписались, новые выросли.


          1. Arhammon
            28.04.2026 07:09
            #29902974

            Это с очень натянутыми на глобус косвенными потерями - типа потенциально не рожденные в 90х люди, если экстраполировать аномально высокую рождаемость 80х...


        1. AKudinov
          28.04.2026 07:09
          #29902916

          Судя по всему, это цитата кого-то известного. А кого?


          1. Alexandroppolus
            28.04.2026 07:09
            #29903228

            То ли Гайдара, то ли Чубайса


            1. AKudinov
              28.04.2026 07:09
              #29904286

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


    1. mmMike
      28.04.2026 07:09
      #29897160

      “Золотой дождь” да… почему то первая ассоциация - это термин из сексуальных девиаций.

      Наверное потому, что вчера потратил пару часов на поиск странной баги. Оказалось, LLM решила, что Long от null строки, нужно как 0 (число), а не null

      ну верьте верьте… впрочем, статья тоже LLM написана. Мусорная


      1. TimurZhoraev
        28.04.2026 07:09
        #29897742

        А в каком языке это null а не исключение. Даже в С это классический null pointer assignment/read и обычно вываливается в исключение, да и во многих принято делать обработчики. В этом случае необходимо модели явно указывать что делается при преобразованиях типов данных, особенно когда заведомо известно что может прилететь null. Равно как деление на ноль - если есть такие формулы то необходимо явно указывать проверку. Модель учится на множествах примерах, поэтому исключение это типовой случай, а если пользователю необходимо if(null) then null else continue, то это выбивается из правил и необходимо это явно обыграть.


        1. maldalik
          28.04.2026 07:09
          #29897878

          SQL?


        1. Nikita22007
          28.04.2026 07:09
          #29899098

          Я так понимаю, имелось ввиду, что ии написал

          Long val = (s == null)? 0 : Long.valueOf(s);

          А ожидалось

          Long val = (s == null)? null : Long.valueOf(s);

          (Long - объект и может быть null, long - примитив)


          1. Wesha
            28.04.2026 07:09
            #29899352

            А что Вы хотели от системы, обученной на материалах со Stack Overflow?


          1. TimurZhoraev
            28.04.2026 07:09
            #29899504

            На любые null, void* malloc-free нужно делать очень тщательные промпт-инъекции чтобы было что то вроде

            Long val = (s == null || s.isEmpty()) ? null : Long.valueOf(s);

            исключающее исключения вроде NumberFormatException. Равно как деление на ноль с прибавлением бесконечно малой, отслеживание диапазонов итд. Это проблема промпта. ИИ вполне правильно сформулировал эту строку.

            можно даже ещё провайбкодить и получить вроде как ещё более замечательный результат. 

            public static Long toLongSafe(String s) {
    if (s == null || s.trim().isEmpty()) {
        return null; // Or 0L, depending on your preference
    }
    try {
        return Long.valueOf(s.trim());
    } catch (NumberFormatException e) {
        return null; // Returns null if the string is "abc" or "12.3"
    }
}

            Вообще говоря преобразования типов даже в динамических языках к примитивам это боль. Поэтому нужно ловить все исключения, даже когда на экране видны 123 а по факту это символы ０１２３ в Unicode. Это скорее недоработка промпта или инъекции нежели баг самой модели. В случае использования этого дела далее в качестве арифметики 0 был бы в принципе нормален без боязни словить null если он не проверен


          1. lazarus_net
            28.04.2026 07:09
            #29901970

            Как вариант самому написать библиотечную функцию и заставить ИИ ее везде использовать не рассматривался?


        1. mmMike
          28.04.2026 07:09
          #29901210

          Да какая в принципе разница. Я к тому, что LLM часто допускает “незаметные” ошибки, которые потом выливаются в неочевидные проблемы, которые не всякими тестами выловишь.

          Но, если вас интересует конкретный случай, то это тема блин импорта замещения и переписывание старого Java кода работающего с Oracle на Postgree. Oracle jdbc умеет выполнять преобразование типов и ссылку по имени. например (чисто для примера)

          String nVal = “123”;

          … pstmt= … con.prepareStatement(“… where … blablaid=:balablaid…”);

          pstmt.setObject(“balablaid”, nVal);

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

          String nVal = “123”;

          … pstmt= … con.prepareStatement(“… where … blablaid=?..”);

          pstmt.setLong(7, nVal == null? null: Long.parseLong(nVal));

          Так то LLM достаточно успешно с этой нудятиной справляется. НО… Хлобысь и где то pstmt.setLong(7, Long.parseLong(Objects.toString(nVal, “0”))); А где то адекватное pstmt.setLong(7, nVal == null? null: Long.parseLong(nVal));

          И когда такого кода N тысяч строк… то… да можно просто не заметить пару строк, где неадекватное сделано. А если внимательно смотреть - то по времени проще руками. Причем результат не детерминированный. Раз так, а в другой запрос - по другому результат.


          1. SiberianMouse
            28.04.2026 07:09
            #29901384

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


            1. mmMike
              28.04.2026 07:09
              #29901442

              Вот доводы “взяли не тот LLM, не правильно промт, нужно было найти и поправить промт/попросить исправить” Вот честно говоря достали эти доводы.

              Для того что бы найти (черную кошку в темной комнате, которой возможно и нет) - нужно все глазами просмотреть (тупая работа) и возможно (!) найдется (глаз то замылен да и совсем тупая работа). Т.е. для того, что бы исправить ошибку, нужно как минимум знать что она есть.

              Ошибки LLM (любой, с любым промтом) они

              1. не детерминированны (разные запуски - разный результат)

              2. Как правило логические (синтаксические компилятор найдет)

              3. тяжело ищутся, поскольку анализировать сгенеренный код мозг отказывается внимательно смотреть. Типа мозг говорит: “ты чего… уже все сделано. зачем эта еще тупая работа по проверке”.


              1. TimurZhoraev
                28.04.2026 07:09
                #29907446

                это не ошибка LLM а ошибка использовать её для языков, которые специально для неё не предназначены а были созданы исторически. Особенно которые перенасыщены грамматикой и смыслом, для которых вся работа программиста это trick and tips с кучей жонглёрских методов и хитростей. Это размывает возможные варианты реализации. Поэтому идеальный вариант это то что несёт минимум смысловой нагрузки с точки зрения реализации, обо всём остальном модель позаботится лучше всего это что то вроде чистого C, Python, JS/Java в режиме C, то есть с минимум выкрутасов. Необходимо делать промпт-инъекции чтобы максимально упростить вывод. Да, с точки зрения человека это уход в 80-е структурного программирования но с другой стороны - это всё генерируется автоматически, спихивая все трудности ради которых и разработаны современные языки на модель. То есть современные паттерны излишни так как лакоичность кода ценой усложнения его семантики уже под вопросом. Если итератор LLM сделает не 1 строку а 5, но, при этом, этот вывод гарантирован и влезает в контекст то собственно зачем гоняться за full language specification, достаточно BASIC уровня калькуляторов


          1. TimurZhoraev
            28.04.2026 07:09
            #29907504

            Так это уже создание тулов которые парсят этот код и находят подобного рода пробки. В этом случае необходимо просить LLM не код править а сделать тул-скрипт для парсинга с использованием внешних утилит. Вообщем что-то наподобие того что ищется по ключевым словам MCP Python Refactor или MCP Java Refactor. В этом случае он нагенерит питон/bash/ещё что которое пройдёт по всем этим 1000 строк и выявит указанные уязвимости. То есть он автоматизирует ручной поиск таких пробок. Изначально, код созданный вручную он плохо пригоден для такого парсинга. Поэтому его необходимо сначала причесать инструментами с языковой поддержкой на уровне пре-компилятора с разбором функций, аргументов, затем вытаскивать все краткие для человека сущности в переменные, код раздуется, но он будет скажем так более понятен с точки зрения векторной базы данных и копошения в нём LLM. То есть сейчас отпадает необходимость писать краткий особо хитрый код со всеми выкрутасами компилятора, наоборот, его необходимо раскручивать до понимания контекста LLM. А дальше он сам уже подставит шаблонные выражения для исключений, макросы, дебаг-инфо итд итп, найдёт возможные коллизии. Причём если код причёсан чуть ли не как маркдаун в комментах, модель справляется более чем отлично особенно для многопоточки. Мелкие баги есть но они отлавливаются прежде всего локальными тестами - это уже другая фишка, и вообще говоря правильная. На каждый исходник и функцию - обёртка из того что показывает что это работает. Для гигантских систем конечно могут быть проблемы и невозможность тестов но они по порядку величины уже сопоставимы с экспертной оценкой профи.


          1. chesser76
            28.04.2026 07:09
            #29907900

            а джуны таких ошибок не делают? )) и просто захотелось в 100500й раз пнуть LLM?


            1. mmMike
              28.04.2026 07:09
              #29908046

              Забавно, откуда у всех такая эмоциональная реакция на замечания вида “вот этот молоток удобен, но идеализировать его не надо”.

              Как будто всем “зачем нападаете на LLM”, LLM приходится близким родственником и они готовы за него вступаться “маaaленьких обижают”. :)

              Иногда даже смешно становится.


          1. Aytim
            28.04.2026 07:09
            #29908492

            "импорт замещения" доставил :-)


    1. Hadis
      28.04.2026 07:09
      #29907892

      Как и в случае с золотым дождем, есть те, кому нравится)


  1. gorchaqw
    28.04.2026 07:09
    #29897004

    Есть мнение что это просто "передел рынка" и зон влияния. Теперь кампании предлагающие нейронные сети для разработки имеют большое влияние на неё и зарабатывают с этого свой гешефт. Преимущества одиночкам?) не думаю. Конкуренцию ни кто не отменял, теперь рынок будет еще больше перегрет решениями сомнительного качества, а успех будет на стороне того продукта, чья рекламная кампания была успешнее или кто вложил в нее больше денЯг.

    Теорема Эскобара во всем её величии )))


    1. gorchaqw
      28.04.2026 07:09
      #29897104

      Вот когда нейронки заменят бездарных руководятлов - тогда заживём )))


      1. duronus
        28.04.2026 07:09
        #29897942

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


      1. hw_store
        28.04.2026 07:09
        #29899498

        ..."вы здесь"...