Интервью с основателем Instagram: выход модели Anthropic Fable 5 означает, что эпоха написания кода исключительно вручную безвозвратно ушла в прошлое

Подготовка и перевод: TechFlow

Гость: Майк Кригер, соучредитель Instagram

Ведущий: Дэн Шиппер

Источник подкаста: Every

Оригинальное название: Mike Krieger Lets Fable 5 Code While He Sleeps

Дата выхода: 11 июня 2026 г.

Ключевые тезисы

Майк Кригер, как соучредитель Instagram, лично создал одно из самых влиятельных потребительских приложений последних двадцати лет. Сегодня он находится на передовой разработки продуктов «нативных для ИИ» (AI-native), возглавляя Anthropic Labs и ведя команду к решению фундаментальной задачи: до какой границы технических возможностей можно продвинуться, если предоставить лучшие в мире модели ИИ настоящим разработчикам?

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

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

Ключевые идеи

Как Fable полностью изменила рабочий процесс Майка

• «Настоящее когнитивное прорывное понимание приходит только после нескольких недель интенсивного использования, а не от первого же знакомства… По мере того как вы проводите с моделью больше времени, внезапно осознаёте: „Я ещё не использовал её по-настоящему. Мне нужно продвинуться дальше и заново переосмыслить границы возможностей этой модели.“»
• «Правильный подход сегодня — чётко передать ей более широкий и полный замысел, а затем полностью отпустить её работать самостоятельно. Она не только способна единовременно выдать потрясающий результат, но и, что ещё более удивительно, понимает дальнейшее развитие функционала и общий контекст всего проекта.»
• «Больше всего меня поразила её способность автоматически завершать циклы. Например, она может рассуждать так: „Майк поручил мне выполнить сложную задачу сегодня вечером. Но я застрял — удалённый сервер упал. Хорошо, я сам напишу заглушку бэкенда…“ Для меня возможность делегировать задачи такого уровня и полностью доверять итоговому результату — поистине шокирующий опыт.»
• «Раньше мы сравнивали такие модели с „ассистентами“ или „партнёрами“, но сейчас она становится настоящим „жёстким товарищем по команде“, готовым взять на себя ответственность и выполнить значительную часть ключевой работы.»

Когда использовать Sonnet, а когда — Fable

• «Это совершенно разные уровни ощущений. Это даже не связано с количеством токенов в секунду — речь идёт о том, сколько „объёмов мозга“ требуется для решения задачи. Иногда простой ответ не требует столь глубокого и многослойного мышления.»
• «Большую часть времени, когда я открываю iOS-приложение, я почти наверняка не собираюсь решать какие-то задачи, требующие вмешательства Fable… Последнее время я действительно остро чувствую эту тонкую настройку: „Эта задача просто не заслуживает Fable — надо вызвать Sonnet“.»
• «Fable — первая модель, с которой я стал активно регулировать „уровень усилий“ (Reasoning Effort) — степень глубины рассуждений. Раньше с Opus я почти не настраивал этот параметр, потому что диапазон масштабируемости модели был намного уже; у Fable же он действительно очень широк.»

Архитектура, ориентированная на агентов (Agent-native), порождённая Fable 5

• «Архитектура, ориентированная на агентов, начинается с первого этапа: каждый ключевой компонент и данные продукта должны быть полностью открыты для агента и иметь соответствующие интерфейсы вызова инструментов. Это быстро становится базовым требованием индустрии ПО — хотя, к сожалению, большинство существующих программных продуктов пока даже не достигают этого уровня.»
• «Долгое нажатие на кнопку чата в приложении пробуждает наш托管 агент для получения „инструкций по изменению кода“… Когда я гуляю с ребёнком, замечаю: „Эта плавающая кнопка в iOS расположена слишком низко“, — и сразу говорю об этом прямо в приложении. Агент сам отправляется в фон и исправляет код.»
• «Как именно Claude должен быть встроен в программное обеспечение? Он не должен ограничиваться лишь „использованием“ — он должен проникнуть в саму „суть построения“ ПО.»

Стоимость создания ПО рухнула

• «Вспомните первую версию Instagram — функционал действительно немного богаче, чем у моего медиа-трекера, сделанного на прошлых выходных, но качественно они не отличаются. При этом первый релиз мы с Кевином собирали в течение пяти бессонных ночей… А сегодня время разработки сократилось до невероятных пределов.»
• «Пропасть между „замыслом“ и „реализацией“ для обычных людей без знания программирования теперь ликвидирована… Впервые в жизни я почувствовал, что то, что есть у меня в голове, и то, что существует в реальном мире, разделены буквально никаким расстоянием. Я могу реализовать это немедленно.»
• «Человеческое творчество безгранично, и самое удивительное, что мы делаем сегодня — это неограниченно расширяем круг людей, способных воплотить свои идеи в реальность.»

Умерла ли инженерия ПО?

