01 / 08
Onix Systems · works.onix-systems.com

Legacy оживає
без повної
команди

Як один PM + AI-агент розморозили проєкт з 28 завислими тікетами, підняли staging і випустили production release за 11 днів.

Ініціатор Serhii Kholin
Заморожено з січня 2025
Реліз 25 червня 2026
Підхід Agentic delivery
scroll
02 / 08
Результат

До і після

28
тікетів «On Staging»
зависли в Jira
7–19
місяців без
prod-релізу
11
днів від старту
до prod
20+
артефактів у docs/
створено агентом
До (червень 2026)
Після (25 червня 2026)
Немає єдиного workspace
GitLab works-workspace + bootstrap
Документація фрагментована по Slack і Google Docs
20+ артефактів у git-репо docs/
Jira ↔ Git розсинхрон
Playbooks + jira-conventions.md
Staging 404, FE-репо заархівовано
Staging + prod працюють
Prod без релізу з листопада 2024
FE 35e98a7a + BE 586d1c6b на prod
28 тікетів зависли без прогресу
Ключові тікети → Done, реліз закрито
03 / 08
Хронологія

11 днів від папки до prod

Три хвилі: знання → система → реліз. Жодна не може перейти до наступної без попередньої.

14 черв
Фаза 0 — знання
Порожня папка → карта реальності
Клон FE+BE, читання CI, збір PRD з коду, перевірка curl prod. Виявлено: FE staging = dev, BE staging = staging — різні назви!
14–15 черв
Фаза 1 — зовнішній світ
MCP підключено: Jira, Sentry, GA4, Figma
Замість ручного CSV-export — прямий API. 26 unresolved Sentry-issues пріоритизовано, GA4 виявив підозру на ботів. Автоматично створено WORKS-1161, 1162, 1168.
16 черв
Фаза 2 — система
works-workspace: 15 агентів + playbooks
Окремий git-репо тільки для docs, rules, playbooks. Жодного generic-агента з інтернету — лише під стек Works. AGENTS.md із guardrails.
16–17 черв
Фаза 3 — staging gate
FE розархівовано, Docker fix, QA test plan
Виправлено Docker build (yarn.lock не потрапляв в image). QA отримала test plan на 38 тікетів. Два звіти регресії: public + admin.
17–24 черв
Фаза 4 — блокери
Sonar fix, WORKS-1147 footer/Terms
SonarQube заблокував MR (дублікація > 3%). Агент проаналізував pipeline, створив fix-гілку, змерджив у staging після green. WORKS-1147: окремий env PUBLIC_SITE_URL_4_UPWORK.
25 черв
Реліз
MR staging→master · Prod smoke Pass · Jira Done
WORKS-1159, 1155, 1147, 1170 у релізі. Release notes у Slack. Prod smoke за чеклістом — не «здається працює».
04 / 08
Фази

PM-уроки з кожної фази

🗺️
Фаза 0 — карта реальності
Перший тиждень — не код, а розуміння що є. PRD з коду (не з застарілого Google Doc), curl на prod, реальні гілки CI. Без цього будь-який реліз — лотерея.
тиждень 1
🔌
Фаза 1 — MCP = автоматичний дашборд
MCP — не «фічі для девів». Для PM це автоматичні дашборди, які агент перетворює на рішення і тікети. Status report за годину замість ручного Jira export.
тиждень 1
📋
Фаза 2 — playbooks = SOP для людей і агента
«Зроби реліз» → чекліст з 50 кроків, який не губиться при зміні PM. Наступний PM або агент не починає з нуля. Файли в git — корпоративна пам'ять.
тиждень 1
🚦
Фаза 3 — staging як обов'язковий gate
Агент готує регрес і test cases, але sign-off QA — людина. Staging — не опція, не «перевіримо на prod». Це контрольна точка перед кожним релізом.
тиждень 2
⚡
Фаза 4 — реліз = серія малих інцидентів
Не «big bang». Кожен блокер (Sonar, Docker, env-змінна) — окремий цикл. Агент з playbooks і MCP скорочує цикл з днів до годин на кожен блокер.
фінал
🧠
Принцип фіксації
Кожна сесія з агентом → артефакт у docs/. Не лише відповідь у чаті. Чат зникає — файли в git залишаються. Це і є корпоративна пам'ять.
завжди
05 / 08
MCP — системи правди

Без MCP агент «галюцинує» статуси

Замість ручного CSV-export — прямий доступ до live-даних. Агент отримав реальну картину проєкту за перший день.

