Практичне використання інструментів ШІ

Складність: [QUICK]

Час виконання: 35-45 хв

Передумови: базова впевненість у роботі з чат-орієнтованими ШІ-інструментами, перевірці джерел та прикладах командного рядка

Що ви зможете робити

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

Чому цей модуль важливий

Гіпотетичний сценарій: ваша команда готує нотатку про оновлення до Kubernetes 1.35, інженер підтримки просить допомогти пояснити невдале розгортання, а менеджер хоче, щоб той самий ШІ-асистент переписав лист клієнту, знайшов актуальні рекомендації щодо релізу, перевірив репозиторій і застосував виправлення. Кожен запит звучить як «використай ШІ», але кожен має інший профіль ризику, вимогу до контексту та шлях перевірки. Якщо ви заштовхаєте їх усі в одне вікно чату, інструмент може звучати однаково впевнено, будучи добре пристосованим до одного завдання й погано — до іншого.

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

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

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

Починайте із завдання, а не з інструмента

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

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

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

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

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

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

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

# Приклад: визначення завдання «Аналіз першопричини» з кількох кроків
# 1. Спостереження: витягніть журнали з пода, що падає (Інструмент: kubectl/термінал)
# 2. Синтез: співвіднесіть журнали з нещодавніми комітами Git (Інструмент: IDE-агент з доступом до git)
# 3. Перевірка: перевірте, чи має підозрювана бібліотека відомі CVE (Інструмент: ШІ з доступом до вебу)
# 4. Виконання: застосуйте патч і перевірте збірку (Інструмент: IDE-агент + локальний компілятор)

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

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

Перш ніж обрати інтерфейс, напишіть контракт завдання в одне речення. Корисний контракт зазначає, які докази потрібні інструменту, який результат ви очікуєте, чого інструменту робити не дозволено та як ви перевірятимете результат. «Поясни цю помилку, використовуючи лише вставлений журнал, і дай мені три ймовірні причини» — кращий контракт, ніж «виправ це». «Знайди актуальну документацію постачальника й поверни посилання з датами» — кращий контракт, ніж «що змінилося нещодавно?». Контракт змушує завдання стати спостережуваним.

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

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

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

Практична модель інструментів

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

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

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

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

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

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

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

# Роль: Старший інженер надійності сайту (SRE)
# Обмеження: Кожна запропонована зміна конфігурації МУСИТЬ супроводжуватися
# командою перевірки (наприклад, `kubectl diff -f ...` або `terraform plan`).
# Запобіжник: Якщо інструмент не може перевірити стан середовища за допомогою
# неруйнівної команди читання, він мусить зупинитися й запросити людське рецензування.

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

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

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

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

Шари стають зрозумілішими, коли ви відділяєте спроможність від повноважень. Спроможність запитує, чи може інструмент зрозуміти завдання, отримати докази, прочитати файли чи виконати аналіз. Повноваження запитують, чи дозволено інструменту використовувати цю спроможність у вашому середовищі. Модель може бути спроможна редагувати маніфести Kubernetes, але це не означає, що вона повинна мати облікові дані кластера, дозвіл на push чи дозвіл схвалювати власні зміни.

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

Для хмарно-нативної роботи межа між аналізом і дією має бути видимою у шляху команди. Читання маніфестів, опис ресурсів та запуск локальної перевірки — це кроки спостереження. Застосування маніфестів, видалення ресурсів, ротація секретів та зміна трафіку — це кроки дії. Допомога ШІ може бути цінною з обох боків, але контрольна точка між ними має бути явною. Інструмент має знати, коли він готує докази, а коли просить схвалення на зміну стану.

Питання для вибору інструмента

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

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

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

Третє питання — про ризик. Ризик — це не лише доступ до продакшену. Хибне узагальнення, надіслане керівництву, необґрунтована інтерпретація вимог відповідності, вигадана цитата чи патч, що потайки послаблює авторизацію, — усе це може завдати шкоди. Правильна реакція на ризик не завжди «ніколи не використовуй ШІ»; часто це «зменш дозволи, вимагай джерела, додай рецензування, запусти тести та зупинись перед незворотним кроком». Інструмент має відповідати наслідкам того, що він помиляється.

