Як зберігати критичне мислення, коли AI-агенти беруть на себе роботу

Автор: Addy Osmani (команда Anthropic Claude Code, відомий технічний архітектор)

Переклад: Deep潮 TechFlow

Огляд Shenchao: З поширенням агентних робочих процесів інженери-програмісти та продуктові команди переживають глибоку трансформацію парадигми людино-машинної співпраці. Колишній когнітивний буфер, який раніше виникав між запитанням та відповіддю, зараз стиснувся до кількох секунд; зі зростанням реалістичності та точності великих моделей явні помилки різко зменшилися, але люди поступово занурюються у «когнітивну капітуляцію» через задоволення від підпорядкування, а системне розуміння та базові навички невідомо прискорено згасають.

Як колишній керівник інженерів Google Chrome та ключовий член команди Anthropic Claude Code, Адді Османі в цій статті системно аналізує феномен поступового зсуву від «когнітивного розгрузки» та «відкладання судження» до «когнітивної здачі». Він не лише глибоко розбирає механізми прихованого накопичення боргу системного розуміння, але й пропонує практичну та захисну стратегію активного читання та контраргументації для щоденних робочих процесів, пояснюючи, чому навіть у майбутньому, коли ШІ матиме вищу ймовірність успіху, людина все ще повинна незламно триматися за межі відповідальності та критичного мислення.

Колись у школі навчали критичного мислення — вимагали підходити до нової інформації з скромною цікавістю та помірною скептичністю: збирати різні думки, слухати всі боки, щоб у кінцевому підсумку сформувати власну незалежну думку. Цей принцип залишається актуальним і сьогодні, але зараз, коли майже вся моя щоденна робота передана агентам, в реальному житті майже ніщо більше не змушує мене застосовувати критичне мислення.

Для інженерів і продуктів, які повністю прийняли робочі процеси з агентами, одночасно запускаючи кілька сесій у повсякденному житті та очікуючи постійного вдосконалення продуктивності моделей, я хочу зазначити: сам я є вірним прихильником цих інструментів. Я написав цю статтю не з метою закликати вас зменшити використання робочих процесів з агентами.

Моя основна мета — допомогти вам зберегти власне критичне мислення у світі, де все можна легко передати агентам.

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

Навіть якщо ви одночасно запускаєте десятки агентів, остаточну оцінку результатів все одно здійснюватиме лише ваше власне око.

Ви повинні свідомо впроваджувати критичне мислення у повсякденні процеси, бо в стані за замовчуванням жодна зовнішня сила не буде захищати вас.

Частинною причиною того, що людям важко виправляти власні помилки, є те, що досвід роботи з агентними потоками надзвичайно приємний. У напружені дні отримати швидко гідну, зручну й загалом правильну відповідь — справді піднімає настрій; але саме це й стає середовищем, де люди легко повністю знищують увагу і здаються.

Під час обговорення цього явища з колегами я зазвичай зображую його як неперервний спектр:

На вершині спектру знаходиться «когнітивне вивантаження» (Cognitive Offloading) — передача конкретних та складних завдань на виконання ШІ, при цьому людина завжди зберігає повну власність та відповідальність за кінцевий результат. Я сам постійно це роблю, і ви також повинні це робити.

На середині спектру знаходиться «відкладення судження» (Deferral), коли результат, що видає інструмент, безпосередньо стає вашим наступним вхідним даним, а вихідний контент більше не розглядається як гіпотеза, яку потрібно перевірити.

А найнижчою точкою на спектрі є «когнітивна здача»: вивід ШІ непомітно перетворюється на вашу власну позицію, і ви інстинктивно вважаєте, що немає жодної потреби перевіряти його.

Термін «когнітивна капітуляція» було запроваджено Стівеном Шоу та Гідеоном Нейвом з Університету Пенсільванії. Він дуже точно відображає мої недавні спостереження: зі зростанням довіри до інструментів (або виникненням лінності) люди неусвідомлено повільно ковзають уздовж цього спектру.

Цей зсув часто надзвичайно непомітний і важко виявляється, бо кожен крок відбувається поступово і на момент виглядає логічним: ви уважно прочитали попередню відповідь, тому наступного разу обмежуєтеся поверхневим ознайомленням; ще далі — просто переглядаєте структуру; а потім, коли хтось вказує на якийсь рядок коду і запитує про нього, ви здивовано розумієте, що навіть з допомогою агента не здатні пояснити його базову логіку.

