Практичний досвід взаємодії із ШІ через призму управлінського досвіду
Мене звати Антон Куц. Я Principal Software Engineer в intive і CTO в стартапі Banister Staff. У своїй роботі я постійно знаходжуся на перетині кількох світів: технологій, продукту, комунікації з людьми, менеджменту і прийняття рішень в умовах неповної інформації.
Я активно використовую різні інструменти ШІ в роботі і повсякденному житті. Коли я тільки почав працювати з ChatGPT, Claude та іншими
Я добре пам’ятаю момент, коли вперше отримав wow-ефект від спілкування з ChatGPT: він згенерував мені працюючий код гри п’ятнашки (15 puzzle) буквально за кілька хвилин. Мало того, він одразу передбачив перевірку початкового розміщення на можливість розв’язання. Мені знадобилося кілька годин на написання такої гри з правильною перевіркою.
З цікавого, дізнавався про його ставлення до моралі: «Чим відрізняється категоричний імператив Іммануїла Канта від золотого правила моралі?» та ламав через логіку вибору випадкових чисел. З часом я зрозумів, що це зовсім інший інструмент і бажано знайти правильний підхід до організації роботи з ним.
Я сформулював для себе підхід, який передбачає взаємодію з моделлю як із співробітником. Не асистентом, а саме підлеглим, який допомагає мені з великою кількістю різноманітних завдань. Співробітник, який дуже швидкий, багато знає, працездатний, але при цьому може бути неуважним, робить припущення, іноді здається, що має практичний досвід.
Якщо взяти аналогію з IT, то це middle-спеціаліст. Він може багато, іноді робить роботу якісно, іноді не дуже. Результати його роботи напряму залежать від того, наскільки ви якісно і повно дали йому задачу, ввели в контекст, надали приклад чи форму очікуваного результату, перевірили і дали зворотний зв’язок. Враховуючи це, саме досвід управління людьми допомагає швидко навчитися взаємодіяти зі штучним інтелектом.
Давайте розглянемо мої правила, які я визначив на основі свого досвіду. Кожне правило надаю з прикладом взаємодії з LLM. Загальна ціль — зробити MVP інтернет-магазину для продажу кавового обладнання. Я не буду наводити відповіді, бо вони достатньо об’ємні. У разі, якщо цікаві саме відповіді, використайте відповідний промпт і ознайомтеся з результатом.
1. Починай з плану і переліку послідовних кроків
Не починай роботу з завдання «зроби мені MVP...», запитай про загальний план і визнач послідовні кроки. Як і в управлінні, майже будь-яка задача потребує декомпозиції. Для того щоб починати роботу, треба визначити, з чого почати і які кроки нам потрібно пройти, що для цього треба зробити і який результат ми чи клієнти очікуємо побачити в результаті.
Якщо ми беремо за приклад магазин для продажу кавового обладнання, то це можуть бути кроки від визначення аудиторії і каталогу товарів до отримання статистики продажів.
Тому перший запит повинен бути на кшталт:
«Я хочу створити MVP інтернет-магазину для продажу кавового обладнання. Дай перелік основних напрямків, які треба опрацювати до початку роботи.»
Відповідь складається з переліку основних напрямків з описом кожного пункту. Далі можна запросити таблицю зі строками, виконавцями і бюджетами. В результаті матимемо детальний покроковий план.
2. Формулюй запит через результат, а не через дію
Частою проблемою в менеджменті є постановка задач через дію. Наприклад, «проаналізуй конкурентів», «напиши договір», «зроби тести»...
Наче зрозуміло поставлені задачі, але вони викладені дуже загально, і, відповідно, результат може не збігатися з очікуванням менеджера. Коли над задачею працює ШІ, цей простір невизначеності заповнюється самим ШІ і найчастіше не так, як ви собі задумували. Набагато краще описати той результат, який ви хочете отримати: вказати форму, критерії, обмеження і призначення відповіді. Також можна дати приклад відповіді, якій вас задовольняє.
Як ШІ, так і працівник набагато краще працюють, коли розуміють, що саме має бути результатом їх роботи.
Приклад поганого запиту:
«Проаналізуй конкурентів інтернет-магазину для продажу кавового обладнання».
Приклад гарного запиту:
«Ми створюємо MVP інтернет-магазину кавового обладнання для маленьких кав’ярень, для використання в офісах і домашнього вжитку». Проаналізуй 6 конкурентів на ринку України. Дай результат у вигляді таблиці: номер, конкурент, аудиторія, сильні сторони, слабкі сторони, що можна використати у нашому продукті. Після таблиці дай узагальнення у вигляді трьох практичних висновків саме для нашого MVP."
В результаті отримуємо дуже зважену таблицю аналізу конкурентів та три поради. Загальний зміст відповіді: «Перевага — не великий каталог кавового обладнання, а обладнання під конкретний сценарій. Для MVP важливо поєднати e-commerce і консультацію».
3. Формулюй контекст для якісного результату
Коли в команду приходить новий співробітник, йому не кажуть в перший день: «Зроби новий React-компонент». Хоча він робив це кожного дня на 10 попередніх проєктах. Його спочатку «вводять в курс справ». Від ознайомлення з внутрішніми політиками до запиту на конкретний функціонал. Як показують дослідження, працівник працює краще, коли розуміє свій вклад у «загальний результат компанії».
Для AI контекст також критично важливий. Бо відсутність інформації заповнюється здогадками, а це прямий шлях до галюцинацій.
Приклад запиту без контексту:
«Запропонуй структуру сторінки товару для інтернет-магазину. Повинні бути фото, назва, ціна, опис, кнопка „купити“, характеристики товару.»
Приклад запиту з контекстом:
«Ми робимо інтернет-магазин кавового обладнання. Основна аудиторія — власники невеликих кав’ярень, офісні працівники і люди, які хочуть готувати якісну каву вдома. Багато покупців не дуже добре розбираються в обладнанні, тому сторінка товару має не тільки продавати, а й допомагати прийняти рішення. Запропонуй структуру сторінки товару, не перевантажену технічними характеристиками, містить простіі візуальніі пояснення, для кого підходить така кавомашина; основні акценти: назва, кнопка „Купити“, коротке порівняння з іншими кавомашинами цієї ж категорії. В нас також будуть акції і знижки, передбач для них відповідне місце.»
Відповіді якісно різні.
4. Прямо проси ставити зустрічні питання та повідомляти про відсутні дані
Навіть при гарно описаній задачі і достатньому контексті можуть залишатися «прогалини». І тут стане у пригоді гарний інструмент — уточнення. У компаніях з зрілою корпоративною культурою співробітники ставлять зустрічні питання, уточнюють, якщо щось не зрозуміло, і просять надати матеріали, необхідні для виконання поставленої задачі.
З AI ситуація трохи складніша. Він часто намагається відповісти на поставлене питання чи виконати затребувану роботу без аналізу самого запиту і визначення необхідної інформації. Навіть якщо запит має суперечності, логічні помилки чи відсутні всі дані для якісного результату.
Що ж робити? Треба прямо у запиті просити модель ставити зустрічні питання до початку виконання запиту.
Приклад такого запиту:
«Ми плануємо checkout для MVP інтернет-магазину кавового обладнання. Перед тим як пропонувати рішення, постав мені уточнювальні питання, які критично впливають на архітектуру і UX. Не давай фінальну відповідь, поки не будеш впевнена, що тобі достатньо інформації.»
Я отримав 37 питань в 12 категоріях з пріоритезацією цих питань.
5. Працюй ітераціями
В реальній роботі зрідка буває, що перша версія — одразу фінальна. Дизайн погоджується клієнтом, код проходить code review, тексти редагуються, продуктові рішення переглядаються після фідбеку. Навіть професіонали у своїй ніші не роблять свою роботу з першого разу.
Тому перший результат роботи ШІ майже завжди чернетка. Відповідно, в наступному запиті треба вказувати на ті аспекти, які треба доповнити чи переробити. Якщо це текст, можна попрацювати зі стилем; якщо код — можна запросити зробити компоненти для перевірки та повторного використання тощо.
Робота з ШІ — це серія робочих уточнень.
Первинний запит:
«Напиши текст для головної сторінки інтернет-магазину кавового обладнання. Аудиторія: власники маленьких кав’ярень, працівники офісів, люди, які п’ють каву вдома. Стиль: професійний, але не занадто офіційний.»
Уточнювальний запит:
«Не треба вказувати на „проблему“, треба вказувати на емоційний результат після купівлі у нас, а саме: ви насолоджуєтеся смачною кавою не гірше за кав’ярню третьої хвилі, але не „за всі гроші світу“ і не треба кудись виходити, стояти в черзі. Відсутнє хвилювання, що купили якусь не ту кавомашину, бо ми підберемо найкращий варіант саме для вас. Ви точно знаєте, що не переплатили, бо ціни в нас нижчі за ринкові, і ми готові повернути різницю, якщо ви знайдете дешевше навіть після покупки. Гарний післясмак після спілкування з нашими професіоналами і купівлі техніки саме у нас.»
Коли ми працюємо з людьми, фідбек — це частина управління. Ми кажемо, що добре, що погано, що треба змінити. Коли ми вказуємо на проблемні моменти в результатах роботи ШІ, вона теж на цьому вчиться.
6. Формуй власний стиль роботи з ШІ
Бачили пости «20 найкращих промптів для ChatGPT», чи блогер каже: «Зберігай мої промпти — вони допоможуть тобі в роботі». Так, деякі з них можуть бути корисними, але краще напрацювати власний стиль роботи, враховуючи свою роботу і задачі та, власне і уявлення про результат. Бо мені, наприклад, легше працювати зі структурованою інформацією і таблицями, React-компонентами і порівняннями.
Приклад запиту в моєму стилі:
«Ми створюємо MVP інтернет-магазину кавового обладнання для маленьких кав’ярень, для використання в офісах і домашнього вжитку в Україні. Проаналізуй 6 сайтів конкурентів на ринку України. Дай результат у вигляді таблиці: номер, назва конкурента, сайт, ключові слова, оціни зазначені слова зі сторони SEO-оптимізації. Проаналізуй слова в Google Trends та Google Keyword Planner для нашої ніші та отримані слова конкурентів і зроби фінальний набір слів для нас з коротким поясненням українською мовою.»
Також тут можна згадати, що деякі користувачі просять ШІ допомогти їм зробити гарний промпт чи користуються спеціальним чатом для створення промптів. Я користувався таким підходом для навчання і розуміння різниці між моїм і згенерованим промптом.
З часом ви починаєте більше розуміти, як саме ця система реагує саме на ваші запити, де її сильні і слабкі сторони та, відповідно, як краще формувати запит під конкретну задачу. Це дуже схоже на роботу з людьми: з часом ви розумієте, кому треба давати чіткі інструкції і формат результату, а кому дати лише ціль, яку треба досягнути.
7. Збирай команду, визначай ролі
Якщо це проєкт більший за landing page, без команди спеціалістів не обійтися. У кожного буде своя роль і відповідні задачі в проєкті. При роботі з ШІ можуть бути декілька підходів: 1. Вказувати декілька ролей в одному запиті. 2. Робити кілька запитів, кожен від нової ролі. 3. Використовувати різні інструменти AI у якості різних ролей.
Приклад промту з різними ролями:
«Ми створюємо MVP інтернет-магазину кавового обладнання для маленьких кав’ярень, для використання в офісах і для домашнього вжитку в Україні. Напиши продажний текст для головної сторінки. Дій як спічрайтер, який знає, як продавати техніку відповідній аудиторії. Після цього проаналізуй текст в ролі досвідченого SEO-спеціаліста, зроби акценти на відповідних ключових словах, зазнач прямо в тексті, які теги для них використовувати. Після цього прочитай текст як звичайний користувач сайту і дай свої коментарі і уточнення, чи все зрозуміло і чи все відповідає основній цілі — купити кавове обладнання. І остання роль оптимізатора — видалити все зайве, всю „воду“. Результат — фінальний текст з коментарями від кожної ролі.»
У відповіді достатньо збалансований текст.
8. Змінюй підходи до роботи
Раніше я писав код вручну. Потім перевіряв і тестував і знову писав. Зараз сам порядок роботи змінився. Ти повинен подумати, що саме тобі необхідно, і описати це для ШІ. Код (основа) генерується без твоєї участі. Залишається перевірити і протестувати те, що вже створено. Тести, до речі, теж генеруються за твоїм запитом. І так рухаєшся крок за кроком.
Відповідно, ти починаєш думати не про реалізацію: як назвати змінні, де написати перевірку і так далі, а про результати: мені необхідна форма з перевіркою в необхідному дизайні. Користування ШІ буквально змінює наше мислення і підхід до роботи.
9. Перевіряй результат
Це, мабуть, основне правило, яке я хочу донести: результат роботи ШІ не можна автоматично вважати правильним. Навіть якщо аргумент виглядає обґрунтованим, документ логічним, а код — працюючим, все одно зробіть перевірку.
На даний час «інтелект» ще може помилятись, іноді навіть в банальних речах. Наприклад: використати неіснуючу бібліотеку для вашого застосунку. Я думаю, ви вже маєте досвід галюцинацій при роботі з ШІ.
Мій банальний приклад:
Запит: «Сьогодні вихідний день в Польщі і Німеччині?»
Повна відповідь ChatGPT:
«Сьогодні (6 квітня 2026) не є офіційним державним вихідним ні в Польщі, ні в Німеччині.
Детально:
- У Польщі сьогодні — звичайний робочий день.
- У Німеччині — також робочий день (у всіх федеральних землях).
Можлива плутанина
Ймовірно, ти маєш на увазі:
- Великодні свята (Easter) — це офіційні вихідні:
- Великодній понеділок (Easter Monday) — вихідний і в Польщі, і в Німеччині
- Але у 2026 році:
- Великдень припадає на 5 квітня (неділя)
- Вихідний (Easter Monday) був 6 квітня 2026 ❗
👉 Тобто уточнення:
- Так, сьогодні якраз Easter Monday — і це офіційний вихідний в обох країнах.
Висновок
✔️ Так, сьогодні (6 квітня 2026) — вихідний день і в Польщі, і в Німеччині (Великодній понеділок).
Якщо потрібно — можу дати список усіх свят на 2026 рік або пояснити, як працюють магазини/служби в ці дні.»
Як ми бачимо, навіть з простими питаннями можуть бути труднощі. Можна, звісно, зробити промпт на перевірку, але це не знімає відповідальності з автора за результат.
Приклад промпта на перевірку:
«Перевір запропонований checkout для інтернет-магазину кавового обладнання. Визнач ризики: юридичні, UX, технічні, бізнесові. Дай відповідь у форматі таблиці: номер, ризик, опиши ризик, чи він критичний (унеможливлює роботу), рішення, як виправити чи знизити ризик.»
Це гарно кореспондується з правилом з менеджменту, коли кожен документ, перед передачею клієнту, повинен бути перевірений кимось, крім самого автора, а код повинен пройти review і тестування.
З прикладів, коли про «галюцинації» ШІ було весело слухати. Стах Возняк розказував, як агенти в Cargofy в спілкуванні з логістами інших компаній постійно замінювали ПДВ (податок) на зовсім різні слова — іноді зовсім відірвані від контексту, і це було дуже важко виявити і виправити.
Гарною практикою при спілкуванні ваших агентів з клієнтами є постійний зворотний зв’язок. Ми можемо швидко виявляти «хиби» і опрацьовувати їх. Деякі компанії, до прикладу, IT SmartFlex, окрема система спілкується з клієнтами, а окрема записує розмови, аналізує їх та дає рекомендації щодо вдосконалення першої.
10. Експериментуй
Коли наче зрозумів, як працює відповідний інструмент ШІ, отримав кілька гарних результатів — закріплюєш підхід і працюєш по ньому. Але тут є але: АІ еволюціонує дуже швидко. Те, що було важко уявити ще рік тому, зараз є частиною повсякденної роботи. Наприклад, AI-агенти та автономні workflow. Моделі змінюються, інструменти удосконалюються, підходи працюють по-іншому — тому завжди залишай можливість для експерименту.
Приклад запиту з експериментальним підходом:
«Запропонуй 3 різні підходи до головної сторінки інтернет-магазину кавового обладнання:
1. Раціональний B2B-підхід;
2. Експертний підхід з основним акцентом на економічній вигоді;
3. Емоційний підхід для тих, хто ходить в кафе і любить каву: основний меседж — кава як у крутій кав’ярні третьої хвилі прямо у тебе вдома. Для кожного підходу дай: короткий опис, ключові слова, аудиторію.»
Я, наприклад, перебрав багато інструментів для написання коду, поки не зупинився на Codex — OpenAI’s coding agent в VSC. Зараз в планах гляну в сторону Jules від Google.
Якщо повертатися до класичного менеджменту. Є цікава практика, коли проводять експеримент у вигляді зміни ролі працівника на один день. Менеджер з головного офісу стає продавцем в магазині, а розробник спілкується з постачальниками.
Експериментуйте — іноді це може дати неочікуваний позитивний результат.
Підсумок
Для мене робота з ШІ — це вже не про «написати промпт». Це про організацію роботи. Якщо коротко, то якість результату залежить від кількох речей:
- Спочатку плануємо, потім виконуємо;
- Формулюємо задачу через результат;
- Надаємо необхідний контекст;
- Просимо ставити зустрічні питання та запитувати інформацією, якої не вистачає;
- Вказуємо на те що треба покращити і працюємо ітераціями;
- Встановлюємо ролі, опрацьовуємо результат з різних сторін;
- Перевіряємо фінальний результат.
Та загалом напрацьовуємо власний стиль взаємодії зі ШІ, застосовуємо різні підходи та не забуваємо експериментувати. Це все частина навичок — prompt engineering. І чим далі, тим більше вона переходить у розряд необхідних, незалежно від професії чи ролі. AI дедалі більше пронизує наше життя. GitHub вже «просідає» від навали запитів АІ-агентів. Можливо, ШІ стане для вас точкою професійного росту чи навіть ви опануєте нову професію з AI в назві.
7 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівА міряв хтось вигоду використанняLLM-ок у порівнянні з людьми на позиціях мідлів?
Бо якби мені хтось формулював задачі так же старанно і структуровано, як описані тут промпти, то і я б працював в 100500 разів продуктивніше за ті ж самі гроші ))) (хіба що не цілодобово, як ШІ-агенти)
Перевагою мідлів і сінйорів в тому числі є здатність працювати з не зовсім структурованими задачами, базуючись на досвіді. Тоді роль так званого ШІ зводиться більше до рутинних задач рівня джуніорів.
А без ШІ організовувати роботу не треба було? Воно якось само? ;)
Дуже цікаве питання) Треба пошукати. Але в статті я не кажу, що треба замінити «мідлів» наLLM-ки. Я пропоную взаємодіяти з ШІ не як з «пошуком», а як зі підлеглим рівня «мідл», якщо мова йде про IT (написання коду), і привожу техніки, якими я для цього користуюся.
Так, гарний менеджмент завжди надихає працювати краще. Але, на жаль, не на всіх проєктах він такий.
Я їх не порівнюю)
Звісно треба. Просто результат взаємодії з ШІ, прямо залежить від організації роботи з ним, так само як і з людьми)
Цим стаття вигідно відрізняється від багатьох інших у розділі, де розмазано продають «успішний успіх». Дякую!
Мій коментар скоріше в контексті чи був досвід успішного використання ШІ-помічників з нечіткими задачами. Бо з чіткими ніби непогано справляються ))
Можливо якось можна «навчити» агента робити з нечітких задач структуровані. Бо багато хто пише, що використовує агентів, які пишуть завдання агентам і т.п., але наскільки це доцільно поза рекламою ШІ — не зрозуміло
Завдання типу «сильні сторони, слабкі сторони, що можна використати у нашому продукті» і отут якщо його пітсоттисяч разів не попинати, можна завалити всю задачу. Він не мідл спеціалістом, він є ІНСТРУМЕНТОМ який пише код рівня мідл при умові однієї чітко і правильно поставленої задачі при умові що такі задачі є у нього в базі. Мідлспеціаліст напише будь яку прогу, ШІ це не напише, це не самостійна одиниця, це інструмент. Це як сказав копати копає, не сказав копати не копає, і йому як низькокваліфікованому робітнику ще треба сказати як копати і де копати ще й чим копати, і «ні оту золоту лопатку з музея брати не можна, ти пам’ятаєшь що я сказала не можна золотою лопаткою, а ну повтори, так так не можна брати золоту лопатку, так звичайну, нафіга ти її розпилив? Тому шо не золота? А те шо копати треба а не пилити ти пам’ятаєшь? Та ні я ж кажу не золотою лопатою. Давай ще раз ти не трогаєшь золоту лопатку взагалі. береш звичайну і копаєшь, головне завдання копати. Стій нафіга ти пилишь золоту лопату? Томушо головне завдання копати звичайною лопатою і ти подумав що золота мені не потрібна?». Все замініть мені індійця з тієї сторони . А мідл у цій ситуації подумає а може те нафік копати давайте спростмо у шефа і візмемо екскаватор.
Я частково погоджуюсь з тезою про «інструмент», але тут, як на мене, є важливий нюанс.
У статті я використав аналогію з middle-спеціалістом не тому, що ШІ буквально є «мідлом», а тому що така модель взаємодії практично корисна для більшості людей. Вона добре пояснює головну проблему: якість результату дуже сильно залежить від постановки задачі, контексту, перевірки та ітерацій.
І тут важливий момент: люди на позиціях middle теж регулярно помиляються. Іноді через недостатній контекст, іноді через неправильне розуміння задачі, іноді через поспіх або власні припущення. Саме тому існують review, QA, уточнення вимог, менеджмент і командна робота.
З ШІ зараз дуже схожа ситуація. Це не «самостійний працівник» у класичному розумінні, а дуже потужний інструмент нового типу:
він може робити припущення;
пропонувати альтернативи;
іноді знаходити неочевидні рішення;
а іноді — почати «пиляти золоту лопату» 😄
Тому в статті окремо є акцент на:
декомпозиції;
контексті;
уточнюючих питаннях;
перевірці результату;
ітераціях.
Бо без цього і люди, і ШІ можуть завалити задачу.
Я б сказав так: сучасний ШІ — це вже не просто «молоток», але ще й не автономний спеціаліст. Це дуже сильний co-pilot, ефективність якого напряму залежить від того, хто і як організовує з ним роботу 🙂
Досліди : OpenAI, Antropic та низки інших незалежних команд показують, що instructured/naive промпт та structured/well formed промпт дають в середньому різницю в 500%.
Процесс сворення ПЗ тобто автоматизації, це поступовий процесс перетворення вимог із повністю не неформальної форми в повнвстю формальну — программний код (інформації із високим рівнем ентропії у інформацію із нульовим рівнем ентропії). Задачі із відкритим контуром не вирішуються. З іншого боку усьогьго 17% людей без спеціальної підготовки здатні до логічного мислення. 55% мають фрагментарні навички. 30% людей на рівні конкретного мислення.
Так, погоджуюсь.