• «Суть инженерии ПО кардинально изменилась. Она переживает глубочайшую трансформацию… Эпоха „чистого программирования“ как ремесла, скорее всего, окончательно ушла в прошлое.»
• «Роль старшего инженера остаётся незаменимой: вам нужны многолетний опыт реагирования на аварии, способность сохранять абсолютное спокойствие, собирать полные логи, экстренно останавливать утечку и затем разрабатывать долгосрочное коренное решение.»
• «В Силиконовой долине раньше было популярно выражение „код побеждает споры“ (Code wins arguments). Я никогда особо не соглашался с этим, поскольку в нём подразумевается, что владение кодированием даёт власть над дискуссией. Сегодня же ситуация развивается в обратном направлении: иногда мы долго не можем договориться о будущем продукта, и вдруг не пишущий код PM говорит: „Я только что собрал демо…“ — и это мгновенно открывает совершенно новый, высокомерный уровень диалога.»
• «Самый очевидный признак — чудовищная параллелизация разработки и абсолютная необходимость высокоуровневой абстракции рабочих процессов. Единственное, что осталось неизменным с самого начала — чувство человеческой „собственности и ответственности“ за продукт.»

Механизмы и стоимость верификации

• «Сегодня „стоимость“ стала многомерным понятием — вы должны считать не только „стоимость одного запроса“, но и „общую стоимость полного решения задачи“. Именно здесь Fable производит наибольшее впечатление: она стремится сделать всё правильно с первой попытки, без необходимости сражаться с ней восемь-девять раундов у компьютера.»
• «Адаптация к этой новой норме и освоение правил совместной работы — обязательный навык для всех нас… Каждый раз, когда я создаю что-либо, я гарантирую, что каждый PR от Claude сопровождается фото или видео — вне зависимости от того, речь идёт о PR для iOS или изменениях UI. Это даёт мне огромную уверенность.»
• «Видео — чрезвычайно недооценённый инструмент для Claude. Недавно я делал прототип: записывал видео того, что построил Claude, передавал ему вместе с FFmpeg и наблюдал, как он анализирует каждую кадровую последовательность, говоря: „Анимация тормозит — я это исправлю“. Скриншоты никогда не смогут этого зафиксировать — ведь они пропускают мгновение.»

Динамические рабочие процессы

• «На ранних поколениях моделей существовал „потолок сложности“ проекта. Как только объём бизнес-логики или кода достигал определённого размера, крупные модели начинали „смотреть только вперёд, забывая о хвосте“… Сегодня же коллега-неинженер, вооружённая моделью уровня Fable, уже несколько месяцев подряд развивает свою систему в фоновом режиме. Вы чётко видите, как это ПО растёт, как живой организм, постоянно эволюционируя под влиянием ИИ.»
• «Рабочий процесс — это хороший промежуточный формат: вы используете чат для его оркестрации, но он выражается в виде кода и выполняется в чистом UI, где на каждом шаге наглядно демонстрируется, что происходит. Я считаю, что в будущем мы будем использовать подобные методы для связки долгосрочных задач и чата.»

Как Fable полностью изменила рабочий процесс Майка

Ведущий Дэн Шиппер: В этом выпуске мы рады представить гостя Майка Кригера — руководителя Anthropic Labs и соучредителя Instagram. Майк, я особенно хочу услышать от вас вашу личную реакцию после глубокого использования этой модели. Когда выходит такая мощная модель, и человек, который пользуется ею ежедневно, говорит: «Вот здесь она невероятно сильна, вот здесь реально меняет рабочие процессы, а вот здесь — всё как обычно», — это помогает всем понять, как именно технология должна вписаться в повседневную жизнь.

Майк Кригер:

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

Мы уже сталкивались с подобной перестройкой восприятия на предыдущих моделях. В конце декабря — начале января, когда все активно использовали Opus 4.5 и 4.6, по мере увеличения времени взаимодействия люди вдруг осознали: «Я ещё не использовал её по-настоящему. Мне нужно продвинуться дальше и заново переосмыслить границы возможностей этой модели.»

Ведущий Дэн Шиппер: Внутри нашей команды Every уже есть коллеги, которые начали её использовать. Один из них сказал: «Мне нужна совершенно новая система навыков, чтобы освоить эту модель», особенно это касается коллег без технического бэкграунда, занятых в сфере знаний, — им даже непонятно, с чего начать; а те, кто занимается оркестрацией агентов, говорят: «Столько нового нужно выучить!»

Майк Кригер: Ваша фраза про «смену рабочего процесса» точно попадает в цель — речь идёт не только о конкретных действиях, но и о смене мировоззрения. Случайно, как раз в этот период я сменил должность: перешёл с позиции CPO (Chief Product Officer) в Labs и снова вернулся в режим разработчика. Примерно через полтора–два месяца у нас впервые запустили такую модель внутри. Я сидел за компьютером и думал: «Ладно, теперь я снова новичок». Я осознал, что мои прежние привычки составления промптов и даже подходы к декомпозиции задач устарели перед этой моделью.

