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