AI-агенти для PMs: чому будувати робоче середовище важливіше за найновіші моделі

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

Якщо ви вже користуєтеся ChatGPT, Claude чи Gemini, у вас, найімовірніше, був такий момент: модель дала нормальну відповідь, але більшість роботи все одно залишилася на вас: перенесли відповідь у Jira/Notion, додали контекст, про який модель не знала або забула, перевірили факти, почали новий чат, бо старий уже «поплив». Потім повторили все знову для наступної задачі.

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

Ця стаття для продактів, технічних менеджерів, аналітиків і розробників, які вже використовують AI для текстів, аналізу, PRD, досліджень або прототипів, але відчувають стелю.

Мене звати Олег, я Technical Product Manager та co-lead Google Developers Group Kyiv, у минулому — розробник. Системно працювати з AI я почав після виходу ChatGPT 3.5, а у 2025 році перебудовував навколо AI більшість робочих процесів і частину особистих.

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

Наразі у мене одне середовище, в якому в один і той ж день можуть працювати Codex, Cursor, інколи Сlaude Code чи Github Copilot CLI.

День коли в мене «зламався» чат

Довгий час я використовував AI як чат-бота. Приносив шматки контексту, пояснював задачу, отримував відповідь, переносив її в Jira/Notion/Obsidian, код або повідомлення колегам. Потім починав нову задачу і знову ніс контекст руками.

Рис. 1. Базовий флоу чат-бота

На коротких задачах це працює: переписати абзац, придумати заголовки, розкласти ідею в булети, підготувати чорнову структуру PRD.

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

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

Рис. 2. Приклад надання контексту чат боту

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

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

Я почав пробувати робити свої workflow: n8n, будувати кастомні GPTs на кожний чих, пробувати наповнювати контекстом Projects. В цілому будувати ті речі, які дозволять довгостроково тримати контекст. Проте, крім контексту, потрібно було ще щось, що я весь час хотів отримати якимись циклами: CoT-промптами... агентність.

Реально перший Aha момент я отримав в кінці 2024-го, коли спробував Cursor, де можна було тегнути файл, папку — це було вау, в цілому завдяки ньому я зробив свій досить великий пет-проєкт — Kaggle competition UNLP 2025, де я вперше тренував свій BERT-like трансформер — планував задачу, брейнштормив, ітерувався, в цілому весело було.

Рис. 3. Можливість тегати файли у папці у Cursor IDE

Зараз таким функціоналом не здивуєш нікого, хто користується Claude Code чи Codex, але 2 роки тому це було вау. Далі я почав все глибше копатись в агентах, ну а далі, вийшов Claude Code на початку 2025 і понеслося.

Чим агент відрізняється від чату

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

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

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

Рис. 4. Як агент працює над задачею

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

Після декількох місяців спроб, різних підходів, навіть фреймворків (bmad, gsd привіт), я зрозумів, що основне вузьке місце — це онбординг. По відчуттях, 80-90% всіх проблем у роботі були десь такі: агент не мав достатньо контексту, не бачив прикладу, як я хочу бачити результат, або не знав, як перевірити себе, бо я йому не пояснив.

Тоді й виникла в голові аналогія: агент схожий на нового тіммейта.

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

З агентом так само.

Рис. 5. Онбординг = покласти у відповідні артефакти агента знання

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

Агент працює з матеріалами в середовищі й повертає проміжний результат, сам здатний перевірити і побудувати наступні ітерації, або дозапитати. Це головна різниця між агентом і чат-ботом, яка піднімає користь від використання на порядок (як мінімум для мене), хоча чечно кажучи в ChatGPT у мене GPT 5.5, а агентни працють буває і на GPT 5.4-mini.

Чому локальний диск раптом став важливим

Найбільша зміна для мене з агентом сталася у середовищі зберігання інформації. Раніше це переважно було збереження одразу в Notion/Google Docs після діалогу в чаті, а точкові речі залишалися лише в чатах.

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

Це не футуристично. Так, можна обвішатися MCP і CLI-конекторами до Jira, Notion, Google Drive чи GitHub і змусити це працювати. Але кожний новий конектор підвищує складність системи. Локальна папка в цьому сенсі банально стабільніша. Агенту не треба чекати, поки я руками занесу все в чат, або перевірю чи всі MCP підключені які треба. Він може почати з карти проєкту, знайти файли через локальний пошук, а не дьоргати декілька інтерфейсів, прочитати приклади й повернутися з результатом, де видно, на що він спирався. Я теж можу відкрити папку й зрозуміти, що там відбувається, щось докинути, видалити, думаю ідею ви зрозуміли.

Звідси для мене природно виріс і вибір формату. Базовим став Markdown. Не тому, що я хочу пересадити всіх із docx (чесно, мрію ще з університету), але причина тут простіша. Фінальні документи можуть бути де завгодно, фінальні результати агент може зберігати там де зручно всій команді. Але як проміжний робочий шар Markdown дуже зручний: це чистий текст, який нормально читає людина, агент, Git, Obsidian, та будь яка IDE.

Рис. 6. Робота з локальними файлами, як проміжними прихованими шарами системи

У якийсь момент я почав думати про мою папочку cowork (я чесно назвав її так раніше за вихід Claude Cowork) як про маленьку Product OS. Мені близька ідея Джона Катлера, що спосіб роботи продукту все одно є системою, навіть якщо ніхто її не описав. Для агента це особливо видно. Якщо в системі не зрозуміло, де лежить довгоживучий контекст, які документи для нас опорні, які приклади вважаються хорошими і як перевіряється результат, його починає ковбасити.

Мій сетап зараз (майже Product OS)

Зараз мій робочий сетап доволі приземлений. У мене є Obsidian vault на Markdown-файлах з PARA-подібною структурою: окремо активні проєкти, окремо довгограючі зони, окремо ресурси, ресьорчі, самарі. Усередині цього простору я тримаю не тільки нотатки, а й навігацію між ними, приклади хороших артефактів, чернетки й інструкції для агентів.

Рис. 7. PARA метод організації простору

Поверх цього лежить кілька простих шарів.

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

Другий: Git + Github, як основний сторедж всього, можливо бо я в минулому розробник, але реально не знайшов нічого кращого, щоб тримати все разом. Він корисний не тільки для коду, а й для PRD, чернеток, PoC і всього, що «воно колись ж було тут».

Третій: локальний пошук. Для цього я використовую QMD від Tobi Lutke (CEO Shopify) + лінкування файлів Obsidian. Для мене це спосіб швидко знайти у vault правильні зачіпки: стару нотатку, приклад, джерело, формулювання, яке я вже колись записав.

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

З чого я б радив почати, якщо ви ще тільки думаєте по агентів

Я б не починав з «AI workspace для всього життя». Краще взяти одну повторювану задачу, яку вам набридло щоразу пояснювати з нуля: аналіз інтерв’ю, PRD review, release notes, конкурентний огляд, follow-up після дзвінка.

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

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

Пробуйте, експериментуйте і кайфуйте, але не вигорайте, адже АІ забирає велику кількість нудної роботи, але тепер у нас більш інтенсивна робота, адже рутина забрана, а весь thinking, judgment і прийняття рішень залишилися у нас, і це справді може втомлювати, тож бережіть себе!