ШІ-агенти: чотири навички, які важливіші за добрий промпт

Type: kb/sources/types/snapshot.md

Author: Кирило Балалін Source: https://mezha.ua/articles/shi-agenti-chotiri-navichki-yaki-vazhlivishi-za-dobriy-prompt-311970/ Date: 2026-06-04T19:03:00+03:00

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

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

Одна крайність це довірливість та оптимізм: наслідки ми можемо спостерігати у вигляді стрічки постів в LinkedIn з "корисними" думками, згенерованими чатботами. Іншу крайність уособлюють неолуддіти, які радіють кожній невдачі ШІ й чекають, коли ця бульбашка лусне. А істина навіть не посередині. Вона лежить у площині англійського слова "mindset" в значенні, яке найкраще передати саме як "спосіб мислення". Бо маючи настільки багатогранний інструмент у своєму розпорядженні, як ШІ, людина має підлаштовувати свій спосіб мислення під нього!

Можливою відповіддю є фреймворк під назвою AI Fluency, який Рік Дакан (Ringling College of Art and Design) і Йозеф Феллер (Cork University Business School) розробили у 2023-2024 роках на основі власних досліджень того, як ШІ змінює творчі й бізнесові процеси. Згодом до ініціативи долучилися Anthropic, щоб зробити з фреймворку безплатний курс. Сам курс і супровідні матеріали доступні на платформі Anthropic Academy за адресою anthropic.skilljar.com/ai-fluency-framework-foundations. Курс англомовний, тож якщо рівень мови дозволяє, його варто пройти повністю - 12 уроків займуть лише декілька годин і це чудова інвестиція часу в себе самого!

Фреймворк визначає AI Fluency, тобто "вільне володіння ШІ", коротко: уміння працювати з ШІ ефективно, продуктивно, етично й безпечно. І перш ніж зануритися, варто сформулювати головне твердження статті. Якість роботи з ШІ залежить від того, наскільки свідомо людина тримає чотири паралельні рівні: що вона передає моделі, як описує, як перевіряє і за що зрештою відповідає.

Чому "промпт-інжиніринг" це навіть не чверть роботи

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

Чотири навички AI Fluency

AI Fluency складається з чотирьох компетенцій. Англійською вони називаються Delegation, Description, Discernment і Diligence, тому в авторській термінології їх ще звуть "чотири Ds".

Переклад слів для розуміння буде корисним, але вигадувати зайві сутності не хочеться, тому далі ці чотири слова вживатимуться в оригінальному англомовному вигляді: - Delegation (делегування): рішення, які саме задачі передавати моделі, а які залишати собі. - Description (опис): вміння описати задачу так, щоб модель могла її виконати без здогадок. - Discernment (розпізнавання): критична оцінка того, що модель видала, і того, як вона себе при цьому поводила. - Diligence (ретельність): відповідальність за фінальний результат, прозорість використання ШІ, етика та підзвітність.

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

Три режими роботи з ШІ

Перш ніж розкривати чотири навички окремо, треба розглянути три режими взаємодії (в оригіналі modalities), які цей фреймворк виділяє.

Automation (автоматизація): людина дає ШІ конкретну задачу, модель виконує. Класичні приклади: "Перефразуй цей абзац формальніше", "Перетвори таблицю в CSV", "Склади короткий summary з цього документу". Ніякого подальшого діалогу, ніякої співпраці, просто виконання за чітко заданою інструкцією.

Augmentation (доповнення): людина і модель працюють як партнери, що думають разом. Людина ставить задачу, модель відповідає, людина бачить, що корисно, а що ні, повертає уточнення, отримує кращу відповідь, повторює... Це режим, у якому проходить більшість змістовної роботи зі знаннями. Якщо повернутися до другої частини цієї серії, то весь ланцюжок з NotebookLM, Claude, GPT Image 2 і GPT-5.5 для інфографіки був чистою augmentation. В принципі, навіть просто довгий діалог з чатботом це найпростіший приклад цього режиму.

Agency (агентність): людина налаштовує ШІ так, щоб він виконував задачі самостійно, у межах заздалегідь узгоджених правил. Це режим експериментів з першої частини (написання Android-застосунку) і концептуальної бази третьої частини. Передбачається, що над моделлю вже не треба "сидіти", її можна сконфігурувати й дати певний простір для роботи.

