Skip to main content
vibe-codingsreai-automation

Naive + SRE: як тепер збирають софт

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

Технічний контекст

Я зачепився за цей кейс не через красиву назву, а тому що вже бачу таку саму механіку наживо: спочатку "наївне" складання через AI automation, потім інженерне доведення. Не як теорія, а як реальний конвеєр.

Схема проста і дуже впізнавана. Люди, не обов'язково з розробки, беруть Cursor, GitHub, агента поверх Gemini або іншої моделі, накидують PRD, ріжуть задачу на вертикальні шматки і отримують робочий прототип. Він проходить happy path, виглядає переконливо і іноді навіть доїжджає до перших користувачів.

Отут багато хто плутає "працює" з "готово". Я багато разів бачив, як штучний інтелект integration чудово збирає UI, CRUD, базові API і зв'язки з зовнішніми сервісами, але сиплеться на правах доступу, ідемпотентності, rate limits, логуванні та міграціях.

Саме тому друга половина схеми важливіша, ніж здається спочатку. SRE або сильні platform/backend-інженери приходять не "полагодити пару багів", а заново вибудувати надійність: моніторинг, secret management, rollback, алерти, тестовий контур, CI/CD, базову threat model. І так, іноді після такого аудиту половину згенерованого коду простіше переписати спокійно, ніж героїчно латати.

При цьому сам патерн мені подобається. Я б не називав його новою професією, але як blueprint для AI implementation в командах це вже виглядає цілком життєздатно.

Вплив на бізнес та автоматизацію

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

Програють команди, які вирішать, що SRE-фаза необов'язкова. Тоді виходить класичний vibe coding: демо є, експлуатації немає.

Я б закладав таку модель одразу в архітектуру процесу: швидкий прототип, жорсткий handoff, потім hardening за чек-листом. Ми в Nahornyi AI Lab якраз вирішуємо такі стики для клієнтів: де залишити швидкість, а де без ілюзій зібрати нормальну AI solutions architecture, щоб продукт не помер після першого успіху. Якщо у вас вже накопичилися хаотичні AI-прототипи, я з командою можу допомогти перетворити їх на робочу систему, а не на дорогу колекцію демо.

Раніше ми детально розбирали концепцію "subprime code crisis" — як впровадження ШІ в розробку може погіршити якість коду та підвищити сукупну вартість володіння. Методологія з наївним креативним розробником і SRE-загартуванням якраз спрямована на те, щоб переламати цей сценарій і випускати в прод надійні продукти.

Поділитися статтею