Четверте питання — про права на дії. Система, що може читати файли, відрізняється від системи, що може редагувати файли, а система, що може редагувати файли, відрізняється від тієї, що може робити push коду чи змінювати інфраструктуру. Дозволи слід надавати малими кроками. Дайте доступ на читання перед доступом на запис, здатність до пробного запуску перед живим виконанням і вузьке володіння завданням перед широкою автономією. Що більше інструмент може робити, то чіткішою має бути межа.

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

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

# Приклад тріажу: вибір інструмента для аудиту RBAC у Kubernetes
task: "Проаудитувати ClusterRoleBindings на предмет можливого підвищення привілеїв"
requirements:
  reasoning_density: "Високий" (відстеження дозволів ServiceAccount до виконання Pod)
  knowledge_freshness: "Середній" (примітиви RBAC стабільні)
  execution_layer: "Високий" (потребує розбору вихідних даних JSON/YAML для перевірки логіки)
recommended_strategy: "Використати модель міркувань із пісочницею виконання для аналізу"

Зверніть увагу на фразу «пісочниця виконання», а не «доступ до продакшену». Для аналізу пісочниця може розбирати JSON, порівнювати YAML, обчислювати статистику чи запускати тести на безпечній фікстурі. Це відрізняється від того, щоб дозволити інструменту змінювати кластер. У багатьох робочих процесах найкращий дизайн — дати ШІ достатньо здатності до виконання, щоб перевірити свої міркування, водночас утримуючи повноваження на виконання незворотних операцій.

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

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

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

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

Обсяг версій — ще одне питання для вибору, яке початківці часто пропускають. Відповідь для Kubernetes 1.35, відповідь для хмарного провайдера щодо щойно випущеної функції та відповідь для мовної бібліотеки для конкретної основної версії — усі вони потребують різного обґрунтування. Якщо інструмент не може вказати версію, яку він використовує, зробіть цю невизначеність видимою у результаті. Обізнаність про версію — це не педантизм; це різниця між багаторазовими рекомендаціями та тонкою майбутньою помилкою.

Ризик, перевірка та коли зупинятися

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

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

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

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

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

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

Для практичної роботи поєднуйте кожен шар ШІ з артефактом перевірки. Чат має лишати стисле узагальнення припущень. Пошук має лишати URL-адреси джерел і нотатки про свіжість чи версію. Інструменти для кодування мають лишати diff, запущені команди та результати тестів. Агентні робочі процеси мають лишати журнал виконання, що розрізняє спостереження, міркування, запропоновану дію, схвалення та результат. Ці артефакти роблять роботу придатною до перевірки після того, як розмова рушила далі.

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

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

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

Патерни та антипатерни

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

Патерн	Коли використовувати	Чому це працює
Контракт завдання перед промптом	Використовуйте, коли запит складніший за швидке пояснення.	Він називає докази, результат, межі та перевірки до того, як інструмент почне оптимізувати заради гладкості.
Обґрунтуй перед узагальненням	Використовуйте, коли відповідь залежить від нещодавніх фактів, рекомендацій постачальника чи політик.	Він запобігає тому, щоб необґрунтовані твердження ставали відшліфованими внутрішніми рекомендаціями.
Лише читання перед доступом на запис	Використовуйте, коли інструмент може перевіряти системи, файли чи API.	Він дає інструменту достатньо контексту для міркувань, тримаючи дію під людським контролем, доки план не перевірено.
Пробний запуск перед живим виконанням	Використовуйте, коли інфраструктура, дані чи поведінка, звернена до клієнта, можуть змінитися.	Він перетворює впевненість моделі на спостережувані докази перед незворотним кроком.

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

Антипатерн	Що йде не так	Краща альтернатива
Промптинг «спершу інструмент»	Користувач підганяє завдання під відкритий інтерфейс і проґавлює вимоги до доказів.	Спершу назвіть тип завдання, глибину контексту, ризик і шлях перевірки.
Агент для контрольного списку	Робочий процес додає дозволи та затримку, не зменшуючи реальної роботи.	Тримайте контрольний список під людським виконанням, доки повторення та стабільні перевірки не виправдають автоматизацію.
Пошук як судження	Відповідь має посилання, але слабкі міркування про застосовність.	Використовуйте пошук для обґрунтування, а тоді застосовуйте предметне рецензування, щоб порівняти обсяг, версію та ризик.
Асистент з кодування як власник	Diff може пройти синтаксис, порушуючи задум чи послаблюючи тести.	Ставтеся до асистента як до автора пропозицій патчів і лишайте володіння за інженером.

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

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

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

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