Вам нужно эволюционировать и свой временной масштаб, и стиль взаимодействия. Раньше я мог сказать: «У меня есть идея функции, давайте начнём с первого шага…» Сегодня так нельзя. Правильный подход сегодня — чётко передать ей более широкий и полный замысел, а затем полностью отпустить её работать самостоятельно. Я помню, как в марте–апреле её способности уже сильно поразили меня — она не только способна единовременно выдать потрясающий результат, но и, что ещё более удивительно, понимает дальнейшее развитие функционала и общий контекст всего проекта.

И эта эволюция не прекращается. Утром сегодня я обсуждал работу с коллегой — в самолёте я осознал: «Я могу удалённо решить подавляющее большинство задач». Я даже перестал беспокоиться о потере Wi-Fi: стоит лишь задать моделью правильный контекст и инструкцию (например, команду с циклическим выполнением) до отключения интернета — и она доведёт дело до конца.

Последние два месяца я часто переживаю такие моменты: перед сном я говорю Claude «спокойной ночи» и даю сложную задачу, а утром обнаруживаю, что всё уже сделано — основная работа завершена к 2 часам ночи, а остальные четыре часа ушли на детальную доработку.

Больше всего меня поразила её способность автоматически завершать циклы. Например, она может рассуждать так: «Майк поручил мне выполнить сложную задачу сегодня вечером. Но я застрял — удалённый сервер упал. Хорошо, я сам напишу заглушку бэкенда, зафиксирую проблему в документации, запущу весь процесс, сохраню результат и исправлю всё, как только сервис восстановится». Для меня возможность делегировать задачи такого уровня и полностью доверять итоговому результату — поистине шокирующий опыт.

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

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

Майк Кригер:

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

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

Поэтому я продолжаю активно взаимодействовать с Fable. Иногда она предлагает кажущееся идеальным решение, и я уточняю: «Да, я планирую выпустить это в ближайшее время — но нужно учесть масштабируемость за пределами одного сервера». Такое двустороннее взаимодействие крайне важно. При проектировании архитектуры я часто прошу её сгенерировать HTML-страницу для визуализации нашего обсуждения, чтобы поделиться с командой. Подойдёт даже Markdown-файл, но я предпочитаю графические формы.

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

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

Такой режим работы с долгосрочным горизонтом и ощущением «Не волнуйтесь, я беру это на себя — потребуется время» действительно открывает большие возможности. Мы также исследуем на уровне продукта, как лучше поддержать такой опыт — вы, конечно, хотите сочетать «мгновенный отклик» и «долгосрочное фоновое выполнение», и их взаимодействие чрезвычайно интересно. Мой личный подход: всегда держать хотя бы один окно Claude с высоким контекстом и сверхбыстрым откликом, создавая ощущение: «Я всегда на связи — скажите слово, и я мгновенно запущу или порожу подзадачу».

Когда использовать Sonnet, а когда — Fable

Ведущий Дэн Шиппер: Например, вы идёте по улице и вдруг возникает вопрос — будете ли вы доставать Fable? Не будет ли это похоже на «стрельбу из ракетницы по комару»? Или вы часто переключаетесь между разными моделями?

Майк Кригер:

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

Но на прошлой неделе мне пришлось найти ответ на простой вопрос, о котором мне даже неловко было спрашивать — о финале NBA. Я переключился на мобильную версию Sonnet и мгновенно осознал: «Ах да! Раньше я всегда использовал Sonnet для таких быстрых запросов». Это совершенно разные уровни ощущений. Это даже не связано с количеством токенов в секунду — речь идёт о том, сколько „объёмов мозга“ требуется для решения задачи. Иногда простой ответ не требует столь глубокого и многослойного мышления.

Для нашей продуктовой команды это тоже очень любопытный вопрос. В целом, вы, конечно, не хотите, чтобы пользователи ежедневно выбирали модель в интерфейсе. В идеале, в долгосрочной перспективе, мы сможем сгруппировать их в несколько интуитивно понятных, готовых к использованию сценариев; или даже распределять их автоматически по типу интерфейса — ведь, честно говоря, большую часть времени, когда я открываю iOS-приложение, я почти наверняка не собираюсь решать какие-то задачи, требующие вмешательства Fable. Поэтому незаметное закрепление модели на уровне интерфейса может стать одним из решений. Нам предстоит тщательно изучить, что это значит на продуктовом уровне. Но эта тонкая настройка — «эта задача просто не заслуживает Fable — надо вызвать Sonnet» — я действительно ощутил в последнее время.

Вы правы: для частых, мелкозернистых интерактивных задач Fable склонна углубляться в рассуждения. Фактически, Fable — первая модель, с которой я стал активно регулировать «уровень усилий» (Reasoning Effort) — иногда я думаю: «Я просто хочу изменить стиль UI — достаточно установить средний уровень усилий и посмотреть результат». Раньше с Opus я почти не настраивал этот параметр, потому что диапазон масштабируемости модели был намного уже; у Fable же он действительно очень широк.

