Ви отримали відповідь. А хто організував роботу?

Як перетворити ШІ зі співрозмовника на робоче середовище — для договору, бізнес-плану й не тільки

Сергій Авдейчик · DOBROVOLA · 12 вересня 2026 року

Уявіть: на столі лежить бізнес-план нової пекарні. Двадцять охайних сторінок, прогноз виторгу, маркетингова стратегія, переконливий висновок: другу точку варто відкривати. Текст підготував ШІ. Керівник ставить одне запитання: «Звідки це взялося?»

Звідки взялася кількість покупців? Чому оренда саме така? Чи враховано списання випічки? Хто перевірив, що грошей вистачить до виходу на стабільні продажі?

Та сама сцена в юридичній роботі. Договір має професійний вигляд, але незрозуміло, які умови погодили сторони, звідки з’явився строк оплати й на яку редакцію закону спирався автор.

Проблема тут не в красі тексту. Просто готовий документ ще не означає, що необхідну роботу виконано.

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

Метод, що виріс зі студентської практики

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

У цьому підході мені близький досвід Андрія Карпаті з MenuGen — застосунком, який створює зображення страв за фотографією ресторанного меню. У своєму розборі він описав, наскільки швидко з’явився перший інтерфейс і скільки додаткової роботи потребували інтеграції та доведення застосунку до використання. Між вражаючим початком і готовим продуктом виявився цілком інженерний шлях. [1]

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

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

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

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

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

Почати з розмови, а не з ідеального запиту

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

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

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

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

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

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

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

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

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

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

GitHub, Linear і агент: три зрозумілі ролі

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

GitHub — місце для файлів та історії їхніх змін. Репозиторій можна уявити як проєктну папку, у якій видно, що змінилося й хто це зробив. Там зберігають не лише код: GitHub підтримує файли, спільну роботу й історію версій. [2]

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

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

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

Linear — диспетчерська роботи. Тут видно, що потрібно зробити, до якої віхи належить завдання, що вже перевірено й що заважає рухатися далі. Віхи в Linear дають змогу об’єднувати завдання за етапами проєкту й відстежувати їх виконання. [3]

ШІ-агент — виконавець у підготовленому середовищі. У такій ролі можна використовувати, наприклад, Codex або Claude Code. Codex уміє працювати з файлами, вносити зміни й запускати доступні інструменти. На основі цих можливостей можна організувати не лише програмування, а й обробку даних чи підготовку документів. Це спосіб застосування агентного середовища, а не обіцянка готового галузевого рішення. [4]

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

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

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

Кейс перший: договір, який можна перевірити

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

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

Спочатку — блюпринт процесу

Мету можна сформулювати так: підготувати проєкт договору, який відображає погоджені умови угоди, показує спірні питання й може бути переданий юристові на перевірку.

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

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

Потім — завдання на джерела й перевірки

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

Наприклад, для польського права відправною точкою може бути державний портал ELI. Він розрізняє опубліковані тексти, зведені тексти й версії, підготовлені для інформаційних цілей; уже тому недостатньо завантажити перший знайдений файл і назвати його «законом». [6]

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

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

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

Віхи — через результат, а не зайнятість

Для цього процесу достатньо трьох зрозумілих віх: «Факти й нормативні підстави перевірено», «Проєкт договору й перелік спірних умов підготовлено», «Юрист перевірив проєкт, рішення сторін зафіксовано».

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

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

На фінальній перевірці зручно рухатися від кожного важливого пункту назад: це вимога норми, умова з листування чи пропозиція, яку ще належить обговорити? Хто підтвердив ціну? Де описано приймання обладнання? Чи залишилися суперечності між договором і додатком?

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

Кейс другий: бізнес-план, який може сказати «не відкривати»

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

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

Блюпринт починається з рішення власника

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

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

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

Джерела важливіші за впевнений прогноз

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

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

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

Одне число змінює весь висновок

Візьмімо умовну модель. Середній виторг на один чек — 25 злотих без ПДВ. Точка працює 30 днів на місяць. Змінні витрати становлять 45% виторгу; умовні постійні грошові витрати, зокрема оплата праці й оренда, — 45 000 злотих на місяць.

За 100 чеків на день місячний виторг становитиме:

100 × 25 × 30 = 75 000 злотих.

Після змінних витрат залишиться 55% виторгу, тобто 41 250 злотих. Після постійних витрат вийде мінус 3 750 злотих.

За 140 чеків на день виторг зросте до 105 000 злотих, а результат тієї самої спрощеної моделі становитиме плюс 12 750 злотих. Різницю створило одне припущення — кількість покупок на день.

Поріг покриття цих витрат визначається так:

45 000 ÷ (25 × 0,55 × 30) ≈ 109,1 чека на день.

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

Тепер повертається запитання з початку статті: звідки взялося припущення про 140 чеків? Його підтверджують спостереження, тест продажів чи лише надія власника?

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

Маркетинг теж має узгоджуватися з розрахунком

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

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

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

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

Планувати наступну віху з огляду на реальність

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

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

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

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

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

Агенту для цього дають актуальні матеріали обох репозиторіїв і стан завдань у Linear. Його просять показати, що він справді вивчив, а не виходити з припущення, ніби підключена папка автоматично стала прочитаною.

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

Розвивати потрібно два контури

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

В агентному середовищі є власні інструкції. Для Codex використовують файли AGENTS.md, для Claude Code — CLAUDE.md. У них задають контекст проєкту й правила роботи. Це звичайні текстові документи, а не матеріал, доступний лише програмістові. [8, 9]

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

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

Повторювані процедури можна оформлювати у скіли: наприклад, як складати реєстр джерел або перевіряти фінансову таблицю. В агентних інструментах скіл поєднує інструкції та допоміжні матеріали для певного завдання. [10]

Але текстові правила не замінюють технічних прав доступу. Запис «не надсилайте документи» — не те саме, що обмеження можливості надсилання. Доступи, підтвердження значущих дій і ліміти витрат потрібно налаштовувати окремо. Документація Claude Code прямо розрізняє контекстні інструкції та примусово застосовувані налаштування. [9]

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

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

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

«Готово» — це не статус у планувальнику

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

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

Наприкінці кожної віхи я пропоную два запитання.

Чи можу я простими словами пояснити поточну віху та її завдання людині поза проєктом?

Якщо завтра агент стане недоступним, чи зможу я зрозуміти, що зроблено й чому саме так?

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

Почати з одного процесу, а не з «ШІ-трансформації»

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

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

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

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

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

Іноді найкращий результат — не робити

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

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

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

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

Про автора

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

Сайт: dobrovola.dev · LinkedIn · Facebook

Який процес у Вашій роботі вже проситься в таке середовище — і на якому етапі Вам найважче перевірити результат? Буду радий обговорити конкретні приклади.

Джерела й матеріали

Послідовність роботи у статті — авторська методика. Зовнішні джерела пояснюють можливості інструментів і окремі обмеження. Обидва кейси навчальні; розрахунки виконано за явно вказаними умовними даними. Довідкові сторінки перевірено 12 вересня 2026 року.

[1] Андрій Карпаті. Vibe coding MenuGen. Авторський розбір створення застосунку, 27 квітня 2025 року. Відкрити матеріал.

[2] GitHub Docs. About repositories. Файли, спільна робота й історія змін. Офіційна документація.

[3] Linear Docs. Project milestones. Віхи проєкту й пов’язані завдання. Офіційна документація.

[4] OpenAI. Codex CLI. Робота з файлами, командами й повторюваними процедурами. Офіційна документація.

[5] OpenAI. Model Context Protocol. Підключення інструментів і зовнішнього контексту. Офіційна документація.

[6] ELI, Польща. European Legislation Identifier. Офіційні законодавчі джерела й позначення версій текстів. Державний портал.

[7] OpenAI. Why language models hallucinate. Причини впевнених помилкових відповідей і визнання невизначеності, 5 вересня 2025 року. Дослідницький матеріал.

[8] OpenAI. Custom instructions with AGENTS.md. Контекст та інструкції проєкту для Codex. Офіційна документація.

[9] Anthropic. How Claude remembers your project. CLAUDE.md; відмінність між інструкціями й технічно забезпеченими обмеженнями. Офіційна документація.

[10] OpenAI. Skills. Повторювані інструкції та допоміжні файли для агента. Офіційна документація.