Коли використовувати це, а коли альтернативи

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

Сигнал завдання	Почніть із	Ескалюйте, коли	Зупиніться, коли
Вам потрібне пояснення чи чернетка	Чат-інструмент	Відповідь потребує актуальних джерел, файлів чи виконання.	Ви можете перевірити результат напряму, і зовнішні докази не потрібні.
Вам потрібні актуальні рекомендації	Інструмент з опорою на пошук	Вам потрібні глибші міркування над отриманим матеріалом.	Джерела відсутні, застарілі чи не стосуються вашої версії.
Вам потрібна допомога з кодом	Інструмент для кодування	Завдання охоплює повторювані кроки зі стабільними перевірками.	Тести падають, diff розростається за межі обсягу, чи володіння неясне.
Вам потрібне повторюване виконання	Агентний робочий процес	Процес має чіткі спостереження, дії та контрольні точки.	Інструмент не може перевірити стан чи просить дозволи поза межами завдання.

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

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

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

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

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

Остаточне судження — чи допоміг вам інструмент перейти від невизначеності до обґрунтованої дії. Пояснення зменшує концептуальну невизначеність, пошук зменшує невизначеність джерел, допомога з кодуванням зменшує невизначеність реалізації, а робочі процеси зменшують вартість координації в повторюваних кроках. Коли інструмент не зменшує однієї з цих невизначеностей, він усе ще може бути цікавим, але не виконує корисної інженерної роботи. Практичне використання ШІ-інструментів — це дисципліна помічати цю різницю до того, як завдання стане дорогим.

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

Чи знали ви?

Систему управління ризиками ШІ NIST (AI RMF 1.0) було випущено в січні 2023 року, а її основні функції використовують послідовність Govern, Map, Measure та Manage для структурування роботи з ризиками ШІ.
Рекомендації OpenAI щодо виклику функцій радять робити визначення інструментів чіткими та обмеженими, бо модель може обрати добре лише тоді, коли доступні функції очевидні й обмежені.
Kubernetes уже роками підтримує пробний запуск на боці сервера для запитів до API, тому команди на кшталт kubectl diff природно вписуються в рецензування змін за допомогою ШІ.
Фраза «людина в циклі» — це не єдиний засіб контролю; вона може означати рецензування перед дією, схвалення після плану, моніторинг під час виконання чи аудит після завершення.

Поширені помилки

Помилка	Чому вона трапляється	Як її виправити
Використання чату, коли завдання потребує актуальних джерел	Відповідь звучить гладко, тож відсутній крок пошуку легко проґавити.	Спершу використайте інструмент з опорою на пошук, а тоді попросіть дати, посилання на джерела та нотатки про застосовність.
Надання агенту розпливчастої мети	Користувач хоче швидкості, але не визначив докази, межі чи умови зупинки.	Напишіть контракт завдання з вхідними даними, дозволеними діями, забороненими діями та контрольними точками рецензування.
Ставлення до пропозицій коду як до передачі володіння	Асистент створює патч, тож інженер послаблює дисципліну рецензування.	Запустіть тести, огляньте diff і лишайте відповідальність за людиною-супровідником.
Ескалація кожного завдання до автоматизації	Агентні інструменти здаються просунутішими за прості промпти.	Починайте з найменшого безпечного інструмента й ескалюйте лише тоді, коли конкретне назване обмеження блокує завдання.
Прохання про чутливі до джерел рекомендації без критеріїв якості джерел	Інструмент може зібрати посилання, що застарілі, вторинні чи не відповідають версії.	Вимагайте первинні джерела / джерела постачальника й просіть інструмент вказати припущення щодо версій.
Дозвіл інструментам дії пропускати пробні запуски	Запропонована зміна виглядає розумною, і користувач хоче заощадити час.	Вимагайте неруйнівну перевірку, як-от запуски тестів, попередні перегляди, diff чи перевірки лише для читання перед дією.
Ігнорування конфіденційності під час вибору інструмента	Команда зосереджується на корисності й забуває, чи можна ділитися доказами.	Визначте межі даних перед промптингом і використовуйте схвалені локальні чи корпоративні інструменти, коли потрібен приватний контекст.