Что медиа-трекер Майка, собранный за выходные, раскрывает об архитектуре, ориентированной на агентов

Ведущий Дэн Шиппер: Можете показать нам, что вы создали с её помощью?

Майк Кригер:

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

Ведущий Дэн Шиппер: Вы запускаете это в терминальном приложении или в десктопном?

Майк Кригер:

Отличный вопрос. Большинство времени я всё ещё работаю в терминале. Но интересно, что моя жена — она не профессиональный инженер, её бэкграунд ближе к UX-дизайнерам и менеджерам продуктов — она по-настоящему влюбилась в Claude Code именно через десктопное приложение. Я думаю, десктопное приложение помогло ей избежать множества низкоуровневых абстракций. А для своего проекта я использовал Ghostty и терминал.

Мне нужен был идеальный «трекер прогресса в медиа» — я играю в игры, смотрю сериалы, получаю рекомендации от друзей и хотел инструмент, полностью соответствующий моим привычкам организации информации. Два моих главных требования: во-первых, добавление должно быть максимально простым — достаточно сказать Claude голосом или текстом, и она сама найдёт информацию в сети, дополнит её и распределит по категориям; во-вторых, система должна сама уведомлять меня о новых сезонах или продолжениях игр.

Большую часть UI Fable создала за один раз — это уже впечатляет. Но в этом году в Labs я сосредоточился на одной ключевой задаче: как ещё ближе сблизить команду разработчиков — а сегодня эта команда и есть Claude — с самим программным обеспечением?

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

У меня возникла идея: можно ли провести радикальный эксперимент — позволить ПО изменять само себя изнутри?

Я заставил её создать две версии — мобильную и веб-версию. У меня уже был интерфейс чата, где можно было сказать Claude: «Добавь этот URL в список отслеживания». Но я хотел, чтобы всё ПО обладало такой способностью — мне больше не хотелось рыться в многоуровневых меню в поисках функций.

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

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

У меня есть хороший пример: недавно мне порекомендовали бразильский сериал о радиационной утечке в Гоянии. Его название было длинным и сложным для запоминания, и я лишь приблизительно упомянул его системе — Claude мгновенно нашла и точно классифицировала его. Этот опыт намного лучше, чем самостоятельный поиск в Google по интуиции.

Но меня по-настоящему увлекает следующий шаг: что произойдёт, если в мобильном сценарии ПО сможет изменять само себя изнутри?

Я сделал — точнее, я приказал Claude сделать — следующее: в приложении долгое нажатие на кнопку чата пробуждает наш托管 агент для получения «инструкций по изменению кода», а затем мы используем функцию Live Preview от Vercel для немедленного просмотра результатов. Целый функциональный модуль был запущен практически мгновенно — это было очень круто, и позже я добавил ещё несколько идей. Если вы хардкорный игрок, вы можете просмотреть Diff (разницу в коде) или заглянуть в историю диалогов托管 агента, чтобы увидеть, что именно он изменил на низком уровне — хотя я почти никогда этого не делаю, потому что для личного проекта мне совершенно не важна его долгосрочная поддерживаемость (смеётся).

Это приложение вызывает привыкание. Когда я гуляю с ребёнком, я замечаю: «Эта плавающая кнопка в iOS расположена слишком низко», — и сразу говорю об этом в приложении. Агент сам отправляется в фон и исправляет код. С инструментарием Expo он даже выполняет горячую перезагрузку (Hot Reload) прямо на моём телефоне — это ощущение просто потрясающее.

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

Это не только блестящая демонстрация мощных инженерных возможностей Fable, но и концентрированное выражение того главного вопроса, который мы обсуждаем: как именно Claude должен быть встроен в программное обеспечение? Он не должен ограничиваться лишь „использованием“ — он должен проникнуть в самую „суть построения“ ПО.

Стоимость создания ПО рухнула

Ведущий Дэн Шиппер: Я хочу, чтобы все осознали: подобные инструменты вы могли бы создать и десять–двадцать лет назад, но совсем не таким способом. Стоимость создания ПО рухнула по отвесной траектории. Подумайте: сколько ресурсов требовалось в эпоху Instagram, чтобы вывести проект на такой уровень готовности? А сколько требуется сегодня? Помогите нам количественно оценить этот исторический сдвиг.

Майк Кригер:

Я часто вспоминаю те времена. В самом начале Instagram я считал себя чрезвычайно эффективным инженером — увлечённым мобильной разработкой и обладающим сильной интуицией в отношении продуктовой направленности. Тем не менее, даже при этом путь от идеи в голове до её полной реализации занимал минимум четыре–пять бессонных ночей. Бессонница была моей повседневной нормой: до четырёх утра, а затем сон до полудня — такой режим полностью исключал совместимость с семейной жизнью, но именно так я работал в режиме «Builder» (создателя).

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

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

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

