Статьи
Потолок ИИ — это ваши амбиции: четыре измерения — скорость, высота, глубина и охват
Руководитель инженерного направления Anthropic Феликс Ризеберг разложил «быть амбициознее в работе с ИИ» на четыре измерения: скорость, высота, глубина и охват. В статье — его приёмы и примеры, а также мои практические заметки: целеориентированные инструкции и команда экспертов из Multi-AI Agents для перекрёстной проверки с разных точек зрения повышают качество задач.
· 1 мин чтения
Руководитель инженерного направления Anthropic Феликс Ризеберг (Felix Rieseberg) в статье «How to be more ambitious: A tutorial for humans with models» пишет: когда он видит, какие поразительные результаты другие получают с помощью ИИ, у него и у людей вокруг обычно одна и та же реакция: «Нам не хватает амбиций».
Моя интерпретация такая: потолок использования ИИ человеком чаще всего определяется его собственными амбициями и воображением, а не моделью.
Он разложил «амбиции» на четыре измерения:
- Скорость (Speed): ту же работу делать за меньшее время.
- Высота (Altitude): подняться на более высокий уровень абстракции и смотреть на конечный результат, а не на отдельную задачу.
- Глубина (Depth): работать по стандартам, с инструментами и методами ведущих экспертов предметной области.
- Охват (Range): выйти за рамки одной области и искать решения на стыке дисциплин.
Сначала вывод: если точно давать целеориентированные инструкции и управлять командой экспертов из Multi-AI Agents, организуя совместную работу с разных точек зрения и перекрёстную проверку, то качество задач поднимается в целом.
1. Скорость: самое базовое, и здесь застревают реже всего#
Та же работа за меньшее время. Феликс считает, что это все уже хорошо знают, и в статье он эту тему сразу пропускает.
Моё мнение: скорость — самая очевидная ценность ИИ, но если гнаться только за ней, способ совместной работы почти не изменится. Настоящую разницу создают три остальных измерения.
2. Высота: спросите о «цели за целью»#
Ключевой вопрос: какой результат на самом деле нужен следующим шагом? Какая цель стоит за этой целью?
Примеры Феликса:
- От исправления одного краша — к приложению, которое больше не падает. Сначала он просил Claude исправить один краш, потом изменил задачу: приложение должно оставаться с нулём крашей. Чтобы это можно было гонять автоматически и постоянно, ему пришлось сначала поменять собственный процесс: сделать отчёты о крашах легкодоступными, сопоставить версии приложения с Git-коммитами, дать Claude возможность воспроизводить и проверять исправления на машинах с Windows, macOS и Linux.
- Квартальный бизнес-обзор (QBR) в три этапа:
- Как можно полнее опираться на сырые данные и объяснить, что изменилось за квартал, почему и что делать дальше.
- Найти 3 самых срочных решения и для каждого записать аргументы «за» и «против».
- Спроектировать альтернативный механизм, который выявляет проблемы раньше, чем квартальная презентация, проверить его на исторических данных и один квартал гонять параллельно с действующим процессом.
Он также оговаривает границы: в 2026 году расплывчатая цель вроде «Claude, заработай мне денег» ещё не работает, но он ожидает, что уровень абстракции, который модели способны обработать, будет расти.
3. Глубина: равняйтесь на спецификации ведущих экспертов области#
Подход Феликса:
- Используйте инструменты, которыми в этой отрасли реально пользуются. Модели часто меняют только формулировки, но не метод: бросают таблицу в Markdown и считают дело сделанным. Настаивайте на настоящих аналитических инструментах — базах данных, статистических моделях.
- Ставьте цели, которые выглядят неразумными, и говорите модели, что они достижимы. Его пример: после того как загрузка сайта ускорилась с 10 до 5 секунд, он потребовал 200 миллисекунд. Когда модель отступает, настаивайте, что цель можно достичь.
- Оспаривайте то, во что вы сами верите. Дайте модели сырые данные и проверяйте гипотезы в состязательном ключе. Например: «Мы считаем, что отток связан с онбордингом; попробуй воспроизвести этот вывод по сырым данным».
- Создавайте новое знание. Построить по логам симуляцию, найти самые ранние сигналы оттока, которых вы ещё не знали, и проверить их на данных, которых модель не видела.
- Найдите внешнего судью (Outside Judge). Не позволяйте модели проверять саму себя. Лучше всего подключить инструмент, который модель может запустить напрямую и сразу получить обратную связь.
Его принцип для промптов: нужна «более глубокая версия», а не «более крупная версия». Попросите модель сказать, что сделал бы сверх этого ведущий профессионал, где лежат самые первичные данные, какие методы и инструменты нужны и что, кроме суждения модели или вашего собственного, может доказать правильность результата.
4. Охват: глаголы вместо существительных, соберите команду экспертов#
- Глаголы вместо существительных. Эту идею Феликс заимствует из книги «The Art of Innovation». QBR — это не «презентация», а «за 30 минут помочь занятым людям понять причинно-следственные связи и принять решение в условиях неопределённости». Если определять цель глаголом, становится видно, какие компетенции из каких областей нужны.
- Соберите команду. Для хорошей презентации нужны аналитик, журналист и редактор; для выступления на сцене добавьте специалистов по анимации и звуковому дизайну. Для состязательной проверки возьмите исследователя из шортселлерской фирмы и судебного бухгалтера.
- Не занимайтесь бессмысленной ролевой игрой. Не говорите модели «пиши в тоне шортселлерской фирмы», а попросите её по-настоящему применить метод, которым шортселлерская фирма исследует один из участков. Если сменить только тон, результат лучше не станет.
Условие: у модели должен быть компьютер, на который можно устанавливать программы, и она должна получать нужные данные, например через MCP-коннекторы.
5. Мои практические заметки: от «передачи данных» к «достижению намерения»#
Ниже — моё развитие темы на основе программной архитектуры и инженерной практики; в оригинальной статье этого нет.
1. Jobs to be Done и подход, ориентированный на намерение (Intent-Based)#
- Спрашивайте не «что делать», а «чего достичь». Дизайн не должен останавливаться на пассивном конвейере передачи данных вроде
generate_deck_pdf(); его нужно поднять до намерения, описывающего смену состояния, например resolve_leadership_uncertainty_and_commit_budget().
- Определите настоящую функцию потерь. Если требовать только артефакт, модель выдаст безупречно выглядящую воду; если требовать снять неопределённость в решении, модель и её Sub-agent сами начнут закрывать логические пробелы и границы рисков.
2. Расходимся при исследовании, сходимся при приёмке#
- При исследовании сначала расходитесь в поисках возможностей, затем сходитесь.
- При приёмке больше не расходитесь. Не задавайте безграничных вопросов вроде «Как ещё можно это сделать?» — в ответ вы получите только общие слова.
- Чётко пропишите рамки цели, ограничения и объективные инструменты проверки (конкретные тестовые скрипты, пороговые значения бизнес-метрик), чтобы команда Multi-Agent проводила стресс-тест в сфокусированных рамках и выдавала результат высокого качества.
Итоги#
- Ориентация на цель: глаголы вместо существительных. Сдавайте результат, решающий проблему, а не артефакт, созданный лишь для галочки.
- Исследование и сходимость: при исследовании расходитесь в поисках возможностей, при приёмке строго сходитесь и проверяйте границы.
- Абстракция и фокус: отталкивайтесь от ключевого вопроса и перестраивайте весь процесс выполнения задачи.
- Экспертная глубина: не просто копировать тон эксперта, а заставлять модель решать задачу инструментами и методами ведущих экспертов.
Оригинал: How to be more ambitious: A tutorial for humans with models (Феликс Ризеберг, 2026-10-13)