Ваша команда має Claude Code. Але не має Agentic SDLC — і саме тому нічого не змінилось

Останній рік я чую від фаундерів і директорів практично одну й ту саму фразу: «Ми купили підписки на Claude Code, роздали команді — і що далі?» Хтось із розробників у захваті, хтось розчарований, а на виході жодної системної зміни немає. Швидкість та сама, якість та сама, тільки рахунок за токени виріс.

Я одразу кажу таким клієнтам: це не провал AI. Це провал підходу «чат для всього».

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

За останній рік в Evergreen ми пройшли цей шлях — від хаотичного «давайте спробуємо AI» до керованого процесу, який я називаю Agentic SDLC. Якщо впізнаєте своїх — ця стаття не про вас, вона для вас.

Що таке Agentic SDLC

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

Спершу — про те, чого ми не робимо

Один із моїх клієнтів якось процитував людину з Anthropic чи OpenAI: «Якщо твій CEO хоче замінити людей на AI — у твого CEO немає уяви». Я під цим підписуюсь повністю.

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

Три опори, на яких усе тримається

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

Правила — це джерело істини, а не побажання. Ми фіксуємо базові принципи роботи агентів у структурованих середовищах на кшталт .cursor/rules чи .cursor/agents — байдуже, працюєте ви в Cursor, Claude Code чи будь-якому іншому агентному інструменті. Головне, щоб логіка роботи існувала як окрема, чітко описана сутність, а не жила виключно в голові одного розробника, який піде у відпустку чи звільниться.

Принципи однакові незалежно від інструменту. В Cursor контекст живе в .cursor/rules і .cursor/agents. У Claude Code — в CLAUDE.md, .claude/commands і skills. Якщо ви на GitHub Copilot — у .github/copilot-instructions.md. Місце різне, суть одна: контекст має бути закомічений у репозиторій, а не в голові одного розробника.

Що конкретно там лежить? Наприклад, у нашому BDA (Backend Developer Agent) є правило: «Перед будь-якими змінами в БД — читай поточну міграцію, не піднімай нову, якщо не знаєш нащо». Це одне речення рятує від значної частини помилок на рев'ю. Таких правил на модуль — 10–20. Вони в Markdown, у репозиторії, і агент читає їх при кожному запуску.

Агент — це роль, а не скрипт. Кожен агент у нас — синтетичний член команди з чіткою роллю: Backend Developer, Business Analyst, Project Manager, Tech Writer. Це напряму випливає з того, як влаштовані і навчені сучасні LLM: модель із чітко окресленою роллю та межами відповідальності працює набагато краще, ніж модель, якій дозволили «бути креативною у всьому». «Ти робиш ось це і тільки це, твоя зона — звідси й досі, не більше» — так само, як ми б сформулювали задачу для реальної людини в команді. Без таких меж LLM намагається уявити собі одразу все, і якість падає.

Підписуйтеся на наші соцмережі

AI не замінює SDLC — він його перебудовує. Йдеться не про заміну циклу розробки агентами, а про побудову нового, агентно-орієнтованого SDLC (Agentic SDLC). Це набагато більше, ніж prompt engineering. Раз у раз чую від команд: «Я написав промпт і поділився ним з колегою». «Як саме?» «Скопіював у Slack». На жаль, це не той підхід. Промптами ділитись не треба — треба будувати контекст: документацію як контекст, код як контекст, ролі агентів як контекст. Під контекстом я маю на увазі прості markdown-файли, які визначають чіткі межі й через ролі бізнес-аналітика чи продакт-менеджера з'єднують машини та людей в одній системі.

Один робочий процес від тікета до релізу

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