Тест

Питання 1: Вашій команді потрібне швидке пояснення заплутаної концепції Kubernetes перед нарадою. Нікому не потрібні джерела, зміни коду чи будь-які дії. Як вам оцінити придатність ШІ-інструмента, порівнюючи тип завдання, глибину контексту, потреби в джерелах, права на дії та ризик?

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

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

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

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

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

Питання 4: Менеджер просить автономного ШІ-агента, щоб переписати один короткий лист, який ви могли б переписати вручну за дві хвилини. Що вам слід діагностувати перед вибором інструмента?

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

Питання 5: Ваша команда безпеки просить ШІ-систему вносити зміни в конфігурацію продакшену напряму, але немає гейта рецензування й немає надійного способу перевірити результат перед розгортанням. Як вам реалізувати план перевірки?

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

Питання 6: Вам треба перевірити, чи має підозрювана проблема у бібліотеці з відкритим кодом відомі вразливості, зібрати посилання та підтвердити найновіші рекомендації перед вибором виправлення. Який інструмент слід використати першим?

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

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

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

Практична вправа

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

Створіть файл із назвою tool-selection-notes.md у вашому робочому каталозі. Команда перевірки:

touch tool-selection-notes.md
test -f tool-selection-notes.md && echo "notes file exists"

Підказка до розв'язання

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

Додайте до файлу п’ять міток завдань: explanation, recent information, code help, repeatable workflow та high-risk/no-verification. Команда перевірки:

grep -nE 'explanation|recent information|code help|repeatable workflow|high-risk/no-verification' tool-selection-notes.md

Підказка до розв'язання

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

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

grep -nE 'chat was enough|human judgment' tool-selection-notes.md

Підказка до розв'язання

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

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

grep -Eo 'https?://[^ )]+' tool-selection-notes.md | wc -l
grep -n 'plain chat would have been risky' tool-selection-notes.md

Підказка до розв'язання

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

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

grep -nE 'useful output|human should still review' tool-selection-notes.md

Підказка до розв'язання

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

Для завдання repeatable workflow опишіть процес із 3–5 кроків, який ви виконуєте більш ніж раз, а тоді вирішіть, чи має він лишитися контрольним списком, чи стати робочим процесом/агентом. Додайте одне речення, що пояснює межу. Команда перевірки:

grep -nE 'checklist|workflow|agent|boundary' tool-selection-notes.md

Підказка до розв'язання

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

Додайте один приклад, де ШІ взагалі не слід використовувати, бо ризик, конфіденційність чи прогалина в перевірці надто високі. Команда перевірки:

grep -nE 'should not be used|confidential|risk|verification gap' tool-selection-notes.md

Підказка до розв'язання

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

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

grep -n 'smallest safe tool that solves the task' tool-selection-notes.md

Підказка до розв'язання

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

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

tool-selection-notes.md існує й містить усі п’ять категорій завдань.
Щонайменше одне завдання зіставлено з чатом, одне — з використанням з опорою на пошук, одне — з допомогою в кодуванні та одне — з рішенням про контрольний список чи робочий процес.
Приклад з актуальною інформацією містить щонайменше два джерела.
Один приклад явно каже, що ШІ не слід використовувати, і пояснює чому.
Фінальне правило відображає підхід «спершу завдання», а не «спершу інструмент».

Джерела

Artificial Intelligence Risk Management Framework (AI RMF 1.0) — Довідкова інформація про оцінювання ризиків ШІ та вирішення, коли потрібні суворіші засоби контролю й людське рецензування.
Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile — Практичні рекомендації щодо ризиків генеративного ШІ, потреб у перевірці та безпечних операційних меж.
NIST AI Risk Management Framework overview
OpenAI function calling guide
OpenAI tools guide
OpenAI prompt engineering guide
Anthropic tool use overview
Anthropic evaluation tool guide
Google Gemini function calling documentation
Google Vertex AI grounding overview
Microsoft responsible AI overview
Kubernetes debugging tasks
kubectl diff reference

Наступний модуль

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