Погляд фаундера на те, коли ШІ справді прискорює інженерну роботу, коли уповільнює її, і що це змінює у підході до найму.
У командах із високим рівнем впровадження ШІ час рев’ю pull request зріс майже на 91 відсоток, за даними Faros AI, на основі даних понад 10 000 розробників із 1255 команд. Написання коду стало швидшим. Швидшим не став результат, за який ви фактично платите: робочий продукт, що виконує саме те, що ви просили.
Я керую компанією, де інженерія є ключовою частиною бізнесу, і спостерігав, як це відбувається у власній команді. Два роки тому одна фіча забирала в розробника майже цілий день: години в редакторі, покроковий дебаг, багато однотипного шаблонного коду. Сьогодні той самий розробник може витратити годину на те, щоб чітко описати, що саме потрібно побудувати, запустити трьох AI-агентів за цим описом і провести решту дня, читаючи та перевіряючи те, що вони згенерували. Проте, роботи менше не стало. Це інша робота, і якщо ви наймаєте розробників або керуєте ними, це змінює те, як варто наймати і за що варто платити.
Це не застереження, що ШІ переоцінений, і не заклик повірити, що він вирішує все. Це спроба відповісти на запитання, яке мені найчастіше ставлять інші фаундери: коли ШІ дійсно робить мою команду швидшою, а коли я просто себе обманюю?
Що ж змінилося?
Останні два десятиліття найдорожчою частиною розробки софту було перетворення бізнес-ідеї на робочий код. Тепер це найдешевша частина. Сучасні AI-моделі генерують перший варіант коду за хвилини. Те, що раніше займало цілий робочий день, тепер більше схоже на годину підготовки та швидкий перший чорновик.
Шон Гроув, інженер OpenAI, стверджує, що саме написання коду становить лише 10-20 відсотків цінності, яку створює інженер. Решта 80-90 відсотків, за його визначенням, – це те, що він називає структурованою комунікацією: точне формулювання того, що саме потрібно побудувати настільки чітко, щоб це можна було коректно реалізувати. Необов’язково погоджуватися з точними цифрами, щоб побачити напрям.
На практиці це означає, що ваші інженери тепер більше часу витрачають на написання чіткої специфікації і перевірку того, що згенерував AI-агент, та менше часу на ручне написання кожного рядка коду. Деякі команди йдуть далі і роблять саму специфікацію джерелом істини, а згенерований код позначають як те, що ніхто вручну не редагує. Більшість команд перебуває десь між цими двома крайнощами. У будь-якому разі зсув один і той самий: реальна робота і реальна вартість тепер зосереджені в плануванні та перевірці.
Коли ШІ дійсно прискорює процес розробки, а коли ні
Це питання, яке найбільше впливає на ваш бюджет і терміни, і чесна відповідь така: усе залежить від того, що саме будується і хто це будує.
На простих, нових проєктах, наприклад, створення MVP , докази однозначні й позитивні. У контрольованому дослідженні, де розробники створювали простий HTTP-сервер з нуля, ті, хто використовував AI-асистента, завершували завдання помітно швидше. Дослідження показують, що в таких проєктах, кількість змерджених pull request зросла приблизно на 26 відсотків. Тож, якщо ви створюєте щось нове, та нескладне, ШІ, найімовірніше, справді прискорить постачання.
На великих, вже існуючих системах, які підтримують досвідчені інженери, картина протилежна. Дослідження METR спостерігало за досвідченими розробниками з відкритим кодом, які працювали у власних великих, зрілих репозиторіях обсягом у мільйони рядків коду, і виявило, що з ШІ вони працювали на 19 відсотків повільніше, хоча самі ці розробники вважали, що стали приблизно на 20 відсотків швидшими. Цей розрив між відчуттям швидкості та реальною швидкістю показує, що саме варто знати фаундеру, перш ніж вірити звіту про статус проєкту. Справедливості заради: пізніше METR переглянуло це дослідження через помилку у виборі вибірки, тож варто сприймати його як один із значущих сигналів, а не як остаточний вердикт.
Під результатом лежить проблема довіри, про яку варто знати, перш ніж покладатися на результат, згенерований ШІ. Розрив між обсягом делегованої роботи та рівнем довіри до неї є якраз тим місцем, де ховаються витрати. Час, заощаджений на написанні, згодом повертається у вигляді виснажливого й дорогого аудиту.
Практичне правило, яким я користуюся, коли хтось каже, що проєкт вдалося зробити швидко завдяки ШІ: запитати, чи це була невелика, самодостатня частина нової роботи, чи зміна у великій системі, від якої вже залежить бізнес. У першому випадку заяві про швидкість можна вірити. У другому варто спитати, що саме перевірили і хто це зробив, перш ніж повірити.
На що звертати увагу, наймаючи чи оцінюючи розробників
Якщо швидкість набору тексту і знання синтаксису напам’ять важать менше, ніж здається, то й фільтрувати кандидатів за ними варто менше. Натомість непропорційно зросла цінність кількох навичок, жодна з яких не потрапляє до типового резюме-фільтра.
Архітектурне мислення: чи здатна ця людина визначити, як має бути влаштована система, а не просто реалізовувати її складові?
Точність у формулюванні вимог: чи може вона перетворити розпливчасту ідею на кшталт «хочемо, щоб працювало як X» на щось конкретне, що підпадає під числові метрики для перевірки?
Контекстна інженерія: чи вміє вона дати AI-системі потрібний контекст і обмеження, щоб вона видала придатний результат з першого чи другого разу, а не щось, що лише формально відповідає словам запиту?
Оркестрація: чи може вона запускати й координувати кілька AI-потоків роботи над різними частинами проєкту одночасно, не втрачаючи контролю над тим, що зробив кожен з них?
АІ-розробник , йому все одно потрібно достатньо володіти кодом, щоб помітити неправильну відповідь, бо оцінити те, що не вмієш читати, неможливо. Це означає, що сама швидкість написання коду більше не є конкурентною перевагою, відповідно, і процес найму потрібно будувати за новими правилами.
Хто відповідає за помилку
Ось що не змінюється, наскільки б не покращувалися інструменти: відповідальність за результат несе той, хто затверджує зміну. Ви не можете притягнути ШІ до відповідальності, коли щось ламається у продакшні. Пояснити й відповісти за те, що вийшло в реліз, має конкретна людина.
У цього є пряме бюджетне значення. Якщо ваша команда генерує набагато більше коду, ніж раніше, рев’ю і перевірка – це обов’язкові витрати. План, який враховує, що ШІ напише перший чорновик, але не враховує, що хтось його ретельно перевірить, це не швидший план. Це план із прихованим, незапланованим кроком, і зазвичай він проявляється в найгірший можливий момент: у продакшні, на очах у клієнта. Тож, клієнти, враховуйте це.
Що це означає для вашого плану найму
Кількість простих позицій у компаніях із високим рівнем впровадження ШІ скорочується, тоді як премія за навички в архітектурі та роботі з ШІ зростає. Якщо ваш план найму досі базується на тому, що потрібна велика кількість розробників для рутинної реалізації, цю думку варто переглянути.
Колись передбачалося, що компілятори мали дозволити бізнес-аналітикам писати власний софт без інженерів. Мови четвертого покоління та CASE-інструменти обіцяли застосунки, згенеровані прямо зі специфікацій, без розробників. DevOps мав змусити роль адміністратора баз даних зникнути. Нічого з цього не збулося так, як прогнозували. Кожна така заявка знижувала поріг входу в розробку софту, що збільшувало обсяг софту, який будується, а це, своєю чергою, збільшувало попит на більш кваліфікованих інженерів, здатних це будувати і відповідати за це. Компілятори не усунули розробників, вони усунули написання коду вручну на асемблері й підняли рівень, на якому всі працюють. Адміністратор баз даних не зник разом із DevOps, ця роль просто трансформувалася під нові вимоги.
Практичний висновок для вашого плану найму такий: не сприймайте зміни через AI, як причину зменшення інвестицій в інженерні кадри. Сприймайте його як причину змінити те, у які кадри ви інвестуєте. Менше людей, найнятих суто для написання рутинного коду, більше ваги навичкам безпеки й архітектурного мислення.
Три речі, які я зробив би інакше цього кварталу
Перестаньте наймати інженерів за знання синтаксису та наявність логічного мислення. Натомість зважайте на архітектурне мислення і точність формулювання вимог. Просіть кандидатів пояснити, як вони перевірятимуть результат, згенерований ШІ, а не лише те, як вони його отримають.
Закладайте час на перевірку в кожну оцінку, що передбачає код, згенерований ШІ, як заплановану статтю витрат, а не те, на чому сподіваєтеся заощадити.
Не сприймайте зміни в сфері як «ШІ замінює розробників» чи «ШІ заощадить нам час і гроші». Кожне подібне нововведення у минулому піднімало планку вимог до інженерів, а не усувало потребу в них. Плануйте найм і очікування відповідно.
Розробники, яких ви зараз наймаєте, – це спеціалісти з питань архітектури, безпеки, опису та перевірки суджень . Вони мають володіти здатністю точно сформулювати, що має бути побудовано, і знати, спираючись на докази, чи так воно і вийшло. Це інші критерії найму, ніж три роки тому, а також і інші пункти витрат. Ціна розробки за допомогою ШІ інструментів, коли дешевше? читайте на сайті HiTech. Expert.