Борис Черный о циклах

Сегодня у нас есть сорок минут в компании моего замечательного друга Бориса, который не нуждается в представлении. Но на случай, если кто-то о нем не слышал: он возглавляет направление Cloud Code. Я являюсь директором по продукту в команде Developer Infrastructure в Meta и занимаюсь поддержкой наших инструментов для повышения продуктивности разработчиков в области искусственного интеллекта.

У нас будет дружеская беседа в формате «у камина» (fireside chat), где мы обсудим множество различных вопросов, которые у меня есть к Борису. Ранее на экране отображался QR-код, по которому можно было перейти. Во второй части встречи мы планируем сделать сессию вопросов и ответов из зала. У меня с собой iPad, на котором отображаются вопросы, которые вы присылаете, и мы пройдемся по тем из них, которые набрали наибольшее количество голосов.

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

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

Для того чтобы ответить на этот вопрос, лектор заранее подготовил статистику своей деятельности. В текущем году он совершил 1,7 тысячи PR (Pull Requests), добавил 400 000 строк кода и удалил 250 000 строк. Примечательно, что в прошлом году объем удаленного кода превышал объем добавленного, однако в текущем году показатели изменились, и количество добавленного кода стало преобладать над удаленным.

Помимо статистики строк кода, лектор попытался оценить объем потребления токенов. Несмотря на то что часть данных была утрачена из-за политики хранения, известно, что с марта он использовал 8 миллиардов токенов.

На вопрос о том, кем были написаны эти строки кода — им самим или инструментом Cloud Code, — лектор ответил, что 100% его кода было написано с помощью Cloud Code, начиная с модели Opus 4.5, то есть с ноября прошлого года.

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

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

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

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

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

• Per-seat cost controls — контроль затрат на уровне отдельных рабочих мест.
• Использование advisor models (рекомендуемых моделей) для оптимизации запросов.
• Возможность смены используемой модели для всей компании.
• Настройка уровня усилий (effort level) для всей организации.
• Установка бюджетов в зависимости от департамента или на основе RBAC (Role-Based Access Control — управление доступом на основе ролей).

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

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

Оценка окупаемости (ROI)

При расчете ROI (Return on Investment) выделяют две составляющие: инвестиции и возврат. Инвестиции измерить легко — это просто затраты на токены. В прошлом возврат оценивали по тому, какой процент кода написан с помощью AI (искусственного интеллекта), или, например, по процентному увеличению количества строк кода. Однако в условиях, когда у многих разработчиков уже практически 100% кода создается с помощью AI, традиционные метрики перестают работать, и измерять возврат становится сложно.

Для сравнения, при работе над Dev Infra (инфраструктурой разработки) в прежние времена улучшение продуктивности на 2–3% в год считалось очень хорошим результатом. Сейчас же индустрия ориентируется на рост продуктивности в сотни процентов. Например, в компании Anthropic с начала этого года зафиксировано восьмикратное (8x) увеличение объема кода на одного инженера.

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

Преодоление новых узких мест

Когда инженеры начинают писать колоссальные объемы кода, главным узким местом становится генерация хороших идей. Чтобы устранить это препятствие и позволить компании генерировать идеи быстрее, необходимо расширить возможности на данном этапе. На практике это может означать привлечение большего числа PM (product managers) или исследователей пользователей (user researchers).

Следующий шаг — ускорение вывода этих идей на рынок. Здесь требуется устранение барьеров на стороне GTM (Go-to-Market) и маркетинга. Именно в такой последовательности обычно происходит адаптация технологии, хотя разные клиенты сейчас находятся на разных этапах этой кривой внедрения.

Вся индустрия сейчас проходит путь от автоматизации написания кода к решению более широких задач. Изначально фокус был на самом кодинге и увеличении доли участия искусственного интеллекта до максимума. Однако со временем пришло понимание, что существуют смежные узкие места — как предшествующие написанию кода (upstream), так и последующие (downstream). Конечная цель бизнеса заключается в создании ценности, а для этого необходимо разблокировать процесс генерации идей, а также обеспечить быструю, безопасную и точную доставку написанного кода в продакшн.

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

Ведущий задает вопрос от их бывшего коллеги Питера: «Являются ли loops (циклы) следующим циклом хайпа или это реальность?» Также он просит объяснить, что такое loops для тех, кто с ними не знаком, и как лектор использует их лично.