И эта выгода уже выходит за рамки круга профессиональных инженеров и основателей, подобных мне. Раньше, если у вас была отличная бизнес-идея, но вы не умели писать код, у вас было всего два варианта: либо нанимать фрилансеров — что сопровождалось сильнейшей потерей информации и посредственным результатом, либо гнаться за инвестициями. Сегодня пропасть между „замыслом“ и „реализацией“ для обычных людей без знания программирования теперь ликвидирована.

На днях я получил сообщение от коллеги внутри компании. Мы настроили для неё внутренний инструмент, объединив возможности Fable с доступом к нашим внутренним MCP (Model Context Protocol). Она работает в HR (по подбору персонала), и она с восторгом сказала мне: «Это первый раз в моей жизни, когда я почувствовала, что то, что есть у меня в голове, и то, что существует в реальном мире, разделены буквально никаким расстоянием. Я могу реализовать это немедленно.»

Для неё этот момент стал поистине знаковым и шокирующим. Если бы это случилось четыре–пять лет назад, ей пришлось бы либо использовать готовые программы, пытаясь их склеить, либо умолять инженеров внутренней команды по разработке инструментов — а в их Jira-очереди, скорее всего, стояло ещё 50 задач с более высоким приоритетом. А сегодня? Она сама с удовольствием осваивает мир кода.

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

Умерла ли инженерия ПО?

Ведущий Дэн Шиппер: Я полностью согласен с вашей точкой зрения. Но, думаю, многие сейчас задаются фундаментальным вопросом: после всего, что вы описали, инженерия ПО как профессия окончательно умерла?

Майк Кригер:

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

Если бы вы задали мне этот вопрос в эпоху Instagram: «Что такое инженерия ПО?», я бы ответил: «Продумать сложные архитектурные задачи, построить систему и потратить массу времени в TextMate или Xcode — бороться с деталями Django ORM, деплоить, мучительно исправлять баги». Большая часть этого процесса сегодня перевернута с ног на голову и стремительно смещается в сторону продуктового управления. Сегодня граница между продуктовым менеджером и инженером стала чрезвычайно размытой. Это чётко проявляется в нашей собственной команде разработки.

Но если вы выйдете за рамки слишком жёсткого буквенного определения «инженерии ПО» и взглянете на более широкое понятие «производства ПО» или «разработки ПО» — не ограничиваясь лишь узкой областью написания кода программистами — вы увидите, что отрасль не только прекрасно живёт, но и занимает беспрецедентно важное положение.

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

Конечно, такая болезненная трансформация для многих проходит безболезненно.

В мире существует множество людей, которые глубоко увлечены «ручным написанием кода» как ремеслом. Я сам был таким. «Этот баг мучил меня три дня, а сегодня я решил его блестяще!» — это ощущение невозможно заменить. Раньше вы даже могли видеть код во сне — если у вас был такой опыт, то во сне у вас были логические конструкции, и вы просыпались с внезапным озарением. Эпоха чистого ремесла, скорее всего, действительно безвозвратно ушла.

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

Как работает команда инженеров Anthropic сегодня

Ведущий Дэн Шиппер: Поскольку утверждение верно — инженерия ПО не только жива, но и процветает — как же на практике работает ваша внутренняя команда разработки в Anthropic?

Майк Кригер:

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

Во-первых, по-прежнему много «человеческого согласования». Люди собираются в конференц-зале, проводят мозговой штурм по следующим шагам развития Cowork, а затем распределяют план по зонам ответственности участников. Этот этап остаётся критически важным, поскольку многие глобальные контексты, понятные только людям, пока недоступны Claude «на расстоянии» — например, реальные коммерческие цели продукта, текущие скрытые линии разработки, информация о продуктах, которые скоро будут сняты с производства или интегрированы в другие продукты весьма тонким образом.

Хотя в нашей команде каждому выделено по несколько «башен Claude», на уровне управления каждый по-прежнему несёт титул DRI (Directly Responsible Individual — непосредственно ответственный человек) и отвечает за конкретный модуль продукта. Я считаю, что этот механизм в ближайшее время никуда не денется, потому что «распределённое сотрудничество для совместного доведения продукта до совершенства» и «как мне сегодня заставить Claude выполнить эту конкретную задачу» — это принципиально разные уровни мышления. Хотя мы активно продвигаем минималистичный формат встреч, такие предварительные мозговые штурмы и согласования остаются необходимыми.

Во-вторых, много «асинхронного делегирования». Многие наши инженеры сами создали персональные дашборды для отслеживания деятельности своих «армий Claude»: «На каком этапе находится мой Claude Code?», «Что застряло в очереди на моё одобрение?», «Какие PR требуют моего вмешательства — потому что были отклонены другими коллегами или ревью-комментариями от большой модели?»

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