MCP / Джерело Що дав PM
Atlassian (Jira) JQL-запити, статуси, автоматичне створення тікетів WORKS-1161, 1162, 1168
Sentry (self-hosted) 26 unresolved issues → пріоритизований звіт за 30 хвилин
Analytics (GA4) YoY трафік, підозра на ботів, gap у page_view — без ручного export
Figma Дизайн-референси для QA та порівняння staging vs дизайн
Browser MCP Staging + prod без ручних скріншотів — очима користувача
Context7 Актуальна документація Nuxt/NestJS прямо в контексті агента
Git log + GitLab CI Реальні тікети у комітах, дати останнього prod-merge, env-змінні build-arg
06 / 08
Розподіл ролей

PM задає намір. Агент виконує роботу.

Чіткий розподіл — ключ до того, щоб не «втратити управління» і не «загрузнути в операціях» одночасно.

🤖 Агент (автономно)
  • Збір фактів з git, Jira, Sentry, GA4
  • Написання та оновлення docs і playbooks
  • Feature-гілки, commits, MR descriptions
  • Smoke/regression у browser
  • Jira transitions за playbook
  • Діагностика CI/Sonar pipeline
  • Release notes draft
  • Пріоритизований список помилок
👤 Людина (PM / sponsor)
  • Бізнес-рішення: що релізити з backlog
  • OAuth-токени, доступи до GitLab/Jira
  • Merge у master, approve MR
  • QA sign-off на staging
  • Закриття release, комунікація зі stakeholders
  • Зміни CI/Docker без DevOps review
  • Публікація в Slack, ескалації
  • Визначення меж («не чіпай CI»)
Формула PM задає намір і межі («розморозь staging → prod, тікети X–Y, не чіпай CI») — агент виконує операційну роботу.
07 / 08
Повтори на своєму проєкті

10 кроків для PM

Скопіюй структуру, адаптуй під свої гілки — і запускай на одному тікеті перед масштабуванням.

01
Мета одним реченням
«Автоматизувати доставку змін на legacy-портфоліо з мінімальною командою». Не «покращити процеси».
02
Операційна папка
Клон усіх репо в одну директорію. Реальні гілки з CI — не з пам'яті. PRD з коду, а не з застарілого doc.
03
MCP до систем правди
Jira/Linear + моніторинг (Sentry) + аналітика + Browser. Без MCP агент галюцинує статуси.
04
Status report «як є»
Перший deliverable для stakeholder — не код. Скільки тікетів зависло, на скільки місяців git попереду prod, топ-5 ризиків.
05
3 playbooks
New feature · Release · Hotfix. Скопіюй з works-workspace і адаптуй. SOP одночасно для людей і для агента.
06
AGENTS.md із guardrails
Заборони важливіші за «будь ласка». «Не пушити в master, не комітити секрети» — агент без меж зламає legacy швидше, ніж оживить.
07
Один тікет end-to-end
Гілка → MR staging → QA → MR master → smoke → Jira Done. Після успіху — масштабуй на batch.
08
Фіксуй у docs/ і CHANGELOG
Чат зникає. Файли в git — корпоративна пам'ять. Кожна сесія → артефакт.
09
Реліз + комунікація
Prod smoke за чеклістом (не «здається працює»). Release notes у Slack. Jira Done — лише для тікетів з кодом у цьому релізі.
10
Ітеруй
Tier 2: SEO-агенти, security, автоматизація Jira transitions після CI. Works Tier 0+1 дав prod-реліз — це стартова точка.
08 / 08
Що тут незвично для PM

Зміна парадигми

01
PM — архітектор автоматизації
Не лише власник backlog. Ти проєктуєш систему доставки: агенти, guardrails, playbooks — це теж твій продукт.
02
Документація — продукт
У Works docs/ — такий же deliverable, як код. 20+ артефактів у git, а не в головах і Slack-тредах.
03
Legacy — не привід чекати
28 завислих тікетів + рік без prod — організаційний борг, який структура + агент розкладають на кроки. Не потрібна повна команда.
04
MCP = аналітик у режимі реального часу
Status report за годину без ручного Jira export — реальність. Агент не чекає «ідеального ТЗ» — він читає живі системи.
05
Реліз — кульмінація процесу
25 червня 2026 — не «магія AI». Це наслідок playbooks, staging QA і дисципліни гілок, побудованих за тиждень до того.
06
Архітектура важлива для PM
Одна строчка env (PUBLIC_SITE_URL_4_UPWORK) вирішила тижні плутанини з footer на Upwork. PM, який розуміє архітектуру, не чекає dev-пояснень.
Наступні кроки

Tier 2 вже в роботі

SEO-агенти, фільтр Sentry 4xx, синхронізація Jira ↔ git після кожного MR — наступна хвиля автоматизації.

WORKS-1161 · SEO-агент WORKS-1162 · SEO-агент WORKS-1168 · Sentry 4xx filter handover.md · onboarding 2год