Лектор интересуется у аудитории, пробовал ли кто-то использовать рутины циклов (loops routines). Поднимается не так много рук, поскольку технология пока находится в зародышевом состоянии. Чтобы определить необходимый уровень технической детализации объяснения, лектор просит поднять руки тех, кто является инженером и пишет код. В зале оказывается много инженеров.

Для инженеров в аудитории ментальную модель можно описать следующим образом. Два года назад мы писали исходный код (source code) вручную. Затем мы начали переходить к тому, чтобы agents (агенты) писали код. Сейчас же мы переходим к этапу, когда agents (агенты) дают промпты другим agents (агентам), которые затем пишут код. Лектор называет это «Vortex-объяснением» [возможная ошибка распознавания: Vortex explanation / вербальное объяснение].

С точки зрения лестницы абстракции, ментальная модель выглядит так. Если исходный код (source code) — это базовый уровень, что-то вроде программирования на уровне инструкций (statement programming), то написание кода агентом — это как функция (function) в программировании. В таком случае loops (циклы) представляют собой функции высшего порядка (higher order functions). Таким образом, происходит переход на еще одну ступень по лестнице абстракции. Переход от агентов к loops — это такой же важный и масштабный шаг, как в свое время переход от исходного кода к агентам. Сейчас мир loops находится примерно в той же точке, где агенты были полтора года назад. Технология все еще находится на ранней стадии развития, но уже появляются признаки того, что она работает.

Примеры работы Loops

В качестве примера можно рассмотреть работу инженера, значительная часть которой заключается в проведении код-ревью. Инженер может делать код-ревью вручную. Другой вариант — использовать agent (агента) и давать ему промпты для проведения код-ревью. Версия этого процесса на основе loops (циклов) заключается в том, что у вас есть agent, который непрерывно работает в цикле (running in a loop) и выполняет абсолютно все код-ревью.

Другой пример связан с чтением отзывов пользователей в Threads для получения обратной связи. Это можно делать вручную или поручить агенту. В случае с loops у вас есть agent, который циклически запускается каждые пять или десять минут, читает отзывы и автоматически создает PRs (пулл-реквесты) для исправления ошибок.

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

Что касается личного опыта лектора, в среднем около 30% его кода на сегодняшний день пишется с помощью loops. Если очень постараться, в отдельные дни можно довести этот показатель до 100%, но технология пока не работает идеально во всех сценариях.

Ведущий отмечает, что если задать вопрос о том, сколько инженеров пишут loops, через год, то в зале будет гораздо больше поднятых рук. Лектор в некотором смысле живет на три-шесть месяцев впереди остальной команды. Тема loops вызывает огромный интерес внутри компании. Сотрудники начинают исследовать различные способы оркестровки разнообразных инструментов, необходимых для создания автоматического цикла. Сейчас на каждом этапе процесса человеку все еще приходится находиться внутри процесса (humans are in the loop). Цель состоит в том, чтобы сделать этот процесс все более автоматизированным. Запуск такого непрерывного цикла (loop) является ключом к автоматизации и достижению более высокой продуктивности.

Компания Anthropic в последнее время активно инвестирует в CoWork. Большинство пользователей преимущественно используют Claude Code, однако существуют важные причины, почему стоит использовать CoWork, и множество сценариев его применения за рамками написания кода.

Для того чтобы попробовать CoWork, необходимо скачать приложение Claude Desktop для компьютера. Это то же самое приложение, в котором доступны чат и Claude Code, и в нем также присутствует CoWork. Оно работает на Mac и на Windows.

По сути, CoWork — это Claude Code для не-инженеров. Под капотом находится тот же самый Claude Code, и он использует тот же самый Claude Agent SDK, на котором построен Claude Code. Вся инфраструктура совпадает, и пользователи могут сами вести разработку на этом SDK.