Задача потрапляє в роботу (у нас це часто прив'язано до Jira через MCP — протокол, через який агент підключається до зовнішніх систем: Jira, Grafana, поштові скриньки). Agent discovery перетворює формулювання тікета й контекст навколо нього на структуроване технічне завдання. Architecture review agent сканує кодову базу, шукає наявну документацію, перевіряє залежності і формує технічну специфікацію. BDA (Backend Development Agent) або відповідний агент з фронтенду виконує реалізацію в ізольованій гілці за правилом «Спланувати → Виконати»: спочатку план, потім код, потім локальний прогін тестів. QA-агент перевіряє результат за окремим чек-листом. Автоматизований рев'ювер (у нас це CodeRabbit) робить перший прохід по коду — стиль, очевидні проблеми, конвенції. І тільки після цього пул-реквест потрапляє до живої людини на фінальне рев'ю та aprув перед merge.

Кожен агент відповідає лише за свою ділянку. Ніхто не «доробляє все підряд».

Ми свідомо ділимо роботу на три типи процесів:

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

Overnight delivery: що агент робить, а що — ніколи

Один із форматів, який ми використовуємо — overnight delivery: агенти самостійно розвивають і покращують кодову базу в ізольованих гілках, поки команда відпочиває.

Конкретно це виглядає так: агент отримує задачу (наприклад, додати unit-тести до модуля чи написати changelog за diff), виконує її в окремій гілці, відкриває MR з описом. Зранку розробник переглядає — не пише з нуля, а рев'юить готове.

Те, що агент не робить autonomously, ніколи: deploy у production, зміни у міграціях БД, будь-що з secret variables. Це hard rule, а не побажання.

Результати

За рік роботи за цим підходом ми бачимо приріст швидкості розробки в рази, а не у відсотках — на окремих продуктах (зокрема на ConnectiveOne, нашому власному продукті) це вимірювалось приростом швидкості розробки приблизно на 300% рік до року порівняно з попереднім baseline. Але цифра, яка мене хвилює більше за швидкість — це стабільність проходження quality gates при зростанні кількості паралельних агентів. Якщо вона тримається — швидкість є побічним, а не єдиним ефектом. Якщо падає — значить, ви наростили паралелізм раніше, ніж стабілізували правила.

Що може піти не так

Головний ризик — пропустити послідовність і одразу запустити кількох агентів паралельно без стабільних правил і quality gates. Це та сама помилка, яку ми бачимо в командах, що «пробували AI SDLC, і в них не спрацювало»: вони отримують хаотичний результат і роблять висновок «агенти не готові». Насправді не готова була не модель, а процес навколо неї.

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

Третій — ігнорування hard rules з попереднього розділу. Автономія без чітких заборон (production deploy, DB-міграції, secrets) — це не швидкість, а відкладена інцидент-репортна робота.

На практиці: ConnectiveOne і Evergreen

Варто одразу зняти можливу плутанину. ConnectiveOne — наш власний продукт, платформа автоматизації комунікацій. Evergreen — IT-консалтинг і розробка на замовлення. Agentic SDLC народився в Evergreen на реальних клієнтських проєктах, а потім ми застосували його і всередині ConnectiveOne. Тобто ми не продаємо методологію, яку не пробували на собі.

У межах Evergreen AI business digitalization ми провели агентів через кожен етап розробки продукту: discovery вимог, де агенти перетворюють сирі запити клієнтів і транскрипти зустрічей на структуроване розуміння задачі; проєктування системи й архітектури; розробку й тестування за правилом «Спланувати → Виконати»; і автоматичні оновлення документації — система рефлексує над змінами і сама оновлює специфікації та README-файли, щоб наступний розробник не втратив контекст.

C1 Cursor: як ми довели це до автоматизації

C1 Cursor — наш внутрішній оркестратор, який ми розробили для ConnectiveOne і зараз застосовуємо в клієнтських проєктах. Він не є публічним продуктом, але підхід, який він реалізує, можна зібрати з відкритих інструментів: GitHub Actions + Claude API + кастомні rules у репозиторії. Ми просто зробили це one-click замість three-days setup.

Він керує циклом роботи агентів через API або через звичайний frontend-інтерфейс, і завдяки йому ми отримали три речі, які раніше вважали неможливими для команди нашого розміру: overnight delivery (описано вище), автоматизацію роботи з клієнтами — агенти за розкладом перевіряють пошту на запити, генерують статус-апдейти й початкові оцінки термінів — і інтеграцію із зовнішніми системами: підключення агентів до Jira для управління задачами чи до Grafana для автоматичного аналізу алертів.

Що з цим робити вам: 5 кроків на тиждень

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

Якщо хочете спробувати самостійно — ось мінімальний старт на тиждень:

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

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