Як AI стирає межі між ролями в IT. Досвід продакта-вайбкодера

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

Усім привіт! Мене звати Нарек Карапетян, я R&D Product Manager в одному з бізнесів групи продуктових IT-компаній Universe Group — Guru Apps. Ми створюємо застосунки, які є лідерами в двох основних напрямках: утиліти та AI. Нашими продуктами користуються 100+ млн людей зі 186 країн світу.

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

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

Я хочу показати на реальних кейсах, як AI вже сьогодні розмиває класичні межі між PM, дизайнером та інженером та поділитись поглядом практика на те, куди це все рухається в перспективі 2-3 років і як адаптуватись прямо зараз, незалежно від вашої ролі.

Про мій власний досвід

Я — R&D Product Manager у B2C-компанії. У мене немає інженерного бекграунду. Я не знаю як працює event loop в Python і не дебажу сегфолти на дозвіллі. Але Git, Docker, бази даних, CI/CD та інші високорівневі концепції я розумію. Не як розробник, але достатньо, щоб з AI зібрати працюючий продукт.

Пів року тому у нашої маркетинг-команди з’явилася потреба в інструменті для аналітики і моніторингу конкурентів. Класичний шлях вирішення цієї задачі: специфікація → грумінг → спринт → розробка. Але замість цього я спроєктував архітектуру, логіку обробки даних, інтеграції і зібрав першу версію, включаючи деплой. Зробив це самостійно через Cursor із Sonnet 3.7(так, це було дуже болісно) в ролі мого персонального розробника. У результаті — маркетинг почав користуватись цим інструментом того ж тижня. Потім до проєкту підключився розробник для оптимізації і масштабування. Але перша робоча версія, яка довела цінність, була зроблена руками продакта-вайбкодера.

Ось що ще пішло в реліз з моїх рук після першої версії:

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

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

Автоматичні алерти. Моніторинг метрик з алертами в Slack. Backend-логіка, планувальники, інтеграція з даними.

Пайплайн пошуку і кластеризації апок. Повноцінний інструмент з інтеграцією third-party інструментів, обробкою даних, візуалізацією. Перший реліз повністю мій — від архітектури до деплою.

Зараз я обмежую себе internal tools і автоматизаціями. Для user-facing продукту для мільйонів юзерів — інженер незамінний, а ревʼю обов’язкове. Це чесна межа сьогоднішнього дня. Але от що важливо: це межа саме сьогоднішнього дня і вона рухається.

Як саме змінюються ролі

Є очевидне питання: якщо AI знижує поріг входу для розробки — як саме це має впливати на бізнес і класичний розподіл ролей? На мою думку — кожна роль починає заходити на територію сусідньої:

• PM отримує можливість не тільки формулювати задачі, а й реалізовувати їх. Контекст про користувачів, бізнес-логіку, пріоритети — все це вже в голові, і тепер не потрібно транслювати це через три рівні комунікації.
• Інженери рухаються в зворотному напрямку. В моїй команді розробники все більше мислять продуктово: не просто «як реалізувати задачу», а «яку проблему ми вирішуємо і чи правильно ми до неї підходимо». Самостійно пропонують рішення, челенджать вимоги.
• Дизайнери все частіше виходять за межі макетів, збираючи прототипи через v0 або Lovable, тестують взаємодії на реальних сценаріях і приносять розробнику майже готовий фронтенд.

Кожна роль стає ширшою. І десь посередині формується нова зона, де ці ролі перетинаються.

А тепер — що буде через 2-3 роки?

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

Якщо подумати, що буде коли моделі стануть надійнішими, агенти зможуть тримати контекст всього проєкту, а тести, безпека і code review будуть автоматизовані на рівні, якому можна довіряти — межа «internal tools — можна, user-facing — ні» буде зсуватись. Не зникне повністю, адже завжди будуть задачі, де потрібна глибока інженерна експертиза. Але периметр того, що одна людина з правильним контекстом і AI може побудувати самостійно — буде рости з кожним кварталом.

Я думаю, через 2-3 роки ми побачимо такі зміни:

Команди стануть менші і швидші. Там де зараз потрібно 5+ людей і три тижні — буде 1-2 людини і три дні. Не тому що AI замінить людей, а тому що кожна людина зможе покривати ширший спектр функцій.

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

«Builder» стане реальним тайтлом. Буквально за день до початку написання статті подивився Lenny’s Podcast з Борисом Черним — він Head of Claude Code в Anthropic, і до речі, українець з Одеси. Я зловив себе на думці, що він описує рівно те, що бачу у себе в команді — тільки в масштабі Anthropic. У них вже зараз кодять усі: PM, дизайнер, фінансист, data scientist. Приблизно 50% перетин між традиційними ролями. Найсильніші люди — дженералісти на стику дисциплін. Борис прогнозує, що тайтл «software engineer» поступово зміниться на «builder».

Конкурентна перевага зміститься від execution до judgment. Коли побудувати стане дешево — головним питанням стане не «як», а «що і навіщо».

Що це означає прямо зараз?

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

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

Технічна частина — другорядна, але необхідна. Не треба ставати розробником. Треба розуміти базу: як працюють API, дані, інтеграції, де можуть бути обмеження. Без цього AI-assisted робота швидко перетворюється на той самий ненависний всіма розробниками vibecoding — коли результат начебто є, але контролю над ним немає.

Найкращий спосіб все це освоїти — почати робити. Для кожної ролі точка входу буде своя:

• Інженер — почати самостійно валідувати продуктові гіпотези, а не тільки реалізовувати чужі. Подивитись на задачу не «як це розробити», а «чи правильно ми взагалі її формулюємо».
• Дизайнер — зібрати працюючий прототип через v0 або Lovable, а не тільки макет в Figma. Принести команді щось, що можна клікати.
• PM — взяти задачу з беклогу і довести її до деплою самостійно. UI-фікс. Slack-бот. Простий дашборд.
• Маркетолог — побудувати собі інструмент для рутинної задачі, замість чекати на розробку. Парсер, моніторинг, автоматизацію звітів.

Не через два роки. Зараз.