AI-native SDLC — це про трансформацію організації, а не про інструменти
Зі зрозумілих причин більшість компаній зараз хочуть собі AI-native SDLC (мені більше подобається термін AI-driven SDLC, але він поки програє за популярністю). І тут на них чекає неприємний сюрприз — поточна архітектура, процеси та команди часто просто не готові до таких змін. Вони будувалися під зовсім інші реалії, в основі яких лежали два фундаментальні обмеження: «писати код руками довго і складно» та «люди можуть опанувати й підтримувати вузький спектр знань».
Якщо хочеться швидше — потрібно робити паралельно. Щоб робити паралельно, потрібно більше людей. Люди мають вузькі технічні навички, тому потрібні різні спеціалізації розробників. Оскільки вони працюють над однією фічею, їх потрібно об’єднати в команди. Бізнес не має часу й бажання готувати якісні артефакти для розробки — введемо додаткові ролі, як-от бізнес-аналітик або проєктний менеджер. На додачу до вузької спеціалізації, розробники не можуть об’єктивно перевіряти свою роботу. Додамо в команду QA-інженерів. Ось і вийшла сучасна команда розробки з FE, BE, QA та додаткових ролей.
Тепер навколо цієї команди виникають процеси розробки. Оскільки якісно обмінюватися інформацією в IT ми так і не навчилися (документацію писати руками не любить ніхто, а підтримувати її складно), будемо збиратися на численні мітинги й обговорювати все голосом. Оскільки розробка триває довго, потрібно ретельніше планувати, куди витрачати зусилля і коли очікувати результатів. З’являється ще більше мітингів. Під час паралельної роботи над фічею потрібно синхронізувати зусилля. Тут з’являються трекери задач, чати, дейлі та інші звичні нам атрибути.
Можна продовжувати довго, але, сподіваюся, загальну суть причинно-наслідкових зв’язків ви вловили. А тепер уявіть, що обидва фундаментальні обмеження більше не актуальні. За допомогою AI-інструментів ми можемо дуже швидко генерувати код будь-якої складності та використовувати спектр знань будь-якої ширини. Чи вдасться по-справжньому ефективно натягнути AI на існуючі реалії в компаніях і отримати прискорення в рази?
Дуже сумніваюся. А практика показує, що результати виходять далекими від очікувань. Розробники починають генерувати в рази більше коду й створюють величезне навантаження на етап тестування, який у більшості компаній залишився ручним або напівручним з фокусом на end-to-end тестування. І тут з’являється ціла купа нових проблем: від масштабування середовищ до екстреної мінімізації ручного тестування. Якщо бізнес, як і раніше, не залучається до процесу розробки, то виникає ще кумедніший ефект «слопогенерації». Раніше, під час довгої розробки, у команди виникали додаткові запитання до бізнесу, і відповіді знаходилися ще до завершення роботи. Зараз же LLM здатні закрити всі прогалини здогадками чи припущеннями, з яких потім генерується рішення. І що більше таких прогалин, то далі рішення буде від очікувань бізнесу. Це лише кілька прикладів очікуваних ефектів.
Яким же компаніям AI-native SDLC «з коробки» допоможе вийти на новий рівень продуктивності? Тим, у кого вже є такі практики, як сервісна архітектура з розподілом за доменним принципом, Continuous Delivery, QA-стратегія з прицілом на максимальну автоматизацію, маленькі доменні команди із залученим PO, інфраструктура, що легко масштабується, тощо. Тобто AI знову робить сильних кратно сильнішими, а слабких не надто посилює.
Тому впровадження AI-native SDLC — це не про AI-інструменти та моделі, а про внутрішню трансформацію організації. А вона на порядок складніша, ніж впровадження нових інструментів.