Причина, по которой данный инструмент позиционируется как решение для не-инженеров, заключается в наличии большого количества встроенных защитных барьеров (guardrails). CoWork имеет полноценную виртуальную машину (virtual machine), в нем реализована сложная строгая изоляция [возможная ошибка распознавания: tight isolation вместо quite isolation], а также настроена интеграция с операционной системой, чтобы гарантировать, что пользователь случайно не удалит файлы. В системе предусмотрена надежная защита от промпт-инъекций (prompt injection) и множество других мер безопасности, которые значительно снижают вероятность совершить критическую ошибку и навредить системе. Спикер использует CoWork для решения любых задач, не связанных напрямую с инженерной разработкой.

Инструменты автоматизации, такие как CoWork, можно эффективно использовать для выполнения задач, не связанных с непосредственным инженерным программированием. Одним из практических примеров является управление проектами. Вместо проведения ежедневных утренних встреч (stand-up), на которых каждый член команды отчитывается о проделанной работе, лектор использует CoWork для автоматизации этого процесса.

В браузере открывается электронная таблица, содержащая все рабочие потоки на текущую неделю. CoWork автоматически отправляет сообщения каждому инженеру в Slack с запросом статуса выполнения задач. Когда инженеры отвечают на сообщения, агент CoWork фиксирует ответы и самостоятельно заполняет таблицу статусов. Для этого не требуется сложная настройка — достаточно иметь установленное расширение CoWork для браузера Chrome, которое обеспечивает взаимодействие между инструментами. Это создает ощущение магии, когда ИИ-агент способен объединять различные инструменты так, как это сделал бы человек.

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

На текущий момент процесс автоматизирован еще сильнее: CoWork выполняет запланированную задачу, ежедневно просматривая электронную почту и календарь Google. Если в календаре появляется подтвержденное мероприятие в другом городе (не в Сан-Франциско), агент автоматически приступает к бронированию. Он знает предпочтения лектора относительно отелей и авиарейсов, поэтому самостоятельно резервирует билеты и отели для поездок.

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

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

Эволюция моделей и программирование

Если анализировать развитие возможностей моделей в программировании, то переломный момент наступил в ноябре прошлого года с выходом Opus 4.5. Скачок в качестве между предыдущей моделью и Opus 4.5 был настолько значительным, что многие пользователи впервые начали писать весь свой код с помощью Claude. Для автора это стало моментом, когда он фактически перестал использовать свою IDE и удалил её, так как больше не нуждался в ней.

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

Применение Fable в задачах

Эта способность эффективна в ряде направлений:

• Анализ данных: из-за наличия нюансов в работе с данными часто требуется задавать вопросы «почему» несколько раз подряд, чтобы докопаться до сути. Fable выполняет это естественным образом.
• Отладка (debugging): процесс требует формирования гипотезы, её последующей проверки и поиска доказательств, с чем модель справляется очень успешно.
• Написание кода: возможности модели настолько велики, что автору фактически не удавалось придумать достаточно сложную задачу, которую Fable не решила бы с первой попытки или с минимальным количеством дополнительных подсказок (prompting).

Что касается разработки продуктов Anthropic, таких как Claude Code и CoWork, то с ноября прошлого года они практически полностью пишутся с использованием моделей Claude. Это подтверждает общую тенденцию в компании, где для всё большей доли команд написание кода на 100% делегируется ИИ.

При выборе моделей для решения задач возникает вопрос: стоит ли использовать только наиболее функциональные модели, такие как Claude 3 Opus (в транскрипте упоминается как Fable), или переключаться на менее дорогие и быстрые аналоги? Даже внутри компании Anthropic вопрос использования токенов стоит остро. Хотя компания сама их производит, они не являются бесплатными, так как каждый токен, затраченный на внутренние нужды — это токен, который не был продан клиенту, что создает opportunity cost (альтернативные издержки).

При рассмотрении ROI (возврата инвестиций) существует несколько стратегий оптимизации. Можно снизить затраты на 50% или более, используя advisor model (модель-советник): использовать Opus по умолчанию, которая при необходимости делегирует задачи более простым моделям (например, Sonnet). Однако такая оптимизация требует постоянной работы: необходимо регулярно проводить evals (оценки качества), чтобы убедиться, что система продолжает работать эффективно при обновлении моделей.