В-третьих, понимание того, как код работает в производственной среде. Это ещё одна передовая область, над которой усиленно работают крупные модели. Fable уже показал значительный прогресс в этой области, но путь ещё долог: например, глубокое понимание того, что происходит после развертывания кода. Системы могут падать, возникать самые неожиданные и странные сбои — честно говоря, с 2012 по 2016 год я потерял половину своей жизни на решение таких онлайн-аварий и масштабирование архитектуры. В чрезвычайных ситуациях роль старшего инженера остаётся незаменимой: вам нужны многолетний опыт реагирования на аварии, способность сохранять абсолютное спокойствие, собирать полные логи, экстренно останавливать утечку и затем разрабатывать долгосрочное коренное решение.

И наконец, я хочу подчеркнуть: роль «инженерного прототипа» сегодня кардинально изменилась.

Вы должны чётко определить, является ли ваш объект демо или готовым к запуску production-кодом. В Силиконовой долине раньше было популярно выражение «код побеждает споры» (Code wins arguments). Я никогда особо не соглашался с этим, поскольку в нём подразумевается, что владение кодированием даёт власть над дискуссией. Сегодня же ситуация развивается в обратном направлении: иногда мы долго не можем договориться о будущем продукта, и вдруг не пишущий код PM говорит: «Я только что собрал демо, хотя в 8 деталях оно ещё сыровато — но посмотрите, этот путь точно рабочий!» — и это мгновенно открывает совершенно новый, высокомерный уровень диалога.

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

Но единственное, что осталось неизменным с самого начала — чувство человеческой «собственности и ответственности» за продукт.

Механизмы верификации

Ведущий Дэн Шиппер: Fable тоже дорогая. Тестируя её, я чувствовал себя ребёнком в кондитерской: «Я хочу это, это и это!» Но когда доходит до оплаты, я каждый раз перед нажатием Enter сомневаюсь: «А не сожгу ли я этим 100 долларов или даже больше?» Я думаю, эта высокая цена фактически создаёт невидимый барьер для «кто может её использовать» и «для чего её использовать». Как вы оцениваете её коммерческую рентабельность?

Майк Кригер:

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

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

Модель уровня Fable идеально подходит для логики третьего этапа. Если вы постоянно демонстрируете высокие результаты и реально создаёте ценность в бизнесе, внутри компании естественным образом сформируется положительная бюджетная «петля», которая будет бесконечно вас поддерживать.

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

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

Сегодня „стоимость“ стала многомерным понятием — вы должны считать не только „стоимость одного запроса“, но и „общую стоимость полного решения задачи“. Именно здесь Fable производит наибольшее впечатление: она стремится сделать всё правильно с первой попытки, без необходимости сражаться с ней восемь-девять раундов у компьютера, отчаянно крича: «Нет! Я имел в виду не это!»

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

Майк Кригер:

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

Меня часто поражают её «божественные» действия. Например, только что написав код, она внезапно сама пишет: «Босс, я знаю, что в реальной production-среде конфигурация здесь может отличаться. Ваш переключатель функции включён? Если нет, то мой код не будет работать после деплоя.»

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

Такая способность к суждению чрезвычайно важна. Если бы я указал на самое большое улучшение, то это — её отказ от мгновенной «коленной» реакции «да, да, я исправлю». Она скорее говорит: «Дайте мне подумать. Я всё ещё не согласен». Это чрезвычайно полезно.

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

Ведущий Дэн Шиппер: Чат — это действительно наиболее подходящий интерфейс для этой модели? Он не пошаговый, а скорее похож на делегирование задачи кому-то. Как это влияет на то, как вы её используете, или как вы относитесь к этому интерфейсу?

Майк Кригер:

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

Первое: ноутбук — это правильное место? Вот почему я ранее упоминал, насколько удобно мобильное устройство для личных проектов. Создатели Claude Code всегда на полшага впереди в понимании, как используются модели: около девяти месяцев назад я говорил с ним, и он сказал: «Я перенёс большую часть своей работы с Claude Code на мобильное устройство». Я тогда был скептически настроен, но особенно на уровне Fable, поскольку она может поддерживать сессию, а у нас в Anthropic есть удалённые машины разработки, первый пункт — это отделение места выполнения работы от места обсуждения.

Второй пункт продолжает мою предыдущую мысль: как сделать всё, что Fable обсудила, решила и предложила, понятным для вас? Это область, над которой мы работаем. Есть некоторые функции, позволяющие ей рисовать диаграммы, но текущий интерфейс чата недостаточен: Fable иногда выдаёт огромные объёмы текста, и вам нужно выйти на прогулку, чтобы подготовиться к его осмыслению. Одна из вещей, которую я начал делать: «У вас гораздо больше контекста по этой задаче, чем у меня. Давайте вернёмся назад — и постепенно раскрывать сложность?»

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

