На початку 2025 року дослідницька група METR провела дослідження, яке навряд чи сподобається інженерним лідерам. Вони взяли шістнадцять досвідчених розробників open-source, дали їм реальні завдання з їхніх власних репозиторіїв і випадковим чином вирішували для кожного завдання, чи можна використовувати AI-інструменти. Ці розробники вільно володіли такими інструментами. Вони очікували, що допомога AI прискорить їх приблизно на чверть. Виміряний результат виявився протилежним: завдання, виконані з AI, зайняли приблизно на дев'ятнадцять відсотків більше часу, ніж без нього. Але найтривожніший висновок — не саме уповільнення, а розрив у сприйнятті навколо нього. Навіть після завершення роботи розробники все ще вважали, що AI зробив їх приблизно на двадцять відсотків швидшими.Порівняйте це число з тим, яке цитують усі. Широко відоме контрольоване дослідження GitHub показало, що розробники писали HTTP-сервер на JavaScript приблизно на п'ятдесят шість відсотків швидше з Copilot, ніж без нього. Обидва дослідження реальні. Обидва проведені компетентно. Розрив між ними — не суперечність, яку треба вирішити, обравши "правильне". Це і є головна тема цієї статті. Завдання "з нуля" винагородило генерацію, бо людина володіла малим контекстом, який модель могла надати. Експерт, що працював у коді, який вже носив у голові, сповільнився, бо обмежуючим фактором ніколи не була швидкість набору тексту. Це було судження — і інструмент додав шар перевірки та виправлень поверх судження, яке в розробника вже було.Це і є прихована змінна за майже кожним розчаровуючим впровадженням AI. Інструмент — не втручання. Втручання — це процес навколо нього.Купівля інструмента — це не зміна процесуБільшість організацій впроваджують AI так само, як будь-який інший інструмент для розробників. Закупівля погоджує ліцензії, ентузіаст проводить lunch-and-learn, дашборди починають рахувати прийняті пропозиції — і всі чекають, коли графік delivery почне вигинатися вгору. Зазвичай він не вигинається, і причина структурна. Асистент, доданий у незмінений процес, прискорює один локальний крок, залишаючи кожен наступний крок так само обмеженим, як і раніше.Найяскравіший публічний доказ цього — програма DORA від Google, яка роками вимірює продуктивність доставки ПЗ у тисячах організацій. У звіті за 2024 рік зростання впровадження AI на двадцять п'ять відсотків було пов'язане з приблизно півторавідсотковим зниженням пропускної здатності delivery та семивідсотковим зниженням стабільності. Прочитайте це повільно. Більше AI корелювало з трохи гіршим delivery, а не кращим. Це кореляційні дані з опитування, а не доказ того, що AI шкодить delivery, але механізм, запропонований дослідниками, легко впізнати в будь-якій команді: швидша генерація коду створювала більші набори змін, а більші набори змін складніше рев'ювити, тестувати та безпечно відвантажувати.Видання 2025 року загострило картину, а не спростувало її. Зв'язок пропускної здатності з впровадженням AI став позитивним у міру того, як команди навчилися працювати з інструментами, але нестабільність продовжувала зростати, і власне резюме звіту вартує процитувати дослівно: "Тертя не зникає — воно переміщується: від ручної рутини до прийняття рішень і перевірки." Це речення — аргумент усієї статті в одному рядку. Коли одна частина конвеєра стає дешевшою, робота нікуди не зникає. Вона накопичується там, де ваша спроможність найслабша.Це можна побачити на рівні одного тікета. Розпливчаста вимога, передана здатній моделі, не провалюється голосно. Вона видає правдоподібну, добре структуровану, впевнено неправильну реалізацію, яка проходить поверхневу перевірку. Згенерований набір тестів не відкидає неоднозначну специфікацію. Він фіксує ту поведінку, яку модель вгадала, а потім захищає цю поведінку від майбутніх змін — тож неправильна відповідь стає частиною фундаменту. Швидкість за клавіатурою перетворюється на затримку в черзі рев'ю, дефекти, що спливають через тиждень, і тихий податок на сеньйорів, які тепер витрачають вечори на реконструкцію задуму з коду, який вони не писали. Локальне прискорення, глобальне гальмування.Координаційний шар, який агентам справді потрібенЯкщо проблема в процесі, вирішення — координаційний шар, якого більшість команд ніколи не будували, бо неозброєні люди носять його неявно. Коли сеньйор-інженер бере завдання, він уже знає критерії прийняття, крихкі частини системи, конвенції, які застосовує команда, і до кого звернутися, коли щось незрозуміло. У моделі нічого цього немає, поки ви не зробите це явним і машиночитаним. Ця практика тепер має назву — context engineering, і вона менш гламурна, але набагато вирішальніша за формулювання промптів.Робочий координаційний шар складається з кількох конкретних частин. Специфікація описує, що має робити зміна і, що не менш важливо, як усі дізнаються, що вона спрацювала: критерії прийняття у перевірюваних термінах. Настанови на рівні репозиторію — закомічений файл з інструкціями — повідомляють будь-якому агенту локальні конвенції, директорії, яких можна торкатися, і команди, які мають пройти, перш ніж роботу вважати завершеною. Багаторазові skills пакують завдання, яке команда виконує часто — патерн міграції чи чекліст релізу, — щоб поведінка була послідовною, а не вигаданою заново щоразу. Доступ до інструментів надається свідомо: агент, що може читати трекер задач, запускати набір тестів і відкривати чернетку pull request'у, корисний, а агент з необмеженим доступом на запис до продакшн-даних — це відповідальність.Саме тут стандарт на кшталт Model Context Protocol заслуговує на увагу. Anthropic опублікувала MCP як відкритий стандарт наприкінці 2024 року, щоб вирішити нудну, але реальну проблему: кожне з'єднання AI із системою раніше було індивідуальною інтеграцією, що робило доступ непослідовним і некерованим. Спільний протокол дозволяє підключити агента до вашого трекера задач, документації чи системи спостережності через один аудитований інтерфейс. Суть не в протоколі як технології. Суть у тому, що доступ стає чимось, що можна побачити, обмежити за обсягом і відкликати — а це передумова довіри агенту чогось справді важливого.Специфікації мають застереження, яке ентузіасти часто пропускають. Точна специфікація прибирає неоднозначність щодо реалізації. Вона не каже вам, чи варта фіча того, щоб її будувати, який компроміс обслуговує клієнта, чи коли сказати "ні". Spec-driven розробка переміщує продуктове судження вгору за потоком і робить його явним. Вона його не замінює. Організація, яка ставиться до написаної специфікації як до заміни рішення про те, що варто робити, автоматизувала легку половину проблеми і покинула складну половину.Де AI заробляє своє місце у життєвому циклі розробкиПравильне питання — не чи використовувати AI у SDLC, а де, обмежене чим, перевірене ким і виміряне як. Проходження по стадіях життєвого циклу робить патерн конкретним, і він повторюється: дати агенту обмежене завдання, залишити важливе рішення за людиною, відстежувати результат, а не активність.Планування та вимоги. Вузьке місце тут — рідко написання тікетів. Це неоднозначність, яка доживає до реалізації, де її дорого усувати. Модель по-справжньому корисна як ворожий читач наміру. Спрямуйте її на чернетку епіка і зріз наявної системи та попросіть виявити невизначені терміни, відсутні кейси помилок, суперечливі критерії прийняття й граничні умови, які ніхто не назвав. Одна типова команда використала це, щоб перетворити "користувачі можуть експортувати свої дані" на набір гострих питань: які формати, яка стеля рядків, які поля для видаленого акаунту, що відбувається, коли експорт переживає сесію. Те, що не можна делегувати, — рішення, яке провокують ці питання. Чи дозволені взагалі експорти для видалених акаунтів — це юридичне і продуктове рішення, а не модельне. Результат, який варто вимірювати, — частка історій, які доходять до sprint review без відкату через вимоги.Архітектура та дизайн. Обмеження на етапі дизайну в тому, що наслідки відкладені й дорогі. AI найбільше допомагає як швидкий генератор варіантів і стрес-тестер пропозицій. Зобов'язання залишається людським, бо відповідальність за рішення, всередині якого організація житиме роками, не можна делегувати. Безпека належить цьому етапу, а не кінцевому — саме це стверджує NIST Secure Software Development Framework. Конкретна міра цінності тут — кількість дизайн-вад і проблем безпеки, виявлених на рев'ю, порівняно з продакшеном.Реалізація. Генерація — реальний важіль там, де людині бракує контексту: скаффолдинг нового сервісу, знайомий CRUD, переклад функції іншою мовою. Вона слабша там, де вільний інженер уже тримає ментальну модель у голові. Обмежене завдання — маленька, специфікована зміна з тестами, подана як чернетка на рев'ю, ніколи не як неконтрольований коміт. Опитування Stack Overflow 2025 показало: найпоширеніше розчарування AI (майже половина респондентів) — вихід "майже правильний, але не зовсім". Довіра до точності AI впала нижче третини. Важливий результат — не рядки коду, а час циклу рев'ю та рівень дефектів, що прослизнули.Тестування та QA. Згенерований набір тестів виглядає як старанність, але модель, залишена сама на себе, охоче напише тести, що стверджують, ніби код робить те, що робить зараз — тавтологія, вбрана у верифікацію. Використаний правильно, агент розширює людиною заданий оракул: складає кейси, пропонує граничні входи, позначає непротестовані гілки. Визначення правильності — робота людини, і вона не переноситься. Вимірюваний результат — дефекти, що прослизнули, і частка невдалих змін, а не кількість тестів.Розгортання, операції та підтримка. В операціях вузьке місце — час під тиском. Агенти допомагають, стискаючи нудні частини: таймлайн з логів, кореляція сплеску з деплоями, чернетка резюме інциденту, пропозиція rollback для затвердження людиною. Автономія має бути пропорційною оборотності й ризику: PR, що піднімає версію бібліотеки, — низькоризиковано; production rollback чи деструктивна міграція без людини в контурі — обмінює невелику економію часу на постійний ризик. Результати, за якими варто спостерігати, — час відновлення сервісу, частка невдалих змін і частота деплоїв.Композит: скорочення затримки рев'ю без зрізання кутівКоманда середнього розміру вже придбала AI-ліцензії і не побачила покращення в delivery. Медіанний час від відкриття pull request'у до злиття зріс приблизно з дня до майже трьох, а частка невдалих змін повзла вгору. Замість купівлі ще ліцензій чи заборони інструментів, вони перепроєктували один процес — шлях зміни від тікета до злиття:Коротка специфікація з перевірюваними критеріями прийняття до початку будь-якої AI-асистованої реалізації.Закомічений файл інструкцій репозиторію й обмежений доступ агента до інструментів через єдиний перевірений інтерфейс — тести й чернетка PR, і нічого більше.AI-рев'юер перед людським, вузько орієнтований на механічні проблеми, щоб людина фокусувалась на дизайні й намірі.Агент ніколи не зливав зміни сам. За квартал медіанний час рев'ю повернувся нижче дня, частка невдалих змін повернулася до попереднього рівня, пропускна здатність зросла. Вони не зробили модель кращою. Вони зробили процес здатним поглинати те, що модель виробляла.Чого має навчитися кожна рольНіхто не мусить ставати prompt-інженером. Продакт-менеджер вчиться писати перевірюваний намір — критерії, які агент реалізує буквально. Інженер зсувається від автора до редактора й специфікатора: читає згенерований код з обґрунтованою підозрою, розуміє, коли власний контекст робить інструмент чистими витратами. QA-інженер піднімається на рівень вище — від написання кейсів до визначення оракула правильності. Інженерний менеджер і архітектор керують автономією і читають сигнали на рівні системи. Метанавичка, спільна для всіх: помічати й ескалувати невизначеність. Розрив у сприйнятті METR означає, що індивідуальна інтуїція про цінність AI не заслуговує довіри — виграють ті, хто вимагає цифру.Вимірювання того, що справді важливоМетрики активності (ліцензії, прийняті пропозиції, рядки коду) можуть зростати, поки delivery погіршується — саме це показав METR. Метрики результату прив'язані до бізнесу: lead time, частота деплоїв, частка невдалих змін, час відновлення сервісу, доповнені часом циклу рев'ю та дефектами, що прослизнули. Дисципліна, яка робить ці числа значущими, — порівняння з базовим рівнем на подібних класах робіт. Одна цифра "до і після" не встановлює причинність.ВисновокAI не покращує delivery, пишучи код швидше. Він покращує delivery, коли команда перебудовує потік наміру, контексту, верифікації й відповідальності навколо нього. Ліцензія — легка покупка. Операційна модель — це і є робота, і саме її жоден вендор вам не продасть.Так ми думаємо про постачання програмного забезпечення у VRB Tech. vrbtech.co
/