Несмотря на наличие стратегий по сокращению издержек, ключевая рекомендация заключается в смещении фокуса с экономии на максимизацию прибыли. Если оптимизация затрат может сократить инвестиции, условно, на 50%, то работа над увеличением возврата от использования модели может дать прирост в 1000%, 10 000% или даже 100 000%. Поскольку технология внедряется на ранних этапах, важно, чтобы расходы оставались под контролем и были хорошо управляемыми, однако практически все усилия стоит направлять на увеличение returns (доходности). Необходимо фокусироваться на потенциальном «апсайде» (upside) значительно больше, чем на возможных «даунсайдах» (downsides), так как на текущем этапе развития технологий потенциал роста превосходит пространство для оптимизации издержек.

Вопрос о том, что делает Cloud Code для улучшения сотрудничества, затрагивает проблему текущего восприятия разработки как преимущественно индивидуальной работы, где для взаимодействия с другими приходится использовать внешние инструменты, например GitHub. В качестве текущего решения рекомендуется использовать MCP (Model Context Protocol) для интеграции Cloud Code с такими платформами, как Slack, Teams или Gchat, используемыми для командной коммуникации.

Что касается фокуса работы инженеров в условиях, когда агенты способны выполнять большую часть написания кода, стоит учитывать, что инженерная деятельность всегда включала в себя широкий спектр задач, помимо самого кодинга: общение с клиентами, генерацию идей, совместную работу с дизайнерами и PM (менеджерами продуктов), анализ данных, определение стратегии развития продукта и синхронизацию с другими отделами организации.

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

В текущий трансформационный период отрасль совместно ищет новые подходы. Статистика показывает, что написание кода занимает меньшую часть времени обычного инженера-программиста. Большая часть деятельности сосредоточена на процессах «выше» и «ниже» по потоку разработки (upstream и downstream), таких как управление развертыванием кода (code deployments), совместная работа в документах и планирование. Cloud Code и другие продукты с поддержкой ИИ направлены на ускорение всего жизненного цикла разработки (development lifecycle). В то время как задачи по написанию кода уже успешно автоматизируются, аспекты жизненного цикла, связанные с организационными процессами, еще находятся на этапе осмысления.

Cloud Code можно сравнить с реактивным ранцем: по мере совершенствования модели у инженера появляется все больше «двигателей», позволяющих ускоряться. На текущий момент работа инженера ограничена не скоростью написания кода, а скоростью формирования промптов — часто в формате живой речи — и поиском качественных идей. Роль инженера-программиста все меньше сводится к написанию кода и все больше — к супервизии агентов, управлению их работой от начала до конца, а также к генерации и продуктовизации собственных идей.

Развитие технологий генерации кода с помощью ИИ привело к резкому увеличению скорости его написания. В контексте разработки программного обеспечения это порождает вопрос о том, как справляться с последствиями такого роста производительности, в частности, на этапе code review (код-ревью). Во многих компаниях до сих пор сохраняется парадигма обязательной проверки кода человеком, однако из-за значительного увеличения объема поступающего кода этот процесс может перестать быть эффективным.

Когда рассматривается цикл разработки: от написания кода до его попадания в продакшн, где он должен влиять на ключевые бизнес-метрики — такие как выручка или вовлеченность пользователей, — становится очевидно, что в процессе существуют различные узкие места. Раньше основным узким местом был сам процесс написания кода, но сейчас эта проблема решена. В Anthropic, как и у многих их клиентов, следующим этапом, требующим оптимизации, стало code review.

Для решения этой задачи был создан продукт Claude Code Review. Это инструмент, который используется внутри Anthropic для проверки абсолютно каждого pull request. Его ключевое отличие от других решений на рынке заключается в более высокой стоимости, обусловленной использованием большого количества токенов для полной автоматизации процесса проверки. Благодаря этому, к тому моменту, когда инженер видит pull request, существует практически полная гарантия того, что все ошибки устранены. Система исправляет 98–99% багов. В результате инженер, просматривая код, больше не ищет ошибки, а оценивает целесообразность самого pull request и его архитектурную ценность.

Следующим узким местом стала безопасность. Агенты, как и люди, могут привносить уязвимости в код. Для решения этой проблемы компания разработала продукт Claude Security. Он еженедельно сканирует кодовую базу, обнаруживает проблемы и автономно их исправляет. В компании также проводятся red teaming и penetration testing для каждого крупного запуска функций, и на текущий момент (с использованием модели Opus 4.8) система безопасности Claude способна находить уязвимости, которые пропускают даже профессиональные пентестеры.