Це й є типовий акт інтелектуальної здачі. Саме тут поступово накопичується «когнітивний борг». Цей борг зазвичай виявляється, коли ви намагаєтеся викликати глобальну ментальну модель системи, але виявляєте, що в вашій голові порожньо.

Вчена Маргарет-Энн Сторі писала, що це проявляється в командній роботі як поступове знищення спільного розуміння теорії систем. Я також писав про відповідне явище на рівні коду — «борг розуміння» (Comprehension Debt, термін запропонований Джеремі Твей). У повсякденній роботі з кодом цей борг повністю невидимий: кодова база виглядає чисто й елегантно, усі автоматизовані тести проходять зеленим. Але щойно система вимагає архітектурної рефакторингу, усі зупиняються, дивлячись один на одного: в команді не знайшлося жодної людини, хто би справді розумів цю систему. Те саме відбувається, коли ви лише кидати погляд на зміст стратегічного плану або технічної специфікації і підписуєте її без глибокого розуміння.

Варто зазначити, що я не закликаю до нереалістичного перфекціонізму. Вимагати від інженерів постійного утримання повної ментальної моделі всієї величезної сучасної кодової бази в голові неможливо. Раніше команда Claude Code відкрито заявляла, що зараз вони використовують стратегію «відновлення розуміння за потреби»: коли потрібно змінити певний модуль, просто дозволити Claude на місці пояснити логіку цього фрагмента, а не намагатися утримувати глобальну картину в голові.

Як я вже зазначав раніше, ця заборгованість у локальному розумінні насправді легше виправити, ніж більшість інженерів уявляють. Якщо ви можете в будь-який момент відновити локальне розуміння, вам не потрібно постійно підтримувати повну картину. Але головне: ви повинні чітко усвідомлювати, де саме у вас є сліпі зони.

У дрібних справах, де витрати на помилки мінімальні, ви можете сміливо повністю передати право прийняття рішень. Але якщо ви стикаєтеся з ключовим питанням, навіть коли агент не може пояснити його базову відповідь, ви фактично повністю втрачаєте власність на систему.

Звичайно, це не означає, що в усіх ситуаціях потрібно ставитися з надмірною увагою. Нещодавно мені потрібно було записати курс, і мені треба було вибрати місце для зйомок серед трьох готелів з майже однаковими рейтингами. Я не мав часу детально переглядати величезну кількість відгуків гостей, тому я повністю поклав це рішення на штучний інтелект. Результат виявився дуже задовільним, і в наступних подібних ситуаціях я знову зроблю саме так.

Але щодо інвестування у ключові активи, планування кар’єри дітей або при прийнятті рішень у роботі — що розробляти, які реальні користувачі постраждають від змін, чи відповідає код стандартам безпеки для запуску — я ніколи не передам право прийняття рішень іншим. На периферії, де вартість помилки низька, ви можете вільно делегувати; але в ключових етапах, де інші повинні платити за наслідки, ви повинні міцно триматися за людську логічну міркування.

Коли раніше я потрапляв у хаос мислення, я зазвичай повертався до списку надзвичайно простих базових питань: Як я знаю, що розв’язую правильну проблему? Як я знаю, що вибрав правильний шлях розв’язання? Чи існують чіткі об’єктивні докази, що підтверджують мої висновки? Як я переконуюся, що ця робота завершена повністю? Більшість разів це просто класичні п’ять «Х» журналістики: хто, що, де, чому, коли та як. Коли вони записані на папері, вони здаються наївними, навіть дитячими, але змушують вас розглянути проблему з тих аспектів, які зазвичай залишаються поза увагою.

У цю епоху людям занадто легко пропустити всі ці складні міркування і звернутися до агента з питанням: «Як ти вважаєш, що мені робити?». Тому я оновив для себе новий список рефлексій для епохи агентів:

