Як ми будуємо софт AI-native
Від реквесту до релізу: AI вбудований у весь життєвий цикл — трекер, репозиторій, CI/CD, тестування, моніторинг. Людина володіє рішеннями. AI виконує все між ними. Це наш стандарт і наша відмінність від звичайної IT-сервісної компанії.
Автоматизуємо весь конвеєр,
а не лише кодинг
Ми автоматизуємо кожну фазу — від оцінки якості реквесту до пост-релізної телеметрії. Якість вбудована в процес, а не пришита ручним QA в кінці. Саме тому ми продаємо не «години розробників», а передбачуваний, вимірюваний цикл доставки
Сім фаз. П'ять human-воріт
Кожна задача проходить однаковий маршрут незалежно від клієнта чи репозиторію. Колір показує, хто володіє фазою: людина приймає ключові рішення, AI виконує роботу між воротами
Intake
Реквест від клієнта (Slack / email / Linear) потрапляє в систему. AI оцінює якість опису, перевіряє беклог на дублікати, класифікує задачу (фіча / бага / chore), драфтить acceptance criteria та естімейт і формує список уточнюючих питань — окремо ті, що йдуть клієнту, окремо внутрішні
Plan
Для нетривіальних задач AI готує технічний план: підхід, які файли та зони чіпає, архітектурні рішення, ризики, стратегію покриття тестами. Зчитує AGENTS.md репозиторію, щоб дотриматись конвенцій і стеку. Тривіальні задачі проходять цю фазу автоматично
Build
AI імплементує задачу в ізольованому git worktree і ставить уточнюючі питання по ходу — щодо реалізації, бізнес-логіки чи архітектури — прямо в Linear. Пише тести, виведені зі специфікації, а не з власного коду (інакше тести просто підтверджують баг). Має бюджет токенів на задачу і ескалює людині, якщо застряг
Gate
На PR запускається CI/CD плюс окремий AI-рев'юер з іншою лінзою (security, performance, регресії — не той агент, що писав код). Перевірка coverage, SAST, secret scan, SCA. AI постить у Linear звіт: які кейси покриті й непокриті, виклики, ризики, які зони та файли зачеплені й потребують уваги, risk map дифу
QA
Маршрут визначає risk score, а не сторіпоінти. Зусилля — не те саме, що ризик. Low-risk → AI QA проходить test_cases у браузері (Playwright), деплоїть на stg, перевіряє флоу і лишає людині лише непокрите. High-risk (auth / payments / migrations / PII) → завжди людина-QA, незалежно від розміру задачі. Скрізь — регресія по зачеплених зонах плюс smoke-suite
Release
Розробник ставить deploy:prod лише якщо задача не потребує дій від нього (міграцій, скриптів) — інакше заливає вручну за міграційним чеклистом. Feature flags відв'язують деплой від релізу: код їде в prod «темним» і вмикається прапорцем. AI генерує release notes; стратегія розгортання (canary / blue-green) обирається за ризиком; на кожен деплой є rollback-план
Telemetry
Після релізу AI робить smoke на prod, моніторить error rate перші хвилини й тригерить авто-роллбек при аномалії. Окремо рахує метрики пайплайна: cycle time, % PR авторованих AI, rework rate, escape defect rate, скільки людина-QA зловила після AI. Зворотний зв'язок повертається в Intake
Сім правил, на яких усе тримається
Фази — це механіка. Принципи — це причини. Вони відрізняють систему від «накидали AI всюди»
Spec-first
Специфікація — головний артефакт, важливіший за код. AC версіонується й затверджується людиною до старту. Туманна спека = AI заповнює прогалини здогадками про бізнес, якого не знає
AGENTS.md у кожному репо
Один файл з конвенціями, стеком і do/don't для агента. Де-факто стандарт 2026 (GitHub, OpenAI, Anthropic, Cursor, Sourcegraph). Дешево, одразу піднімає якість
Маршрут за ризиком
QA-маршрут визначає ризик, а не зусилля. Зміна на 1 поінт у білінгу — high-risk. Зони auth / payments / migrations / PII завжди йдуть до людини
AI рев'юїть, але не себе
Генератор і рев'юер — різні агенти з різними лінзами. Той самий агент має ті самі сліпі плями. Рев'юер дивиться на security, perf і регресії
Сім правил, на яких усе тримається
І бонус — те, що клієнти цінують найбільше: ви бачите процес, а не лише результат
Людина володіє воротами
П'ять воріт за людиною: AC, план, апрув PR, high-risk QA, prod. AI робить усе виконання між ними. Відповідальність завжди людська
Міряємо автономію
Не утилізацію, а % AI-авторованих PR, усунені години рев'ю, cycle time, escape defects. Це наш доказ клієнту і наш інструмент покращення
Security by default
Підписи вебхуків, ізоляція виконання по репо, секрети поза кодом, audit log. Для FinTech / EdTech клієнтів це перше питання — у нас відповідь готова
Прозорість за замовчуванням
Звіти AI, деплої та метрики видимі клієнту в Linear і Slack у реальному часі. Ви бачите, як задача рухається пайплайном, а не лише демо наприкінці спринту
Звичайна сервісна компанія vs Aimeice
Це не «той самий процес, але швидше». Це інша операційна модель
Що ми вимірюємо й показуємо клієнту
Ви бачите ті самі дашборди, що й ми. Метрики доставки — частина співпраці, а не внутрішня звітність
Одна фіча — кілька репозиторіїв
Правило: одна задача = один репозиторій = один PR. Все, що чіпає backend, frontend і website одночасно, стає parent-задачею з sub-issues — по одній на репо. Parent носить бізнес-цінність, sub-issues проходять пайплайн
Контракт — на Plan-фазі parent-а
До розбиття фіксуємо інтерфейс між репо: API-схему, типи, назви фіч-флагів. BE / FE / WEB будуються паралельно проти контракту. Зміна контракту по ходу = parent повертається в Planning, а не тихий фікс в одному з PR
Порядок деплоя
Backend їде першим — backward-compatible, за вимкненим фіч-флагом. Потім frontend і website. Флаг вмикається, коли всі частини в prod — жоден репо не блокує інший у деплої
QA — дворівневе
Sub-issue: перевірка своєї частини проти контракту — це може робити AI. Інтеграційне QA — лише на parent-і, на stg, коли всі частини готові. risk:high хоч однієї sub-issue → parent успадковує high і йде до людини
Released — одне на фічу
Parent закривається, коли всі частини в prod і флаг увімкнено. Release notes і повідомлення клієнту — одне, з parent-а. Клієнт бачить фічі, а не PR-и
Як не отримати 100 задач в In Progress
AI знімає ліміт на старт роботи — але ворота (люди) лишаються лімітом на завершення. Без правил конвеєр просто набиває черги перед кожними воротами
WIP-ліміти на воротах
In Review ≤ 2 на дева · QA ≤ 3 на інженера · Ready to Deploy ≤ 5 на команду. Ліміти стоять на фазах з людськими воротами, не на AI-фазах. Стовпець повний — не тягнеш нове, а розчищаєш його
Cap на агента
Cyrus веде максимум 3–5 build-задач одночасно. «Закинути 30 задач на ніч» = черга перед рев'ю, яка з'їдає весь виграш і робить рев'ю поверхневим
Stop starting — start finishing
Ранковий порядок дева: рев'ю чужих PR і відповіді агенту → свій код → лише потім нове з Todo. Пріоритет руху задач справа наліво по дошці
Aging-алерт замість стендапа
n8n щодня перевіряє Linear: задача понад 24 год без руху перед воротами → пінг власника воріт у #ai-pipeline. Черга — метрика, яку видно, а не яку згадують
Батчинг воріт
PM апрувить AC двічі на день фіксованими слотами, а не по одній задачі щогодини. Ворота дешеві, коли батчаться, і руйнівні для фокуса, коли дриблінгом
Клієнт бачить parent-и
Sub-issues — внутрішня механіка. У звітності клієнта — фічі: «3 в роботі», а не «10 задач». Менше шуму — більше довіри
Тиждень 1 — фундамент і вхід
Мета: Linear стає носієм стану пайплайна, а кожен новий реквест заходить через AI-intake
Тиждень 2 — виконання і контроль
Мета: перші задачі проходять пайплайн наскрізь, а черги перед воротами видно й керовано
Це система.
Не обіцянки.
Ми не продаємо години розробників. Ми продаємо вимірюваний цикл доставки — з людською відповідальністю на кожних воротах і AI-швидкістю між ними.
Готові побудувати разом?
Обговоримо, як AI-Native Delivery прискорить доставку й знизить кількість дефектів у вашому проєкті