Далее внимание переключается на следующие узкие места, такие как генерация идей или оптимизация CI (Continuous Integration). Процесс оптимизации может выглядеть так: модель анализирует реальные тайминги работы CI из набора данных и выстраивает рабочий процесс для повышения скорости. В таких задачах используется dynamic workflow — новая функциональность, при которой модель динамически оркестрирует десятки, сотни или тысячи субагентов. По сути, это новая форма test time compute. В одном из примеров использования такой подход позволил за несколько часов работы и затрату нескольких миллионов токенов создать четыре pull request, которые сократили время выполнения CI на 50%. Работа, на которую раньше требовались дни, недели или даже месяцы профилирования, была выполнена автоматически.

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

В отношении планов развития Claude Code важно отметить, что команда работает по недельным или месячным циклам. У них нет годового плана, так как эта область меняется слишком быстро: экспоненциальный рост изменений настолько стремителен, что необходимо просто адаптироваться и планировать задачи небольшими порциями.

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

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

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

• Долгосрочная работа: Claude уже сейчас является лидером в выполнении долгосрочных задач, и, по мнению команды, этот отрыв будет только увеличиваться.
• Качество и безопасность: создаваемый код будет становиться более безопасным и качественным.
• Согласованность (Alignment): модель будет становиться еще более «отлаженной», то есть лучше понимать намерения пользователя — будь то инженер, менеджер по продукту или дизайнер — и качественнее воплощать эти намерения в жизнь.

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

При обсуждении проблемы обслуживания кода в крупномасштабных проектах, ключевой задачей становится не само написание кода, а его долгосрочная поддержка. Одним из методов работы с этой задачей является использование циклов (loops). Например, можно запускать код в цикле, который анализирует базу данных проекта и выполняет различные улучшения архитектуры: поиск и устранение «хрупких» (flaky) тестов в тестовом наборе, удаление бесполезных тестов или поиск дублирующихся абстракций с их последующей унификацией в единую абстракцию.

В подобных процессах процесс работы выглядит так: система выполняет цикл, создавая набор изменений (PR — pull request), а разработчик проводит их ревью уже после того, как цикл завершил выполнение. Для моделей вроде Claude такие задачи по анализу структуры кода достаточно понятны. Если результат работы модели оказывается неудовлетворительным, достаточно дать дополнительную инструкцию, например: «ищи возможности для улучшения качества кодовой базы и используй workflow (рабочий процесс)». Использование концепции workflow позволяет задействовать дополнительные вычислительные ресурсы на этапе тестирования (test time compute), что значительно повышает качество итогового результата.

Динамические воркфлоу (dynamic workflows) представляют собой относительно новую концепцию. Для понимания разницы между воркфлоу и циклами следует обратиться к законам масштабирования (scaling laws) в области ИИ. Согласно им, производительность нейронных сетей и больших языковых моделей (LLM) определяется тремя факторами: объемом данных, размером нейронной сети и количеством вычислительных ресурсов (compute), затраченных на обучение. Именно это свойство обеспечивает экспоненциальный рост интеллектуальных возможностей моделей.

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

Первый способ — настройки «усилий» (effort settings), которые позволяют конфигурировать модель (от низкого уровня до максимального), тем самым определяя, какой объем токенов она должна сгенерировать. Чем больше токенов выделяется на выполнение задачи, тем выше качество результата.

Второй способ — динамические воркфлоу (dynamic workflows). Это метод, при котором модель Claude пишет небольшую программу, исполняемую в виртуальной машине для оркестрации других экземпляров Claude с целью решения конкретной проблемы. Это новая форма test time compute, которая позволяет модели запускать десятки, сотни или даже тысячи агентов для выполнения поставленной задачи.

Говоря об ограничениях моделей и сложных задачах, с которыми ИИ пока справляется недостаточно эффективно, важно отметить, что современные системы не являются совершенными и имеют области, требующие улучшения. Одной из таких проблем является Product Sense (продуктовое мышление). В частности, генерация продуктовых идей по-прежнему лучше удается человеку, чем нейросети Fable.