• Перед тим як задати питання, чи сформував я власну початкову гіпотезу? Перед тим як запустити агента для вирішення будь-якої нетривіальної задачі, я змушую себе записати (у голові або на наклейці) те, як, на мою думку, може розвиватися відповідь. Навіть якщо це груба, погана припущення — це абсолютно нормально. Після отримання нової інформації ви завжди можете змінити або спростувати свою думку. Але якщо ви спочатку прочитаєте надзвичайно витончений і плавний згенерований відповідь, вам буде важко уявити будь-яку іншу можливість. Якщо у вас немає жодних ідей, спробуйте «метод запитань для виявлення сліпих зон», запропонований Таріком Шіхіпаром: викладіть усі відомі вам факти і попросіть модель допомогти вам знайти невідомі невідомі».

• Я використовую його як допоміжний інструмент для міркувань, чи передаю йому сам процес мислення? Обидва підходи дозволені, але ключове — зберігати абсолютну свідомість і чітко розуміти, у якому стані ви перебуваєте зараз.

• Які умови повинні бути виконані, щоб цей план повністю не спрацював? Після того як ви це зрозуміли, негайно перейдіть до практичного тестування. Самооцінка довіри моделі до власної відповіді має набагато меншу цінність, ніж ваш особистий реальний тест, тому встановіть для нього справжній тестовий виклик.

• Чи слухав я аргументи з протилежної точки зору? Коли я утворюю тверду позицію щодо відкритого питання, я прошу модель виступити у ролі критичного опонента і навести найсильніші контраргументи проти моєї позиції. Це не обов’язково для того, щоб спростувати моє рішення, а для того, щоб змусити себе зіткнутися з небажаними сліпими зонами, які в інших обставинах були б ігноровані.

• Якби мені треба було самому захищати цей результат, я б що сказав? Тимчасово закрийте вікно агента і спробуйте пояснити цю ідею колегам простими словами, власними словами. Якщо ви відчуваєте, що запинаєтеся і не можете чітко пояснити — це означає, що ви ще не розумієте це справді, і просто механічно повторюєте те, що каже ШІ.

У пасивному режимі читання ваш мозок лише механічно ковзає по заданому тексту, пасивно приймаючи потік інформації. Оскільки текст, що генерується агентами, зазвичай добре написаний, добре відредагований і не має граматичних помилок, пасивне читання в такій обстановці дуже легко призводить до помилкового переконання, що ви повністю зрозуміли суть. Це схоже на те, як ви на технічній конференції дивитеся, як виступаючий експерт демонструє плавні операції з архітектурою, і ви народу киваєте головою, вважаючи все зрозумілим, але коли повертаєтеся до готелю й відкриваєте порожній редактор, ви розумієте, що не здатні написати навіть перший рядок коду.

Активне читання — це дія, що заснована на скептичному припущенні. Воно не лише звертає увагу на те, що написано в тексті, а й наполегливо запитує: чому це написано саме тут? Які ключові складності воно уникнуло? Чому саме цей підхід був обраний, а не інший?

Щодо довгих схем, створених агентами, я зазвичай читаю їх із двома дуже чіткими критичними поглядами:

Спочатку знайдіть ті «відсутні контексти»: які припущення він вважає самозрозумілими? Чи не пропускає він певних крайніх випадків? Коли виникає конфлікт між двома вимогами, на яких принципах він тихо робить за вас вибір?

Другим кроком є активне постановлення «контраргументів»: як ця архітектура розвалиться, якщо обсяг одночасних запитів раптово зросте в десять разів? Що станеться, якщо зовнішні залежності від сторонніх сервісів відключаться на півгодини? Краще активно взяти скальпель і провести стрес-тестування, ніж пасивно читати готові відповіді.

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

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

Вважайте агентів точильним каменем для мислення, а не його замінником.

Написання коду та перевірка коду — це абсолютно різні навички мислення. Перед масовим потоком згенерованого коду людська перевірка легко втомлюється і перетворюється на сліпу підписку «штампом».

Тож під час перевірки змін у коді (Diff) обов’язково уявіть, що цей код не був написаний могутнім ШІ, а поданий новоначатим стажером. Ще важливіше — не зосереджуйтесь лише на доданих чи видалених рядках коду, а проникніть крізь поверхневий код і запитайте себе: які важливі дрібні рішення агент приховано прийняв замість вас? Які значення за замовчуванням він обрав? Які складні логічні елементи він тихо виключив із цього діапазону? Коли виник конфлікт між двома вимогами до продукту, яку з них він приховано переосмислив?

