Штучний інтелект уже кілька років поспіль подається як головний прискорювач розробки програмного забезпечення. Від GitHub Copilot до Claude Code — інструменти обіцяють швидше писати код, менше помилятися і загалом «підняти планку» інженерної продуктивності. Але що відбувається насправді, коли ці обіцянки стикаються з корпоративною культурою, системами оцінки ефективності та реальними командами?
У розмові на каналі AI Engineer колишній інженер Uber і Skyscanner, автор популярної розсилки The Pragmatic Engineer Ґергей Орош поділився історіями з великих компаній, внутрішніми дослідженнями та спостереженнями з команд, які вже кілька років живуть з AI у продакшені. Ці приклади дозволяють тверезо подивитися на питання: чи є AI‑продуктивність реальною, чи це поки що більше відчуття, ніж вимірюваний ефект?
Коли «ввімкни AI» стає наказом: кейс Coinbase і ціна опору
Один із найяскравіших прикладів того, як керівництво намагається «продавити» використання AI, — історія з Coinbase. Генеральний директор біржі Браян Армстронґ розіслав співробітникам лист із вимогою перейти на використання AI‑інструментів. Формулювання було жорстким: усі мають «стати на борт» і почати користуватися AI, а з тими, хто не зробить цього протягом тижня, у нього «буде розмова».
За приблизно тиждень, у суботу, принаймні одного інженера звільнили саме в цьому контексті. Сигнал був однозначний: відмова або повільне прийняття AI‑інструментів може коштувати роботи.
Контекст робить цю історію ще гострішою. У Coinbase базові зарплати окремих інженерів сягають 300–400 тисяч доларів на рік — і це до врахування акцій та бонусів. За такі гроші компанія очікує не просто «доброї роботи», а максимальної віддачі й готовності швидко адаптуватися до нових інструментів. У середовищі, де компенсація такого рівня, страх втратити місце через «недостатньо активне» використання AI стає потужним мотиватором.
Такий підхід створює специфічну динаміку. З одного боку, він справді змушує людей експериментувати з новими інструментами, навіть якщо ті ще сирі або неочевидні в застосуванні до складних легасі‑кодбаз. З іншого — це не означає автоматичного зростання продуктивності. Часто це лише гарантує, що AI буде «увімкнений», але не те, що він буде ефективно інтегрований у робочий процес.
Цей кейс добре ілюструє, як питання AI‑продуктивності в реальних компаніях швидко перетворюється з технічної дискусії на розмову про владу, очікування та страхи. Коли ставка — сотні тисяч доларів на рік, мало хто ризикує сказати: «Цей інструмент мені не допомагає, я не бачу сенсу ним користуватися».
Anthropic як противага: коли AI справді пише більшість коду
На іншому полюсі — компанії, які демонструють, що AI може стати не просто «галочкою» у звіті, а реальним двигуном продуктивності. Один із найчастіше згадуваних прикладів — Anthropic, розробник Claude.
Компанія публічно заявляла, що значна й зростаюча частка її коду пишеться за допомогою власних AI‑інструментів, зокрема Claude Code. Це не просто маркетингова фраза: для Anthropic використання AI у розробці — частина базової операційної моделі. Інженери системно покладаються на інструмент, який створює їхня ж компанія, а керівництво бачить у цьому не тимчасовий експеримент, а стратегічний напрям.
Цей контраст важливий. У багатьох великих компаніях керівники бачать успіх Anthropic, зростання її доходів і чують заяви про те, що «велика частина коду пишеться AI». Далі працює проста логіка: якщо там AI так сильно використовується, то, мабуть, саме це і є причиною їхнього успіху. Отже, якщо наші інженери не користуються AI достатньо активно, ми ризикуємо відстати.
Проблема в тому, що кореляція не дорівнює причинності. Anthropic будувала свої процеси навколо AI зсередини, а не «прикручувала» інструменти до старих практик. Багато інших компаній намагаються зробити навпаки: взяти усталені процеси, легасі‑кодбази, культуру, що формувалася роками, і просто додати туди AI‑інструменти з вимогою «користуйтеся більше».
Результат часто виявляється далеким від очікувань. Там, де Anthropic показує реальне зростання швидкості й обсягу розробки, інші організації отримують радше статистику використання, ніж відчутний приріст продуктивності.
Відчуття проти реальності: уроки невеликого дослідження Meta
Один із небагатьох публічних емпіричних поглядів на AI‑продуктивність — невелике дослідження Meta. У ньому взяли участь близько 30 розробників, які працювали з AI‑інструментами в умовах, наближених до реальних завдань.
Результати виявилися парадоксальними. Учасники відчували, що стали приблизно на 20% продуктивнішими. Водночас вимірювані показники — фактичні результати роботи — показали протилежне: у середньому продуктивність знизилася приблизно на 20%.
Цей розрив між суб’єктивним відчуттям і об’єктивним результатом — ключовий для розуміння нинішнього стану AI‑інструментів у розробці. Інженери відчувають себе швидшими: код генерується миттєво, рутинні фрагменти з’являються за секунди, складні API можна «розпитати» в моделі замість читати документацію. Але загальний цикл розробки — від постановки задачі до стабільного продакшену — не обов’язково скорочується.
Причин може бути кілька. AI часто генерує код, який виглядає переконливо, але містить приховані помилки або не враховує контекст конкретної системи. Перевірка, доопрацювання й інтеграція такого коду можуть займати більше часу, ніж написання з нуля досвідченим інженером. Додається й когнітивне навантаження: потрібно постійно оцінювати, чи можна довіряти пропозиціям моделі, чи не пропустили ви критичний нюанс.
Цікаво, що в цьому ж дослідженні був один яскравий виняток: учасник, який став значно продуктивнішим завдяки AI. На його тлі видно, що інструменти не є «магічним прискорювачем» для всіх, але можуть радикально змінити ефективність окремих людей, які вміють ними користуватися.
Цей одиничний «суперкористувач» добре вписується в ширшу картину: AI‑інструменти сьогодні дають найбільший виграш тим, хто інвестує час у глибоке освоєння, експериментує з робочими процесами й не боїться відмовлятися від звичних підходів.
AI як підсилювач для нетехнічних колег: де приріст уже відчутний
Якщо для досвідчених інженерів ефект AI‑інструментів поки що неоднозначний, то в іншій категорії користувачів виграш виглядає значно очевиднішим. У деяких командах AI виявився особливо ефективним не як «турбо‑двигун» для сеньйорів, а як місток для нетехнічних колег у світ коду.
Один із практичних сценаріїв — коли інженер налаштовує й підтримує AI‑агентів або інструменти для колег, які зазвичай не пишуть код: продакт‑менеджерів, аналітиків, дизайнерів. Завдяки цьому вони можуть самостійно створювати невеликі скрипти, працювати з serverless‑функціями, автоматизувати частину своєї роботи без постійного залучення розробників.
Організаційний ефект тут суттєвий. Нетехнічні співробітники перестають чекати, поки інженер знайде час на дрібні задачі, і можуть реалізовувати ідеї швидше. Інженери, у свою чергу, звільняються від нескінченного потоку дрібних запитів і можуть зосередитися на складніших проблемах.
У такій конфігурації AI‑інструменти не стільки «прискорюють» окремого розробника, скільки змінюють розподіл роботи в команді. Продуктивність зростає не тому, що кожен інженер пише на 50% більше коду, а тому, що частину коду тепер можуть писати люди, які раніше цього взагалі не робили.
Це важливий зсув фокусу. Багато дискусій про AI‑продуктивність концентруються на рівні індивідуального розробника: скільки рядків коду він тепер пише, скільки задач закриває. Але реальний потенціал може полягати в організаційних змінах: хто взагалі має доступ до можливості писати код, як перерозподіляються ролі, де зникають «вузькі місця» в комунікації.
Чому майстерність роботи з AI — це роки практики, а не прочитана книжка
Ще одна важлива теза, яка пролунала в контексті AI‑продуктивності, стосується різниці між теоретичним розумінням моделей і практичною майстерністю їх використання.
Розробник і дослідник Simon Willison, відомий своєю роботою над Django, інструментами для роботи з даними та аналізом prompt‑ін’єкцій, описував власний досвід так: стати справді ефективним користувачем AI‑інструментів — це роки практики. Навіть через два роки активної роботи з моделями він продовжував змінювати свої робочі процеси, відмовлятися від одних підходів і шукати інші. За його словами, «немає мануалу», який би раз і назавжди пояснив, як правильно працювати з AI.
Це добре пояснює, чому невеликі дослідження на кшталт експерименту Meta можуть показувати зниження продуктивності. Більшість учасників перебувають на ранній стадії освоєння інструментів: вони ще не знають, які задачі варто делегувати моделі, як формулювати запити, як будувати цикли «запит — перевірка — уточнення», як інтегрувати AI у свій стек інструментів.
До цього додається ще один нюанс: розуміння теорії роботи моделей не гарантує вміння ефективно їх використовувати. Знання про трансформери, attention‑механізми чи тренувальні датасети саме по собі не робить людину кращим користувачем Claude Code або Copilot. Практичні навички тут ближчі до ремесла: як сформулювати задачу, як розбити її на кроки, як будувати контекст, як швидко відсіювати невдалі відповіді.
Це пояснює й феномен «суперкористувача» в дослідженні Meta. Одна людина змогла отримати значний приріст продуктивності там, де інші втрачали час. Ймовірно, вона вже пройшла частину цього шляху — експериментувала, помилялася, адаптувалася — і змогла побудувати робочий процес, у якому AI справді працює як прискорювач, а не як джерело додаткового навантаження.
У ширшому сенсі це означає, що питання «чи підвищує AI продуктивність розробників?» сьогодні некоректно ставити без уточнення: для кого, на якій стадії освоєння інструментів, у якому контексті, з якими процесами навколо.
Культура, его і готовність відмовлятися від старих підходів
На рівні команд і організацій продуктивність із AI виявляється не лише технічним, а й культурним питанням. Є спостереження, що найбільшу користь від AI отримують ті команди, які мають низький рівень его і готові відмовлятися від попередніх уявлень про «правильну» розробку.
Це проявляється в дрібницях. Команди, які готові визнати, що їхні звичні процеси — від код‑рев’ю до написання тестів — можуть бути не оптимальними в епоху AI, частіше експериментують із новими робочими потоками. Вони не намагаються просто «вкрутити» AI у стару схему, а переосмислюють саму схему: які кроки можна автоматизувати, де AI може взяти на себе чорнову роботу, як змінити розподіл відповідальності.
Натомість команди з високим его — де сильні інженери звикли покладатися на власну експертизу й скептично ставляться до «чорних скриньок» — часто або ігнорують AI, або використовують його поверхово. У таких середовищах AI‑інструменти можуть залишатися чимось на кшталт «розумного автодоповнення», яке не змінює суті процесу й, відповідно, не дає радикального приросту продуктивності.
Це знову повертає до питання вимірювання. Коли компанії намагаються оцінювати «успішність» впровадження AI за непрямими метриками — на кшталт кількості використаних токенів або часу, проведеного в інструменті, — вони ризикують стимулювати поверхневе використання без глибокої перебудови процесів. Історії про «token maxing», коли співробітники штучно наганяють використання AI, запускаючи агентів, що генерують сміттєвий контент, — лише крайній прояв цієї логіки.
Натомість реальний ефект AI‑продуктивності, судячи з наявних прикладів, з’являється там, де керівництво й команди готові до більш болісних змін: перегляду ролей, процесів, очікувань і навіть того, хто взагалі має право писати код.
Висновок: AI‑продуктивність існує, але вона нерівномірна і вимагає чесності
Сукупність історій з Coinbase, Anthropic, Meta та окремих команд малює складну, але послідовну картину.
AI‑інструменти вже сьогодні можуть радикально підвищувати продуктивність окремих розробників і цілих організацій. Є компанії, де значна частина коду пишеться за допомогою моделей, і це стає конкурентною перевагою. Є «суперкористувачі», які завдяки рокам практики й гнучкості мислення витискають із інструментів максимум.
Водночас для середнього інженера, який лише починає працювати з AI, ефект може бути нульовим або навіть негативним у короткостроковій перспективі. Відчуття «я працюю швидше» не завжди збігається з реальними результатами. А спроби керівництва форсувати використання AI через жорсткі вимоги або грубі метрики на кшталт «хто більше витратив токенів» створюють поведінкові викривлення, але не гарантують зростання продуктивності.
Найпереконливіші приклади виграшу сьогодні — там, де AI змінює не лише інструментарій, а й структуру роботи: відкриває можливість писати код нетехнічним колегам, змінює розподіл задач у команді, змушує переглядати процеси. І там, де люди готові інвестувати роки в освоєння нових практик, а не очікують миттєвого «бусту» після підключення чергового плагіна.
Питання «чи робить AI розробників продуктивнішими?» поступово трансформується в інше: «хто саме, за яких умов і за рахунок яких змін стає продуктивнішим завдяки AI?». Відповідь на нього вимагає не лише нових інструментів, а й більшої чесності в тому, як ми вимірюємо й розуміємо власну роботу.
Джерело
How AI is changing Software Engineering: A Conversation with Gergely Orosz, @pragmaticengineer