Гиперпродуктивность: следующий этап ИИ?

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

Это AI-перевод статьи, сделанный каналом Про AI: Лучшие Статьи и Исследования.

Гиперпродуктивность: следующий этап ИИ?

Hyperproductivity: The Next Stage of AI? Автор: Steve Newman Оригинальный текст:

Недавно я слышу о новом явлении: команды, использующие агентные (agentic) ИИ-инструменты для «выхода на взлёт» — достигая поразительной продуктивности, которая возрастает каждую неделю, без видимого предела.

У этих команд четыре общие черты:

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

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

История пекинского вайб-кодера

Афра Ван недавно опубликовала увлекательную Историю пекинского вайб-кодера. Это её рассказ о Лю Сяопае — китайском программисте, который использует ИИ-инструменты для выпуска продукта за продуктом. Работая преимущественно в одиночку, он сейчас имеет «одну-две дюжины приносящих доход продуктов» и сообщает о чистой прибыли более $1 000 000 в год. Для сравнения: типичному стартапу требуется много людей для создания и поддержки одного продукта.

Лю Сяопай использует ИИ-инструменты не только для написания кода. Он автоматизирует, как говорится в статье, «весь жизненный цикл продукта». Например, когда у него появляется идея нового продукта, он использует Claude Code для мозгового штурма названий и поиска свободного доменного имени:

>

>

>

>

Лю Сяопай описывает, как использует ИИ для многих аспектов своей работы — не только для написания кода. Но гиперпродуктивные команды не просто используют ИИ — они создают собственные ИИ-инструменты.

Неудивительно, что наиболее агрессивные способы применения ИИ находят в основном программисты. Программисты известны своей страстью к автоматизации — не только работы клиентов, но и своей собственной. Как знаменито сказал инженер DEC Дик Сайтс: «Я предпочту писать программы для написания программ, чем писать программы». Сегодня это выражается в том, что инженеры используют ИИ для создания кастомных инструментов, настроенных под их личный рабочий процесс.

Superpowers: кодификация лучших практик

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

Инструмент Джесси предоставляет Claude серию промптов, которые инструктируют модель подходить к каждой задаче по тщательному плану:

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

Я опустил много деталей, но суть в том, что этот процесс разбивает каждый проект на задачи, которые ИИ-агент может выполнять самостоятельно, и вставляет достаточно перекрёстных проверок, где агент способен уточнять свою работу. Как ещё одну перекрёстную проверку, рабочий процесс инструктирует агента использовать методику, известную как «разработка через тестирование» (test-driven development). Это означает, что прежде чем агент напишет какой-либо код, он сначала создаёт тестовый код, который будет оценивать, работает ли реальный код корректно. Если тесты не проходят, агент будет пересматривать свою работу, пока они не пройдут.

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

>

>

>

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

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

Инструменты, которые улучшают себя

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

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

Amplifier: эксперимент, который начинает ускоряться

Он не единственный инженер, идущий по этому пути. В статье Amplifier: Заметки об эксперименте, который начинает ускоряться инженер Microsoft Брайан Крабах описывает Amplifier — богатый инструментарий, созданный для облегчения практики переноса продвинутых навыков из головы программиста в инструмент. Цитата с главной страницы проекта:

В своём посте Брайан (ведущий инженер) объясняет, как Amplifier используется для улучшения Amplifier:

>

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

>

>

>

Я знаю как минимум три примера команд, работающих в этом стиле, создающих инструменты, которые создают инструменты для улучшения их инструментов создания инструментов. Сэм Шиллаче, руководитель команды Amplifier (и мой соучредитель Google Docs), называет их накапливающимися командами — и все они сообщают об удивительной продуктивности, которая продолжает расти по спирали. Это «оно»? Мы наблюдаем рассвет сингулярности?

Почему я всё ещё настроен скептически

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

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