Якщо звіт лише поверхнево повідомляє вам «все добре, всі тести пройдені», ви ніколи не побачите внутрішньої картини ключових рішень. Тож чітко вимагайте, щоб у ньому була окрема таблиця: перелік суб’єктивних припущень і компромісних рішень, прийнятих під час цього завдання. Потім проведіть випадкову перевірку себе: випадково позначте дві-три ключові рядки коду і запитайте себе, чому саме так було написано? Якщо це проектний документ, закрийте сторінку і спробуйте повністю відтворити на пам’ять основні аргументи для когось іншого. Я дуже люблю одну жорстку практику, яку впроваджують деякі команди: щоб агент у кінці звіту про зміни додав набір самотестування — жорстке правило команди: «Код не дозволяється об’єднувати, доки я не відповім на 100 % питань тесту правильно».

Переконайтесь, що ви добре розумієте свій продукт і маєте достатньо впевненості, щоб захищати його — бо в майбутньому хтось обов’язково прийде з питаннями.

Тим часом агенти також можуть допомогти нам побудувати цінну оборону уваги. Наприклад, я керую величезним відкритим проектом, який отримує величезну кількість Pull Request. Я залучаю агентів для первинної фільтрації: визначаю, які коміти порушують правила спільноти, а які вимагають моєї особистої уваги. Я ніколи не дозволяю агентам приймати рішення про злиття замість мене, але вони допомагають мені точно звузити фільтр уваги, щоб мої людські когнітивні ресурси були зосереджені саме на питанні: «чи вирішують ці зміни справжні проблеми правильним шляхом»?

Нарешті, необхідно визнати психологічне розширення, спричинене вибухом виробництва. Я називаю це «операційним податком» (Orchestration Tax) — це величезна різниця між обсягом промислової продукції, що генерується агентами, і обсягом якісних продуктів, на які ви справді згодні підписатися власним ім’ям. Якщо швидкість накопичення виходів значно перевищує ваші фізичні межі детального перевірки, то запуск нового паралельного сеансу нічого не змінить: ви повинні або стримати автоматизований процес перевірки, або вирішувано зменшити темп.

Коли те, що ти виробляєш, виходить за межі твого контролю та відповідальності, ти вже не проводиш професійного рев’ю — ти просто молишся, щоб нічого не сталось.

У системі співпраці людини та машини людська когнітивна модель не зникла, а просто змістила свій центр: вона перенеслася з довгого проміжного етапу кодування на початковий етап введення завдань та кінцевий етап перевірки результатів. Ви зосереджуєте всю свою когнітивну енергію на розбитті завдань на етапи, наданні контексту на початку та строгому аудиті на завершенні. Саме тому якість підказок (Prompting) має вирішальний вплив на кінцевий результат, і я завжди вважаю видатне проектування підказок ключовою майстерністю високого рівня критичного мислення.

У минулому, якщо ви викинули нечітке, розмите завдання своєму людському колезі, він негайно би вас зупинив, і ви б у відповідному запитанні раптово зрозуміли: «Аж ніяк я цього не продумав». Однак агенти часто не зупиняють вас саме в цей момент. Вони мовчки доповнюють всі пропущені вами деталі, а потім, здавалося б, надзвичайно ефективно повертають вам поверхнево чіткий і повний результат, хоча суть задуму залишається незрозумілою. Я називаю це явище «боргом інтенцій» (Intent Debt): прихованими цілями та обмеженнями, які тихо вбудовані у результат, але які ви самі навіть не розглядали на глибинному рівні. Відмінно від інших видів боргу, ніхто не може сплатити за вас борг інтенцій — суть задуму має 100% походити виключно з вас.

Ті ваші підказки, які ви пишете, є дзеркалом глибини вашого розуміння проблеми; якщо ви не можете виразити її чітко й точно, це часто означає, що вона сама в вашій голові — купа хаосу.