Ведущий Дэн Шиппер: Это заставляет меня вспомнить, что я большую часть времени использую эту модель для своих личных проектов vibe coding, но при использовании в организации возникает проблема: действительно ли я понимаю все части, только что выполненные моделью? Как перенести контекст того, что модель только что сделала, в мою голову? Это серьёзный узкий момент. Как вы определяете границу «сколько я должен знать» и как гарантировать достаточный контекст для уверенности?

Майк Кригер:

Две основные составляющие. Первая — верификация. В начале года я полностью убедился в важности верификации, что связано с одной вещью из моего времени полной занятости написанием кода: найти самый короткий цикл разработки вокруг вашей идеи. В эпоху Instagram это иногда означало создать в Xcode новую цель сборки, содержащую только этот экран и синтетические данные, и итерировать только в этом цикле. Я обучал новых инженеров: «Если я научу вас чему-то одному, то это — создать такой цикл для вашего проекта, и работа станет гораздо быстрее».

Сегодня ситуация такова: каждый раз, когда я создаю что-либо, я гарантирую, что каждый PR от Claude сопровождается фото или видео — вне зависимости от того, речь идёт о PR для iOS или изменениях UI. Это даёт мне огромную уверенность. Fable может работать несколько часов, а затем сказать: «Готово», и вы видите «галерею скриншотов всего UI» — это чрезвычайно полезно. Вы скажете: «На скриншоте восемь — ошибка состояния, с которой я никогда не сталкивался, но я могу представить, как пользователь поведёт себя при её появлении. Давайте это исправим». Полная верификация — это то, чем мы активно занимаемся внутри.

Вторая составляющая: вы в конечном итоге несёте ответственность за выполненную работу. Многие ежедневно используют Claude, но сохраняют ответственность — «Claude написал код, но вам нужно понять, какие стратегические решения были приняты». Я вижу, как многие инженеры начинают практику: Claude завершает задачу, а затем следует последующий диалог — «Могу ли я убедиться, что я полностью понял все ваши компромиссы?» Независимо от того, какой маленький артефакт создаётся, если он делает понимание проще — он стоит усилий.

На встречах это особенно интересно — кто-то говорит: «Я подготовил PR», другой отвечает: «Вы сделали X или Y?», и наступает пауза: «Честно говоря, я не уверен — проверю перед слиянием». Адаптация к этой новой норме и освоение правил совместной работы — обязательный навык для всех нас.

Ведущий Дэн Шиппер: Упомянутый вами «цикл верификации» открывает огромные перспективы. Кроме автоматических скриншотов и демонстрации экрана, какие ещё «жёсткие» идеи вы исследуете?

Майк Кригер:

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

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

Визуальная верификация также критически важна, а видео — чрезвычайно недооценённый инструмент для Claude. Недавно я делал прототип: записывал видео того, что построил Claude, передавал ему вместе с FFmpeg и наблюдал, как он анализирует каждую кадровую последовательность, говоря: «Анимация тормозит — я это исправлю». Скриншоты никогда не смогут этого зафиксировать — ведь они пропускают мгновение.

Для частей, которые сложно протестировать end-to-end, очень интересно, чтобы Claude построил надёжный имитационный бэкенд или использовал существующий. В эпоху артефактов у нас в пред-LLM-эпоху уже была всесторонняя система тестирования. Каждый компонент инфраструктуры имел хорошую реализацию в памяти, которую можно быстро запустить в unit-тестах. Теперь мы переносим это в область Claude: я создаю что-то с устойчивым бэкендом, который сложно запустить на моём сервере разработки, и Claude сразу же создаёт отличный заменитель. Со временем этот заменитель эволюционирует вместе с кодом. Раньше я бы сказал: «Синхронизация займёт слишком много времени». Теперь я думаю: «Claude прочитает изменения и адаптирует заменитель, поддерживая синхронизацию. Этого достаточно.»

Ведущий Дэн Шиппер: Есть очень интересные архитектуры: когда вы получаете баг, агент автоматически его исправляет и сообщает клиенту: «Исправлено». Заметили ли вы изменения в этом процессе на Fable?

Майк Кригер:

Несколько аспектов. На уровне взаимодействия человека и Claude я повторно наблюдаю следующее: если кто-то сообщает баг в канале обратной связи Slack, эта нить передаётся в сессию Claude Code. Благодаря Slack MCP она может действительно получить эту нить и ответить от моего имени: «Это Claude от Майка, я исправил, вот ссылка на PR». А затем она добавит: «Не спешите — ещё не в продакшене. Уведомлю вас, когда выйдет». Через несколько часов: «Этот деплой вышел. Проверьте, исправлено ли?» Такое замкнутое сопровождение — относительно новое явление. У меня есть несколько долгосрочных сессий Claude Code, которые взаимодействуют от моего имени. Я также вставил в них заявления об отказе от ответственности.

