Уравновесим поток ура-ура новостей про ИИ.
Вот Саша Юмашев, очень крутой программист, основатель успешного SaaS-бизнеса, (лучшей) тикетницы Jitbit, подробно матерится (англ) на Claude Opus 4.6, что та не может сделать простую, монотонную работу в уже существующем проекте — заменить jQuery на ванильный JavaScript.
Текущие модели на самом деле дают гораздо более впечатляющие результаты на новых проектах (это и правда проще).
Люблю статьи Антропика, в них чувствуется живой человек, а не только пресс-релизы, как у OpenAI.
В этот раз исследователи нащупали пределы того, на что способны «команды» из агентов, работающие автономно, без участия человека: 16 агентов в параллели, в течении 2000 сессий разработали компилятор языка Си на Rust. Компилятор успешно собирает ядро линукса, QUEMU, ffmpeg, sqlite, postgres, redis, успешно проходит 99% тестов компиляторов.
Под капотом это несколько простых баш-скриптов, запускающих docker-контейнер с агентом, синхронизируется всё через git. Каждый раз, когда агент берет задачу, он коммитит файл с именем задачи в репозиторий, чтобы не было такого, что два агента работают над одним и тем же. Никакой хитрой оркестрации или «главного агента» с мастер-планом: каждый агент выбирает, что он считает самым важным, работает над этой фичей, сохраняет историю, и так в бесконечном цикле.
Звучит магически, но мне вся эта история напоминает очень крутую Машину Голдберга. Да, нейросети создают компилятор «самостоятельно», но рядом с ними 7 инженеров тратят несколько недель на филигранную настройку среды под это. Они следили, где модели затыкаются и корректировали упряжь, в первую очередь тесты и инфраструктуру, чтобы в следующий раз их не занесло.
Работу по написанию кода они заменили на работу по настройке упряжи.
И получили на выходе, конечно же, супер хрупкую штуку, которую невозможно развивать и поддерживать. Например, исследователи пишут, что так и не смогли создать таким способом работающие ассемблер и линкер, а некоторые проекты так и не скомпилировались; пытаясь исправить одну часть, нейросети ломали другую.
Это классическая ситуация, в которой оказываются команды со слишком большим техническим долгом. Тот самый легаси! Меня регулярно зовут делать аудиты и приводить такие системы в порядок, до боли знакомая картина.
В видео-анонсе Антропик пишет, что то, что заняло бы у команды людей месяцы, нейросети сделали за 2 недели. Абсолютно верно! Обычные команды разработки доходят до такого жуткого состояния легаси за годы разработки. С помощью нейросетей можно заспридранить этот процесс за 2 недели с минимальным участием людей! И стоит всего 20 тысяч долларов на API запросы!
То есть на выходе мы имеем полурабочее легаси без какого-либо пути к улучшению. Только если в обычном легаси у нас есть хотя бы углубленное понимание задачи, то в этом случае всё понимание задачи ограничивается тестами, которые они взяли на стороне как вводные для проекта. И попробуй ещё найти задачу, для которой существуют настолько же хорошие (восхитительные) тесты, как для компиляторов; человечество вложило в них человеко-годы!
Как говорил персонаж в сериале Чернобыль: «3.6 roentgen—not great, not terrible».
Гораздо важнее траектория развития способней моделей. 4-я модель «Опуса» еле-еле генерировала работоспособный компилятор. 4.5 первым прошел крупные тесты, но не мог скомпилировать реальные проекты. 4.6 вышедший на днях может компилировать реальные проекты. Что сможет следующая модель?
Исследование очень классное и тональность статьи идеальная — без лишнего хайпа. Рекомендую первоисточник.
Иллюстрация — тот самый вечный цикл, в котором крутились агенты.
Очень красивая статья про то, куда движется программирование в целом! (и как следствие, предсказание, получится ли достичь RSI и сверхинтеллекта)
Одним абзацем для опытных техдиров: разработка больших систем — это моделирование реальности, важна когерентность моделей между собой, наша главная задача — управление сложностью. Нейросети хорошо оптимизируют замкнутые задачи с быстрыми петлями обратной связи и бессмысленны, когда нужно дожидаться ответа из реального мира, а большинство настоящего софта — второго типа. Примененяя модели для изменения больших систем, мы прямо сейчас идем в ловушку, из которой потом будем мучительно выбираться.
❧
Автор умудрился объяснить суть разработки больших систем на пальцах, так что перескажу некоторые тезисы. Рекомендую почитать первоисточник.
❧
IT-системы моделируют реальный мир. В хороших программах, разные модели говорят на одном языке, автор называет это когерентностью системы. В плохих — каждая отдельная модель корректна, но они несовместимы между собой и из-за этого для каждого изменения приходится кучу всего переделывать.
Вообще, софт постоянно нужно менять из-за меняющихся требований. Поэтому, скорость и стоимость внесения изменений — это один ключевых параметров качества софта.
Обычно, с добавлением фичей, с ростом системы, её качество падает. Чем ниже когерентность — тем больше сил нужно тратить на поддержание работоспособности и тем ниже скорость доставки новых бизнес-фич. Автор предполагает, что есть переломная точка, после которой скорость доставки фичей уходит в ноль.
Все, кто работал с легаси большими системами, знают эту ловушку.
В статье очень красивая иллюстрация кода как графа и гениальная анимация того, как если с каждой фичей уделять достаточно сил на улучшение системы, то со временем она становится всё более стройной, а если чуть-чуть оставлять мусора — как уже через 100 коммитов всё превращается в клубок спагетти.
Автор очень красиво и понятно описывает задачу изменения работающих систем через замену водопровода в старом здании, перестройки парусника в линкор на плаву и корабль Тезея. Я обычно теми же словами объясняю бизнесу, что если мы возьмем супер умных чуваков и дадим им бесконечно времени — то они наверняка придумают способ, как пересобрать двигатель самолета во время полета. Но зачем?
То, что водопровод переусложнен — видно даже не-технарю. С софтом всё сложнее, мы бродим по лабиринтам кода и не можем объяснить сложность людям, которые сами в них не терялись.
Нейросети хорошо оптимизируют модели изолированных, замкнутых задач, типа шахмат или го, где небольшой набор правил описывает всю вселенную и можно запустить «быструю петлю обратной связи» и плохи в оптимизации моделей, которые для проверки требуют обращения в реальный мир с его задержками.
Большинство задач, для которых мы пишем софт — второго типа.
Автор делает вывод, что нейросети плохо поддерживают и тем более наводят порядок в больших системах. И как следствие — вряд ли смогут поддерживать своё собственное развитие, тот самый рекурсивный сверхинтеллект, взрывным ростом которого нас пугают.
Заканчивается статья тем, что весь современный важный опенсорс — это во многом пример того, как люди десятилетиями поддерживали внутреннюю гармонию (когерентность) крупных систем. И что хорошо бы не разломать всё это за пару месяцев с помощью ИИ.
Даже если не согласен с выводами автора, можно поучиться качеству концептуализации мира. Красиво!
Интересно: с одной стороны, вся эта движуха с нейросетями, агентами и прочим «запустим продукт за неделю».
С другой стороны, больша́я часть наших проектов — «разобраться в огромной 20-летней системе, половина которой на хранимках, половина в MSSQL, половина в PostgreSQL (хорошо если не Oracle), а большая часть в C++ и Delphi, чтобы вернуть прозрачность и управляемость, опять быстро вносить изменения / запустить тот же бизнес в новой географии».
В таких проектах нейросети тоже полезны, но главный ограничитель этих задач — не в скорости программирования или числе разработчиков (рук). Там главное — системное мышление, опыт, умение разговаривать с людьми, здравый смысл и вкус. ❤️