Чому ці три режими важливі для розмови про чотири навички? Бо різні режими навантажують навички по-різному. Automation навантажує переважно Delegation і Description: правильно вибрати задачу і правильно сформулювати. Augmentation навантажує всі чотири навички одночасно, і саме тому це складніший режим для більшості людей. Agency на додачу ставить найвищі вимоги до Diligence, бо чим автономнішим стає агент, тим важливіше ще до запуску мати ясне розуміння меж, відповідальностей і способів перевірки. Agency також змінює характер Discernment: поки модель видає один лист, перевірка разова, а коли агент веде багатокрокову задачу сам, розпізнавання стає радше постійним процесом моніторингу та аудиту ланцюжка дій, ніж разовим вичитуванням готового результату.

Delegation. Делегування.

Найскладніший з чотирьох навичок, і не випадково йде у фреймворку першим. Делегування складніше за прийняття рішення з питання "що з усього, що я роблю, віддати ШІ?". Скоріш, його варто сформулювати так: "чи я взагалі розумію цю задачу достатньо, щоб обґрунтовано вирішити, кому її віддати?". Зріла навичка делегування у фреймворку розділений на три рівні обізнаності.

Розуміння цілі та задачі. "Що я насправді хочу отримати?" "Який результат я визнаю добрим, а який ні, які компоненти задачі/плану справді важливі, а які додумані?" В принципі, ця навичка навіть без ШІ дуже корисна в житті. Якщо оператор не може описати критерії якості без слова "ну", то ШІ нічого з цим не зробить, бо цілитиме в розмите. На цьому рівні людина розкладає задачу на компоненти: які з них варто робити людині, які можна довірити ШІ повністю, які варто виконувати спільно.

Розуміння можливостей платформи. "Що конкретно цей інструмент робить добре, а що погано?" Це також конкретне питання. Claude і ChatGPT по-різному поводяться з художнім текстом. Cursor, Codex і Claude Code мають різні сильні сторони у роботі з кодом. Один і той самий запит до моделі без інтернет-доступу і до моделі з доступом дасть зовсім різні відповіді. Знання конкретних сильних і слабких сторін це окрема навичка, який накопичується практикою користування, а не читанням маркетингових сторінок.

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

Простий тест на якість делегування з другої частини серії — історія з логотипом. GPT Image 2 малює їх ідеально, тоді як Claude Design видає щось жалюгідне.

Description. Опис.

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

Опис продукту (product description). Що має бути на виході. Запит "допоможи вибрати ноутбук" залишає моделі стільки простору, що результатом буде розмитий загальний огляд. Точніша версія звучить приблизно так: "для бюджету 100 тисяч гривень, з пріоритетом на роботу з відео, питання шуму вентилятора при навантаженні важливе, корпус повинен бути металевий, з прицілом на 4 роки використання, запропонуй три варіанти з обґрунтуванням". Чим конкретніший опис продукту, тим менше модель додумує сама і тим менше доводиться потім переробляти.

Опис процесу (process description). Як саме дійти до результату. Сюди входять інструкції на кшталт "спочатку склади план, потім кожен пункт розкрий окремо", або "перевір кожне число в джерелі, перш ніж використовувати", або лайфхак автора з першої частини: "перш ніж починати, постав мені всі питання, щоб бути впевненим на 95%". Опис процесу задає шлях, яким модель прийде до результату. Точний кінцевий продукт він напряму не визначає. Якщо одного повідомлення мало, то починається діалог. І іноді правильно вести модель до результату кроками замість того, щоб втиснути всю задачу в один запит.

Опис поведінки (performance description). Як модель має поводитися загалом, у будь-якій взаємодії того чи іншого типу. "Якщо не впевнений, не вгадуй, а спитай". "Не давай оцінок без джерела". "Завжди виокремлюй припущення, на яких базується відповідь". Це інструкції стилю роботи, які менше стосуються якоїсь конкретної задачі. У фреймворку цей тип опису спирається на прийом directive prompting, бо задає поведінку моделі наперед. Наскільки цей зріз недооцінюють, видно з даних: за AI Fluency Index, який Anthropic оприлюднила на початку 2026 року, лише приблизно у 30% розмов користувачі взагалі кажуть моделі, як саме хочуть, щоб вона з ними взаємодіяла.

