Экспоненциальный рост возможностей моделей ведёт к доверию более крупным системным задачам

Экспоненциальный рост возможностей моделей ведёт к доверию более крупным системным задачам

Связка 1

Начальное состояние: Модели были полезны в 2025 году, но в узких рамках: локальные изменения, небольшие функции, тесты, связующий код, одноразовые прототипы
Преобразование: Примерно в конце 2025 года наклон возможностей моделей стал экспоненциальным
Конечное состояние: Разработчик начал доверять Claude более крупные и неоднозначные работы на уровне системы

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

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

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

Это статья. Мы создавали распределенную систему очередей под названием Courier с нуля. Все это было до агентов, вручную. Можете в это поверить? Типа, тогда софт еще писали вручную.

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

Следующая идея возникла примерно в сентябре 2025 года. Мы назвали ее Bits Evolve.

Это замкнутый контур эволюционной оптимизации, вдохновленный AlphaEvolve от DeepMind. Идея в том, что вы позволяете частям кода улучшать себя в узкой, сложной области. Думаю, мы видели сегодня на пленарном заседании объявления о dreaming и различных циклах. Так что это была наша попытка в сентябре 2025 года. Это ансамбль или совет моделей, больших и малых, которые генерируют варианты кода, что бы вы ни назначили для улучшения.

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

Если у вас плохие бенчмарки, они приводят к плохим эволюциям. Слабая наблюдаемость — ваши оптимизации поверхностны. Так что в этот период скачка или экспоненты, который начался, мы строили целые распределённые системы с Cloud Code.

Я упомянул точку перегиба Opus 4.5, когда я повысил свои амбиции. Это не было внезапно — я не проснулся однажды утром и не начал доверять облаку целые системы или даже свои базы данных. У нас их много.

Это происходило постепенно. Я пробовал более сложные задачи, затем более крупные подсистемы, много раз терпел неудачи, много учился на экспериментах, и примерно в этот период начал видеть успехи. Поэтому мы решили быть более амбициозными: «Хорошо, сможем ли мы построить что-то такое же большое, как Kafka?» Поднимите руки, кто слышал о Kafka.

Хорошо, теперь больше рук. Итак, Kafka — это стриминговый сервис. Мы попытались: «Хорошо, можем ли мы построить это с нуля?» Это как повторение того же сценария, что и для Courier. Это система очередей, довольно близкая, правда? Та же строгость.

Вы увидите гроб на правой стороне слайда, но Cloud Code выполняет большую часть построения с одним человеком-строителем. За несколько дней, к нашему неверию, у нас была полностью функциональная CAF-совместимая система.

И мы назвали это Helix.

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

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

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

Мы — Datadog, у нас много метрик. Можем ли мы улучшить логику материализации на лету — не офлайн, как мы делали с Bitsovolve раньше? Можем ли мы оптимизировать их для каждого клиента с путём, подтверждающим корректность изменения, чтобы человеку не нужно было проверять каждый генерируемый кандидат? Если посмотреть на поток этих четырёх проектов и заметить закономерность, каждый проект выявлял узкое место для следующего. Сегодня было много докладов и комментариев о том, что узкое место смещается.

Так, с Courier узким местом было построение: люди создавали системы через тщательное проектирование, моделирование и верификацию. На создание Courier у нас ушёл год. А если сравнить, на создание Kafka ушло около трёх дней — то есть двенадцать месяцев? С BitsEvolve узкое место сместилось на цикл обратной связи. Модель создаёт вариации, но окружение решает, что выживет.

А с Helix, системой Kafka, которую мы построили, узкое место снова сместилось — агенты могли создавать большие части системы, мы это видели, но человеку приходится координировать передачу работы в продакшн через инструменты и механизмы, созданные для людей. Это закон Амдала, о котором сегодня говорил Дарио. Так что это переход, который мы совершаем, если посмотреть на этот слайд в центре — от механизации к индустриализации. Механизация означает, что агенты теперь выполняют больше работы. А индустриализация — если использовать метафору, и именно поэтому я упомянул станки — означает, что работа становится повторяемой, проверяемой, контролируемой и масштабируемой.