Ваша команда вже має Claude Code. Чому вона все одно не стала швидшою?

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

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

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

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

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

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

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

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

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

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

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

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

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

Як це виглядає у нас на практиці

Наш повний цикл — збір вимог → проєктування системи → розробка → тестування → деплой, і на кожному етапі працюють окремі агенти. У нас це, наприклад, BDA (Backend Development Agent), UI/UX Agent, кілька QA-агентів і спеціалісти під конкретні процеси інтеграцій.

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

Оркестрація в нас починається з агентів, зосереджених на самій розробці — backend, конструктор/білдер, frontend — а вже потім у справу вступають люди, які ведуть весь продуктовий цикл. Ми свідомо ділимо роботу на три типи процесів:

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

Від запиту клієнта до релізу: наш конвеєр агентів

У межах Evergreen AI business digitalization ми провели агентів через кожен етап розробки продукту — і ось як це виглядає в реальній роботі.

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

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

На етапі розробки й тестування в дію вступають MCP Tool Builder і спеціалізовані QA-агенти, які працюють за правилом «Спланувати → Виконати»: кожен генератор коду вміє не лише написати рішення, а й локально протестувати та перевірити його.

І нарешті — автоматичні оновлення документації. Система не просто пише код: вона рефлексує над змінами і сама оновлює специфікації та README-файли, щоб наступний розробник, який приєднається до проєкту через місяць чи рік, не втратив контекст.

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

Щоб довести цей підхід до логічного завершення, ми розробили власний інструмент оркестрації — C1 Crossroad. Він керує циклом роботи агентів через API або через звичайний frontend-інтерфейс, і завдяки йому ми отримали три речі, які раніше вважали неможливими для команди нашого розміру.

Перша — overnight delivery: агенти самостійно розвивають і покращують кодову базу в ізольованих гілках, поки команда відпочиває, а зранку люди переглядають готові результати. Друга — автоматизація роботи з клієнтами: агенти за розкладом перевіряють пошту на запити, генерують статус-апдейти й початкові оцінки термінів. Третя — інтеграція із зовнішніми системами: підключення агентів до Jira для управління задачами чи до Grafana для автоматичного аналізу алертів.

Що з цим робити вам

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

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

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