Жоден із цих трьох типів не зводиться до "промпт-інжинірингу" у вузькому сенсі. Промпт-інжиніринг найчастіше це опис продукту і трохи процесу всередині одного повідомлення. Опис процесу зараз частіше передбачає щось на кшталт скілів. Опис поведінки часто винесений у системний промпт, в інструкції проєкту, або в той самий CLAUDE.md/AGENTS.md, про який ми говорили в третій частині. Тобто якісний опис задачі для повторюваної роботи майже ніколи не сидить в одному місці. Він розкиданий між повідомленням, інструкціями різних рівнів, скілами та іншими методами контролювати поведінку LLM. Сприйняти Description лише як поради щодо промптів означає звести опис до одного зрізу з трьох. Для тих, хто хоче підтягнути саме промптинг, у курсі є окремий поглиблений блок із шістьма техніками, але поданий він свідомо як частина Description, а не як уся робота.

Discernment. Розпізнавання.

Третя навичка найризикованіше пропустити, бо результати ШІ зараз мають настільки добрий вигляд, що приймати їх на віру стало окремою спокусою. Очевидно поганий результат можна побачити й відкинути без зусиль. Підступний провал виглядає так: текст рівний, структурований, грамотний, аргументи звучать переконливо, але всередині є тиха помилка. Невірна дата. Спотворений факт. Цитата, яка ніби з джерела, а насправді галюцинація. Тобто текст може бути на 95% правильний, з останніми 5%, які виринуть рівно тоді, коли цього найменше хочеться.

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

Розпізнавання продукту (product discernment). "Чи результат справді задовольняє вимоги завдання?" "Чи він точний фактично?" Для цього потрібно мати хоч якісь пізнання в тій галузі, в якій працювала модель. Скажімо, красивий текст на тему, в якому деякі твердження взяті з джерел п'ятирічної давнини. Без галузевих знань розпізнавання продукту фактично не працює, і це окреме застереження, до якого ми повернемось.

Розпізнавання процесу (process discernment). "Чи модель прийшла до результату правильним шляхом?" "Якщо модель мала перевірити три джерела і використати свіжі дані, чи вона це справді зробила, чи відповіла з пам'яті, а потім подала відповідь так, ніби вона з пошуку?" "Якщо ми вели діалог, чи добре модель його тримала, чи з'їла половину контексту і відповіла на спрощену версію питання?" Складніші процеси тягнуть за собою складніші питання. А з довгими відповідями цей тип розпізнавання критично важливий.

Розпізнавання поведінки (performance discernment). "Як модель поводилася в самій взаємодії?" "Чи відповіла із зайвою впевненістю там, де доречний був сумнів?" "Чи з'їла пів запиту і відповіла лише на найзручнішу частину?" Цей тип розпізнавання найважче виробити, бо він вимагає від користувача певного усвідомлення принципів власної взаємодії з моделлю. Хоча ідейно це є простою діагностикою інструмента, з яким користувач взаємодіє — щось на кшталт "чи ніж, яким я ріжу ковбасу, не затупився?" або "чи мій комп'ютер ще здатний запускати сучасні ігри?".

Попередня стаття охоплювала розгорнутий приклад discernment. Коли GPT Image 2 видав перший варіант інфографіки, то картинка мала непоганий вигляд. Кольори норм, шрифти норм, композиція норм. Але в деталях були суттєві недоліки. Перший варіант пішов у смітник, автор переробив опис задачі, і через декілька ітерацій вийшов вже фінальний продукт. Це і є робота розпізнавання. Але не тільки - а у зв'язці з описом.

Description-Discernment loop

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

У фреймворку AI Fluency цей цикл називається description-discernment loop. Звучить як банальне "ітеративний підхід", але всередині є цікаве спостереження. Кожна ітерація опису робить дві речі одночасно. Очевидна: оператор виправляє формулювання, спираючись на те, що видала модель. Менш очевидна і важливіша: попередній результат розповідає людині щось про її власну задачу, чого вона сама до того (можливо) не знала.