Перш ніж звертатися за допомогою до зовнішніх джерел обчислювальної потужності, спочатку напишіть власним, простим мовою список вимог до завдання. Чітко визначте цільову аудиторію, обмежте абсолютно заборонені умови та вкажіть об’єктивні критерії завершення (Definition of Done). Якщо другий раунд редагування все ще не досягає очікуваних результатів, негайно зупиніть сліпе внесення дрібних коректив і повністю перепишіть ваш запит.

Ви також можете використовувати агентів, щоб підвищити якість своїх запитів. Філософ Енді Кларк зробив глибоке розмежування між «одностороннім делегуванням завдань ІІ» та «глибокою двосторонньою співпрацею з ІІ». У справжньому режимі співпраці ви потрапляєте у позитивний ітеративний цикл: ваші точні запити формує відмінні результати, а ці результати, у свою чергу, змушують вас створювати ще глибші запити, що в кінцевому підсумку значно поглиблює вашу розуміння системи. Якщо ви не впевнені, чи логіка є повною, попросіть агента провести з вами зворотне інтерв’ю, ставлячи питання про ті області, які йому незрозумілі. Якщо наприкінці розмови ваша власна логічна структура отримує піднесення — це справжній показник успіху.

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

Тим часом ви повинні сформувати власний стандарт смаку та якості. Я багато разів експериментував з ІЧ у різних творчих і інженерних галузях, і більшість отриманих результатів ніколи не публікувалися, бо не відповідали моїм особистим стандартам. У сьогоднішній епоху всі вихідні дані моделей можна виглядати надзвичайно витончено, з впевненістю, тому «гладкість поверхні» більше не є ефективним сигналом якості.

Штучний інтелект, можливо, значно прискорив лінію виробництва контенту, але я ніколи не дозволю йому публікуватися, якщо якийсь результат змушує мене відчувати сором, що підписую його своїм ім’ям.

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

Якщо ти, як і багато ентузіастів навколо мене, маєш впевнену булішну віру у майбутнє ШІ, ти, ймовірно, ще до прочитання перших розділів подумав: «Через рік-два здатність моделей виправляти помилки та надавати глибокі інсайти повністю перевершить мої, то навіщо мені зусилля витрачати на підтримку цих навичок критичного аналізу?»

У багатьох чисто технічних індикаторах ваше передбачення, ймовірно, абсолютно правильне, і я сам постійно закликаю передавати все більше автоматизованих перевірок агентам. Але чому ця здатність залишається надзвичайно важливою майбутньому? Причина лише одна: в кінцевому підсумку, реальні, живі люди повинні нести повну відповідальність за реальні результати, що виходять на продуктивне середовище. Незалежно від того, скільки обчислювальних потужностей використовується за кулисами, на судову трибуну чи перед наслідками завжди виходить лише справжня людина.

Визначення ступеня довіри, який слід надати агенту в конкретній задачі, — це саме по собі якісне рішення, що вимагає високого рівня мудрості. Щоб постійно підтримувати точну здатність до оцінки, ви повинні безперервно особисто перевіряти роботу, оскільки дивні моделі помилок моделі постійно змінюються. Дослідження Anthropic, спрямоване на відстеження своїх найкращих інженерів і дослідників, докладно вказало на смертельну пастку цього «парадоксу нагляду»: високорозвинені інженерні та архітектурні навички, необхідні для нагляду та керування Claude, саме є тими ключовими навичками, які людина найшвидше втрачає через надмірну залежність від ШІ.

Ці остаточні питання — це те, що я вважаю найважливішим, і ніяка, навіть найпотужніша мова, ніколи не зможе відповісти за вас: чому саме ви створюєте цей продукт? Яку соціальну та бізнес-цінність він має? На кого саме він матиме глибокий вплив? Яку ціну та компроміси ви готові заплатити, щоб досягти його? Всі ці питання повинні бути відповідені вами особисто. Агенти можуть чудово допомогти у розумінні цих питань, і я радий цьому, але остаточний вирок завжди залишається у вашому розпорядженні.

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

Вам зовсім не потрібно сліпо дотримуватися всіх доктрин — просто виберіть ті способи, що добре вписуються у ваш робочий процес, і впроваджуйте їх природно:

• Щотижнева офлайн-цілеспрямована практика: щотижня виділяйте фіксований час, повністю відмовляючись від допомоги агентів, і самостійно напишіть ключовий фрагмент коду або виконайте вручну одну з основних задач, якщо ви втратите навичку — це призведе до серйозних наслідків (я називаю це вправою когнітивної калібровки, і це зовсім не моральний тиск).

• Щомісячний огляд навичок: щомісяця складайте список, у якому відзначте, які справи ви перестали робити власноруч через залежність від ШІ, і серйозно проаналізуйте: які з цих навичок ви справді можете спокійно прийняти як постійно забуті? Питання, яке я поставив у своєму старому блозі кілька років тому, сьогодні залишається актуальним: якщо колись ШІ раптово повністю зникне, наскільки сильно ви опинитеся в стані паралічу та розпачу?

• Якщо зустрінете незрозуміле — глибоко досліджуйте самостійно: якщо зустрічаєтеся з концепцією, що виходить за межі вашого поточного розуміння, обов’язково вивчіть її системно. Коли під час написання статті я зустрічаю незнайомий термін, я, звичайно, можу просто знайти готове пояснення з Вікіпедії й додати його до тексту, але я віддаю перевагу виділити трохи часу на глибоке мікро-дослідження, щоб зрозуміти його причини та наслідки, доки не побачу його місце в загальній картині знань.

• Плануйте перевірку машин як офіційну роботу: справжнє серйозне перевірка результатів машини — це надзвичайно витратна інтенсивна розумова праця. Приховування того, що ця робота проста, — саме та причина, через яку багато команд зрештою повністю відмовляються від перевірки і закладають основу для величезних проблем. Перевірка — це не безкоштовний обід; включіть її чесно до свого щоденного розкладу, щоб мати реальну можливість її реалізувати.

• Навички, які ви перестаєте практикувати, швидко втрачаються: будь-яка когнітивна м’язова тканина, яку ви довго не використовуєте, швидко атрофується, і цей процес часто набагато швидший, ніж ви уявляєте. Обов’язково постійно практикуйте власноруч ті ключові навички, які ви не збираєтеся віддавати без боротьби.

• Зберігайте чітку мету: агент повністю може перевірити вас у зворотному порядку, інтерв’ювати вас і продемонструвати базові аргументи, але лише за умови, що ви активно розробили та налаштували цей механізм співпраці. Тож негайно створіть його.

• Чесно оцініть свою справжню позицію у спектрі: якщо ви навіть не можете пояснити хід міркувань відповіді іншій особі без підказок від агента, признайте: ви впали у когнітивну капітуляцію.

• Завжди ставте запитання з передбачуваними припущеннями: перед тим як задати питання штучному інтелекту, незалежно від того, чи воно добре чи погане, спочатку сформуйте свою гіпотезу в голові.

• Зелений галочок означає лише те, що один тест пройдено: завжди запитуйте: що саме він перевіряє? Що він тихо пропустив?

• Спочатку перегляньте об’єктивні аргументи, а потім читайте суб’єктивні висновки: перед тим як переглядати його захопливі підсумки, уважно розберіть, які саме команди він виконав і які базові дані використав.

• Читайте з урахуванням чутливості до прийняття рішень: з’ясуйте, які дрібні рішення агент прийняв за вас у цьому виводі.

• Детально працюйте над своїми вхідними підказками: глибина та структура вашого формулювання підказок безпосередньо відображають ваше справжнє розуміння суті питання.

• Встановіть абсолютну межу якості доставки і дотримуйтесь її до кінця: якщо ви самі не соромитесь підписати цей продукт, то категорично не дозволяйте його випуск.

Залишайтеся постійно в центрі дошки, постійно практикуючи власноруч ті ключові навички, що мають вирішальне значення. Проста мікрозвичка, яку ви можете відразу спробувати у повсякденному житті: перед тим як задати запитання агенту, запишіть на наклейці те, як ви передбачаєте розвиток подій; після отримання результату від агента відразу запишіть одну з його невиявлених слабких сторін. Подивіться, чи зможе ця мала протиставна звичка повністю змінити глибину вашого мислення при оцінці результатів ШІ. Думайте незалежно, ставте більш глибокі та якісні запитання та несіть повну відповідальність за кінцевий результат.

Діаграма: Збереження незалежного мислення та замкненого циклу відповідальності в робочих процесах AI-агентів