При этом в других аспектах прогресс очевиден: код, написанный ИИ, зачастую превосходит по качеству тот, что мог бы написать человек, а фронтенд-дизайн модели уже лучше, чем дизайнерские решения самого автора. Еще одной областью, где человек пока значительно превосходит Fable, остается проектирование распределенных систем (distributed system design). Это включает в себя комплексное осмысление архитектуры: определение необходимых сервисов, организацию их взаимодействия, проектирование потоков данных и учет таких факторов, как нагрузка на систему (load factors). В этом направлении у ИИ все еще сохраняется значительный потенциал для развития.

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

Изначально в Claude Code существовали запросы на подтверждение разрешений. Всякий раз, когда Claude хотел выполнить команду на компьютере, он запрашивал подтверждение: «можно ли запустить эту bash-команду?», «можно ли использовать этот MCP?», «можно ли получить содержимое этого URL в браузере?». Инженер должен был сидеть и одобрять или отклонять каждое действие. Однако со временем стало понятно, что такой подход ведет к возникновению prompt fatigue (усталости от запросов). Инженеры начали просто нажимать «да», даже не читая команды.

Специалисты по безопасности Anthropic осознали, что наличие «человека в цикле» (human in the loop), который изначально должен был повышать безопасность, фактически начало ее снижать из-за усталости от запросов. В ответ на эту проблему был разработан Auto Mode — новый режим разрешений в Claude Code, который сейчас используется как в Anthropic, так и большинством пользователей.

В режиме Auto Mode каждый запрос на разрешение передается непосредственно модели, которая самостоятельно принимает решение «да» или «нет», опираясь на контекст текущего разговора. Этот механизм не только более безопасен, чем дефолтный режим ручного подтверждения, но и позволяет инженеру освободиться от необходимости постоянно отвечать на запросы. Это открывает возможности для использования long-running agents (агентов, работающих долгое время): теперь можно оставить Claude работать на часы или даже дни. Существуют различные тесты, показывающие, что Claude демонстрирует лучшие результаты в таких задачах.

Внедрение Auto Mode стало возможным благодаря годам исследований, направленных на повышение устойчивости моделей к prompt injection (инъекциям промптов). На текущий момент модели Claude практически не подвержены этой уязвимости. Согласно данным из системных карт (system cards), вероятность успеха атаки при 100 попытках составляет около 1%, что является лучшим показателем в индустрии. В сочетании с классификатором инъекций промптов, который Anthropic использует в своем трафике, модели становятся защищенными от подобного типа атак.

Таким образом, ответ на вопрос инженера заключается в том, чтобы позволить Claude выполнять больше задач самостоятельно. Задача состоит в том, чтобы найти способы разблокировать возможности модели для выполнения большего объема работы безопасным образом, вместо попыток жесткого ручного контроля со стороны человека.

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

На самом деле, инструмент, который я нахожу действительно мощным для этого, — это стили вывода (output styles) в Claude Code. Каждый раз, когда к нашей команде присоединяется новый инженер, мы советуем ему использовать исследовательский стиль (exploratory style). Настройка выглядит как /config output style = exploratory. Вы можете запустить эту команду в Claude Code или просто попросить Claude установить этот стиль за вас. При активации этого стиля каждый раз, когда Claude собирается внести какое-либо изменение, он будет объяснять вам: «Привет, вот как устроена архитектура. Вот как работает этот язык программирования» (если вы не использовали его ранее), «Вот как работает эта часть кодовой базы». Он дает эти объяснения специально для того, чтобы вы могли учиться.

Кроме того, существует обучающий стиль вывода (learning output style), который вы также можете использовать. Этот стиль предназначен для людей, не являющихся программистами. Он объясняет принципы работы на очень базовом уровне и обучает тому, как сделать задачу самостоятельно, вместо того чтобы выполнять её за вас. Например, в случае с JavaScript он скажет: «Вот как это работает. Я не буду вносить изменения за вас, а проведу вас через весь процесс по шагам. Шаг первый — откройте этот файл и отредактируйте его вот так. Шаг второй — запустите эту команду. Отлично, я вижу, что вы это сделали. Шаг третий — сделайте следующее».

Стили вывода и ещё более активное использование Claude представляют собой супермощный инструмент для обучения. Это помогает инженеру понимать, что происходит, даже когда меняется стек технологий или меняется инфраструктура (infra), и особенно когда приходится работать с новыми языками программирования.