Звичайна робоча ситуація. Якщо прикріпити до Claude чи ChatGPT таблицю з продажами по місяцях і попросити "проаналізуй динаміку і дай висновки", то перша відповідь повернеться у вигляді тверджень на кшталт "найкращий місяць був березень, найгірший травень, середнє зростання за рік 12 відсотків". Прочитавши, оператор може помітити, що потрібні були саме пояснення, чому травень провалився, а не загальний огляд. Модель цього знати не могла, бо в самому запиті мети такого рівня не було. Тож другий запит буде більш прицільний: "зосередься на травневому спаді, перевір, що в самих даних може його пояснити, окремо познач, що з цих даних узагалі вивести не можна, а потребує додаткової інформації". Друга відповідь буде набагато кориснішою. І причина успіху в тому, що перша спроба показала нам самим, що ми до кінця не знали, чого шукаємо.

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

Diligence. Ретельність.

Четверту навичку обговорюють менш за всіх і виробляється він найважче. Правильний переклад слова Diligence тут ширше за "ретельність" у сенсі акуратності. Це сукупність етичних і підзвітних практик навколо роботи з ШІ. Грубо кажучи, відповідь на питання "хто відповідає за цей результат" і "наскільки я готовий поставити власне ім'я під тим, що видала модель". Інакше люди або тримають від ШІ дистанцію через страх ("раптом щось вийде не так, краще не використовувати"), або кидаються використовувати без розбору ("ну якщо помилка не моя, то й нічого страшного"). Обидві крайності забирають здатність ефективно діяти. Свідома відповідальність повертає її, бо людина бере на себе наслідки та поводиться відповідно. Diligence теж розкладається на три рівні.

Відповідальне створення (creation diligence). Етичні норми у процесі. Усвідомлення можливих упереджень моделі. Розуміння впливу на людей, які з результатом стикнуться. Сюди ж входить уважність до того, на яких даних модель навчалася і де можуть з'являтися систематичні викривлення. Це той рівень, на якому доречно зупинитися і подумати, чи завдання, яке делегується ШІ, взагалі етично передавати. Якщо автоматизувати, наприклад, складання відмов кандидатам на роботу, то під технічно нехитрою задачею ховається ціла низка ризиків, які LLM самі не помітять — доведеться людям, як мінімум, дуже жорстко вибудовувати процес...

Відповідальність за результат (deployment diligence). Це найважливіша частина у щоденній роботі. Перевірка фактів, тестування, валідація тверджень перед тим, як виставити результат у світ. Готовність відповідати за наслідки. За всі помилки ШІ відповідає оператор, бо ШІ (поки) не є суб'єктом відповідальності ні юридично, ні логічно. Суб'єкт — людина, яка скористалася інструментом. І тільки погоджуючись на відповідальність, ми отримуємо свободу робити серйозні речі з допомогою ШІ.

Третій рівень, прозорість при поширенні (transparency diligence) фреймворк розглядає серйозно, але на практиці він важить по-різному залежно від домену. В академічній роботі правила жорсткі. А у робочих документах між колегами часто достатньо професійного здорового глузду. Конкретні правила залежать від того, де і кому передається результат, і за це теж відповідають люди.

Як описана концепція Diligence виглядає в реальній практиці, добре показують самі автори фреймворку. У документі-першоджерелі є окремий блок із підсумком: усі тексти, які створювалися за допомогою Claude 3.7, пройшли перевірку і редагування людьми, а остаточну відповідальність за зміст, точність і подачу автори беруть на себе. Це формулювання працює як готова робоча модель: інструмент допускається у процес, відповідальність за результат залишається за людьми, які підписують роботу. Сама фраза "ШІ мені допоміг" не звільняє нікого ні від чого; вона лише чесно описує спосіб роботи.

Можна починати з Diligence замість Delegation

Звичний порядок чотирьох Ds ставить Delegation першим, бо це логічний початок: спочатку вирішити, що делегувати, потім описати, перевірити, опублікувати. Але є інша послідовність для тих, хто тільки починає вибудовувати власну роботу з ШІ: спочатку Diligence.

Логіка така. Поки людина не визначила власні межі, цінності та критерії якості, всі рішення про делегування зависають у повітрі. Відповідь на питання "Чи можу я делегувати ШІ роботу з конфіденційними даними клієнта?" залежить від професійних зобов'язань та умов. "Під чим я готовий поставити власне ім'я, а під чим - ні, навіть якщо результат технічно прийнятний?" - залежить від особистих стандартів та переконань. "Чи можу я довіряти моделі рішення про тон у складній комунікації?" залежить від того, що для конкретної людини значить "професійне" і де вона ставить межу. Усі ці питання відносяться до Diligence. Якщо на них немає відповідей, то й делегування стає випадковим. Люди або відмовляються від ШІ зі страху, або беруть все підряд без розрізнення. В обох випадках страждає якість.