Они все работают над новыми, маленькими проектами (насколько нам известно). Разработчики ПО в основном тратят время на расширение и поддержку больших, зрелых проектов. Я имею в виду не только монстров вроде Microsoft Office; даже «выскочки» как Slack, Notion или Figma давно выросли в сложные кодовые базы. Не говоря уже о огромной массе устаревшего ПО, которое работает внутри вашего автомобиля Toyota или за кулисами в United Airlines. Самый старый и крупный проект, над которым команда Amplifier сообщала о работе — сам Amplifier. Если эти методики успешно применяются в более крупных, запутанных средах, я об этом ещё не слышал.

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

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

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

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

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

Это изнурительно

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

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

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

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

Определение гиперпродуктивности

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

>

Открытые вопросы и что наблюдать

Остаётся много открытых вопросов. Насколько велик прирост продуктивности? (Он определённо будет варьироваться в зависимости от команды и задачи.) Каков диапазон ситуаций, для которых ИИ-системы обладают необходимыми возможностями? Сколько людей потянется к этому стилю работы? Какие навыки требуются, сколько людей ими обладают, сколько могут их освоить и сколько времени это займёт?

Если это станет чем-то большим, чем нишевое явление, мы должны ожидать следующего:

• Драматический рост числа гиперпродуктивных команд.
• В частности, сдвиг к командам, использующим «готовые» фреймворки гиперпродуктивности (как Amplifier), а не создающим свои рекурсивные инструментарии с нуля.
• Применение этого подхода в широком диапазоне ситуаций, некоторые с масштабным влиянием; не только крошечные команды, работающие над проектами с чистого листа и чётко определёнными задачами.
• Потенциально, широкое использование за пределами разработки ПО.

Будет очень интересно посмотреть, приживётся ли этот подход внутри лабораторий, разрабатывающих передовой ИИ. (Конечно, это может уже происходить. К слову, немногие анекдотические отчёты, которые у меня есть, предполагают, что нет.) Возможно, именно так «взрыв интеллекта» впервые проявится.

Мы должны особенно следить за тем, развиваются ли Claude Code, OpenAI Codex или Google Jules для поддержки методик накопления навыков и самосовершенствования, которые используют гиперпродуктивные команды, и особенно за признаками того, что ведущие ИИ-лаборатории приоритизируют эти возможности в процессе обучения моделей. Возможно, это может стать следующим большим направлением прогресса ИИ, подключаясь, если обучение с подкреплением (reinforcement learning, RL) начнёт терять обороты.

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

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

Если и когда этот новый стиль «накапливающейся» работы станет мейнстримом, я не думаю, что немедленное влияние будет глубоким. Требуется время для адаптации рабочих процессов к полному использованию новой технологии. Если инженеры Microsoft смогут работать в десять раз быстрее, Windows и Office не станут в десять раз лучше. Возможно, они смогут выпускать обновления Office в десять раз чаще, но будет ли это даже желательно?

Мы должны искать крупное влияние, когда этот подход будет развёрнут в лабораториях, разрабатывающих передовой ИИ. Тем временем, что мы скорее всего увидим — цунами быстро движущихся стартапов. Эра ИИ уже оказывала этот эффект — и из-за возможности создавать новые приложения на базе ИИ (как Cursor — компания, которая за три коротких года достигла массового внедрения и оценки в $29 миллиардов), и потому что ИИ-инструменты подстёгивают продуктивность гибких стартап-команд (см. историю Лю Сяопая выше). Стартапы найдут способы принести гиперпродуктивный подход во всё большее число областей, и результаты будут драматичными. Закончу цитатой из Видения Amplifier:

Приложение

Несколько идей, которые не вошли в основную часть:

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

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

1. Джесси Винсент описывает особенно впечатляющий случай использования:

>

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

Подпишитесь на канал и каждый день читайте лучшие материалы про AI переведенные на русский!

Нашли интересную статью для перевода? Пришлите нашему боту: @ailongreadsbot