Второй аспект возвращается к нашему предыдущему разговору о вкусе и суждении. Один уровень — «есть баг, значит, нужно исправить», другой — наличие хорошего суждения. На выходных у меня был случай: у нас была внутренняя система, которая давно не перезагружалась и начала «течь» по памяти. Хорошее суждение: «Майк, сейчас выходные. Перезагрузите сервер — это решит проблему прямо сейчас, а я асинхронно сделаю PR для долгосрочного исправления». Если вы хотите, чтобы Claude участвовала в этом цикле «баг → исправление», вы действительно хотите, чтобы она понимала то, что любой хороший SRE или инженер понимает: решить текущую проблему, а вопрос о замене платформы или рефакторинге — это отдельная история. Понимание этого баланса крайне важно.

Что стоит создавать с помощью этой модели

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

Майк Кригер:

Несколько идей — начнём с весёлых. У людей всегда есть креативные идеи о том, как выразить сложность их мира, в каждой области есть что-то, что вы особенно хорошо знаете, и всегда есть вариант: «Как я могу это объяснить другим? Могу ли я применить технологии из другой области к своей?» Возьмём мою жену: она недавно увлечённо изучает инженерию окружающей среды — в основном геотермальную энергию, где царят головокружительные математические модели и гидродинамические симуляции. Но с прорывным скачком в возможностях моделей рассуждения, подобных Fable, она успешно интегрировала технологии, совершенно не входящие в её профессиональную сферу, в собственные научные исследования. Сейчас она даже может приказать Fable построить полноценную end-to-end глубокую нейросетевую симуляционную систему на PyTorch — что для неё, учёного-неинформатика, было бы просто фантастикой ещё недавно.

Второе — её способность комбинировать ПО для решения ваших уникальных задач. Большую часть внутренней работы мы посвящаем преобразованию как можно большего числа внутренних систем в MCP-формат с правильной системой прав и настройками развертывания. Снаружи есть отличные PaaS-платформы — вы просто спрашиваете Claude, и она всё настраивает. Но мне особенно нравится ощущение «я создал то, что всегда хотел».

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

Это как раз и раскрывает самую недооценённую и самую «сексуальную» черту этой модели: на предыдущих поколениях моделей у проектов часто существовал «потолок сложности». Как только объём бизнес-логики или кода достигал определённого размера, большая модель начинала «смотреть только вперёд, забывая о хвосте», и добавление новых функций вызывало каскадные ошибки, полностью разрушая существующую архитектуру.

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

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

Динамические рабочие процессы

Ведущий Дэн Шиппер: Вы упомянули ещё одну очень мощную вещь — динамические рабочие процессы. Расскажите подробнее?

Майк Кригер:

Внутри мы часто создаём подобные передовые инструменты, а затем я в офисе «гоняю» инженеров, которые их пишут: «Когда же это наконец выйдет в публичный доступ?» Иногда это действительно связано с ограничениями базовой инфраструктуры, и приходится сначала запускать внутренне, но мы делаем всё возможное, чтобы как можно скорее вывести эти «драгоценности» на рынок. Для меня динамические рабочие процессы — это поистине глобальный прорыв.

Модель уровня Fable особенно сильна по двум причинам. Во-первых, она помогает создавать каркас для глубокой, содержательной работы. Самое безумное, что я делал с ней, — это бросить Fable сложный внутренний Python-проект и поручить ей полностью переписать всю ключевую бизнес-логику на TypeScript — у нас был конкретный производственный аргумент.

В эпоху Instagram руководство серьёзно обсуждало: «Не стоит ли полностью переписать базовый код IG на языке Hack, чтобы бесшовно интегрировать его в инфраструктуру Facebook?» Наш вывод был: «Никогда. Это совершенно нереально.»

Но на прошлых выходных я столкнулся с аналогичным запутанным кодом, и просто отправил ему динамический рабочий процесс в фоновом режиме, а сам ушёл на выходные. Я задал ему следующий цикл: глубоко изучить существующий код, сгенерировать документ, похожий на спецификацию, описывающий, как всё работает, затем поэтапно переводить модули, проводить пошаговое тестирование, выполнять антагонистическую проверку и контролировать отсутствующие элементы. Когда я в понедельник вернулся к работе и открыл ноутбук, произошло чудо — это уже была новая система, работающая в стеке TypeScript и Bun, и на некоторых архитектурных уровнях она даже оказалась элегантнее и быстрее моей оригинальной Python-версии.

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

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

Майк Кригер:

Весь процесс настройки был наполнен хакерским удовольствием от итераций. Я просто открыл Claude Code и сказал: «Брат, у меня сейчас крайне сложная задача по рефакторингу — давай вместе спроектируем полностью автоматизированный рабочий процесс.»

Она показала мне план, я сказал: «Это близко, но мне нужно три-четыре дополнительных уровня проверки, чтобы убедиться, что ничего не упущено». Она ответила: «Вот ваш план. Готовы?» Рабочий процесс выражается в виде кода, и я считаю это чрезвычайно ценным — вы видите, как именно он будет работать.

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