Втім, не кожен має пройти цей шлях. Якщо контекст уже дає ясні межі (корпоративна політика, академічні правила, особисті принципи), можна починати з Delegation. І точні поради давати складно, бо це скоріш сфера суб'єктивних відчуттів.

Чотири навички як одночасні шари

Попередній розділ як раз нагадує, що найчастішою є помилка вивчення AI Fluency, як чек-лист. Спочатку D1, потім D2, потім D3, потім D4, готово. Так воно не працює. У реальній роботі всі чотири навички активні одночасно. Коли оператор пише запит до моделі, то одночасно: думає про делегування (чи правильна це задача для ШІ), описує задачу, заздалегідь готується розпізнавати результат, і тримає в голові власну відповідальність за фінал. Це паралельні шари роботи. Слабкість у будь-якому з них псує результат у решти.

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

Фреймворк корисний саме тим, що дає мову, якою можна навіть з самим собою говорити про власну практику. Незадовільний результат від взаємодії ШІ можна діагностувати, як збій в одному з чотирьох D. Якщо відповідь "не знаю", то AI Fluency уже виконав свою першу функцію: показав, де треба розбиратися детальніше.

Практика

У попередній статті запропоновано 5 кроків для тих, хто хоче вийти за межі звичайного чату з ШІ. Знайти повторювану задачу, зробити проєкт з інструкціями, винести повторювані операції у скіл, використати безпечний зовнішній інструмент, оновлювати інструкції після кожного циклу.

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

Не обов'язково мати готові відповіді на всі ці питання одразу. Достатньо знати, які з них для нас відкриті, і не вдавати, що відповіді є, коли їх немає. Це і є практичний Diligence на старті.

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

Чого фреймворк AI Fluency не дає

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

AI Fluency не є чек-листом, як уже сказано вище. Не варто очікувати, що після вивчення чотирьох D буде гарантований результат. Фреймворк дає мову і структуру для подальших власних роздумів. Той самий "mindset".

AI Fluency не заміняє галузевих знань. Людину, що не розбирається у фінансах, фреймворк ніяк не зробить здатною надійно перевіряти модель у фінансовому аналізі. Навичка Discernment вимагає достатньо знань про предмет, аби помітити помилку. Та й взагалі, ШІ є потужним мультиплікатором спроможностей там, де оператор вже має досвід.

AI Fluency не вказує, який інструмент обрати. Claude чи ChatGPT, Cursor чи Codex, локальна модель чи хмара, безплатний рівень чи Pro - всі ці рішення лежать за межами фреймворку. Фреймворк допомагає працювати з будь-яким інструментом свідомо, але не каже, який саме інструмент брати. Це дуже приємно з урахуванням того, що ініціатива зараз знаходиться під крилом в Anthropic, але всі положення не прив'язані до Claude.

AI Fluency не стає гарантією етичності. Можна формально вивчити всі чотири навички й водночас використовувати ШІ для чогось сумнівного. Адже Diligence у такому випадку передбачає "внутрішню" особисту і професійну відповідальність. Зовнішня регуляція ШІ це окрема розмова, яку фреймворк не претендує вирішити.

Що далі

Курс AI Fluency: Framework and Foundations повністю безплатний, відкритий на Anthropic Academy, і виданий під ліцензією Creative Commons BY-NC-SA 4.0. Це означає, що матеріали можна вільно використовувати, перекладати та адаптувати для некомерційних цілей, зі збереженням авторства і тієї ж ліцензії на похідних роботах (включно з цією статтею).

І з усім тим, не можна ігнорувати промпт-інжиніринг навіть у 2026 році. Бо перелічені вище чотири навички справді важливіші за добрий промпт, але він все ще залишається базою взаємодії з ШІ. Разом з тим, увага користувачів зсувається на інші методи впливати на роботу ШІ-агентів. Контекст-інжиніринг відповідає за те, що знає агент в процесі виконання роботи. А інжиніринг намірів (intent engineering), так би мовити, задає агенту правильні бажання. Ось про це й поговоримо наступного разу.