Швидке зростання OpenCode — відкритого «coding harness» для розробників, який за менше ніж рік наблизився до 10 мільйонів активних користувачів, — легко сприймати як доказ того, що ера «важкої» інженерії добігає кінця. Співзасновник OpenCode Дакс Раад шість років працював повний день над open source‑інструментами, а тепер будує один із найпопулярніших AI‑агентів для програмістів. Здавалося б, якщо хтось і має відчути радикальне полегшення роботи завдяки штучному інтелекту, то саме він.
Однак його досвід виявляється парадоксальним: інструменти об’єктивно спростили безліч завдань, але щоденна робота все одно відчувається настільки ж ментально виснажливою, як і раніше. Ба більше, у сегменті AI‑coding‑агентів не видно команд, які б «рознесли» конкурентів завдяки кращому використанню ШІ. Обіцяного драматичного розриву в продуктивності між командами з «правильним» AI‑стеком і всіма іншими поки що не сталося.
Ця невідповідність між очікуваннями й реальністю багато говорить про реальні межі нинішнього AI‑левереджу в розробці ПЗ.
Коли «об’єктивно легше», але суб’єктивно так само важко
Раад описує відчуття, яке сьогодні знайоме багатьом інженерам: інструменти стали потужнішими, рутина — швидшою, але загальне когнітивне навантаження не зменшилося. Він працює з OpenCode щодня, команда «агресивно» використовує власний продукт у всіх робочих процесах. Автодоповнення, генерація коду, рефакторинг, шаблони — усе це справді знімає частину механічної роботи.
Проте ключова теза звучить так: «Я працюю так само важко, як і завжди. Я борюся з тими самими проблемами, з якими боровся раніше». Об’єктивно багато речей стало простішим, але суб’єктивно — думати доводиться не менше.
Причина в тому, що AI‑інструменти в першу чергу пришвидшують виконання вже сформульованих завдань. Вони не відповідають на фундаментальні питання: що саме варто будувати, у якій послідовності, як це вписується в продуктову стратегію, які компроміси прийнятні, а які — ні. Усе це залишається в полі людського мислення.
Раад ділить життєвий цикл компаній на три фази: до product‑market fit, після його досягнення та зрілі компанії з десятирічною історією. У кожній з них AI дає різний ефект, але в жодній не знімає головного навантаження — необхідності ухвалювати складні рішення.
До product‑market fit інструменти на кшталт OpenCode можуть допомогти «махати руками» швидше: швидко збирати прототипи, перевіряти гіпотези, переписувати частини продукту. Але, як підкреслює Раад, значно ефективніше не просто більше «махати», а більше думати. Багато напрямків можна відсікти, не написавши жодного рядка коду, якщо достатньо глибоко проговорити їх у команді. AI не прискорює цю частину роботи.
На стадії після product‑market fit, де зараз перебуває OpenCode, проблема інша: не «що взагалі робити», а «що саме робити з мільйона можливостей». Тут AI знову ж таки полегшує реалізацію, але не вибір.
Коли швидкість стає пасткою: ефект «Франкенштейна»
Після того як OpenCode досяг product‑market fit і почав стрімко зростати — від приблизно 650 тисяч щомісячних активних користувачів у грудні до 2,5 мільйона в січні, 6,5 мільйона за місяць до запису подкасту й очікуваних майже 8 мільйонів у поточному місяці, — команда опинилася в класичній пастці швидкості.
AI‑агент у зв’язці з досвідченою командою створює ілюзію, що будь-яку ідею можна миттєво перетворити на фічу. Є проблема — можна «запромптити» агента. У конкурента з’явилася нова можливість — можна «запромптити» агента й відтворити її. Користувачі просять щось додати — знову ж таки, агент допоможе швидко реалізувати.
Якщо скласти все це разом, виходить продукт, у який за короткий час «вкрутили» сотні чи тисячі можливостей. З погляду метрик розробки це виглядає вражаюче: команда «шипить» у рази більше, ніж раніше. Але з погляду якості продукту результат часто нагадує «Франкенштейна».
Раад прямо описує цю картину: ти відкриваєш власний продукт і розумієш, що частину речей взагалі не варто було випускати. Кожна фіча, щойно вона потрапляє до користувачів, стає боргом, який потрібно обслуговувати. Вона взаємодіє з усіма майбутніми змінами, ускладнює інтерфейс, додає гілки логіки, які треба враховувати.
AI‑прискорення не додає команді «в десять разів більше хороших ідей». Воно лише дає змогу в десять разів швидше матеріалізувати й хороші, і погані. Якщо не змінити сам підхід до відбору, результатом стає не проривна швидкість, а вибух складності.
Це змушує OpenCode, попри репутацію «AI‑турбоінструменту», робити крок назад і свідомо сповільнюватися. Раад говорить про необхідність «сповільнити всіх» і повернутися до практик «старого світу», які все ще мають сенс: обережність у релізах, жорсткий відбір фіч, увага до цілісності продукту. Іншими словами, AI‑інструменти не скасовують потреби в інженерному смаку й продуктовому судженні, а радше підвищують ціну їхньої відсутності.
Відсутній «суперпереможець»: чому AI не створив гігантських розривів
На тлі гучних заяв про те, що AI‑інструменти нібито створюють «10х‑інженерів» і «10х‑компанії», спостереження Рада виглядає особливо показово. OpenCode працює в самому епіцентрі AI‑гонки — у просторі coding‑агентів. Усі основні гравці тут «супер у AI», активно інтегрують моделі, будують складні оркестратори, оптимізують інференс.
Якщо десь і мав би з’явитися гігантський розрив у продуктивності між командами, то саме тут. Але його немає. Раад прямо говорить: жоден із конкурентів не «крушить» OpenCode, і сам OpenCode не відчуває, що «вбиває» інших завдяки кращому використанню ШІ. Усі рухаються приблизно в одному темпі.
Це не означає, що AI‑інструменти марні. Вони вже стали критичною частиною робочих процесів, без якої важко уявити сучасну розробку. Але їхній вплив виявився більш горизонтальним, ніж вертикальним. Вони підняли «базову лінію» продуктивності для всіх, хто їх використовує, замість того щоб дати невеликій групі команд недосяжну перевагу.
У сегменті coding‑агентів це особливо помітно, бо бар’єр доступу до моделей відносно низький. OpenCode свідомо позиціонує себе як відкритий, модель‑нейтральний агент, який працює з усіма основними провайдерами. Конкуренти роблять подібне. У результаті ключові «цеглинки» — LLM‑моделі, інфраструктура інференсу, базові патерни інтеграції — доступні всім гравцям приблизно в однаковій якості.
Там, де немає ексклюзивного доступу до радикально кращих моделей чи унікального стека, перевага визначається не стільки самим фактом використання AI, скільки тим, як саме команди приймають рішення, що будувати поверх цих моделей. А це вже повертає нас до людських факторів: досвіду, розуміння ринку, здатності сказати «ні» зайвим фічам.
Межі AI‑левереджу: коли «щасливіші інженери» — не бізнес‑аргумент
Раад окреслює ще один сценарій, який добре пояснює нинішні межі AI‑левереджу. Уявімо світ, де всі AI‑coding‑інструменти відшліфовані до ідеалу. Вони справді знімають більшість рутинних завдань, пришвидшують написання коду, зменшують кількість помилок. У результаті «той самий обсяг роботи» виконується тим самим числом інженерів, але з меншим стресом і більшим задоволенням від процесу.
Для інженерів це звучить як мрія: робота стає легшою, а якість життя — вищою. Але для багатьох компаній, особливо великих, цього «не достатньо». Якщо інструмент не дає змоги робити більше за ті самі гроші або те саме — за менші, його важко обґрунтувати як стратегічну інвестицію.
У цьому й полягає ключове напруження: AI‑інструменти вже можуть зробити інженерну роботу комфортнішою, але далеко не завжди конвертуються в очевидну бізнес‑перевагу. Якщо «нетто‑результат» — той самий обсяг фіч, випущених за квартал, але з меншим вигоранням команди, — це радше гуманістичний, ніж фінансовий аргумент.
Багато керівників, особливо hands‑on CEO та CTO, мислять інакше. Вони пам’ятають, як багато часу раніше займало «ручне» кодування, і логічно припускають: якщо цю частину прискорити, то й уся розробка має пришвидшитися. Але, як показує досвід OpenCode, вузьке місце часто зміщується в інші зони: постановку задач, узгодження пріоритетів, дизайн систем, підтримку зростаючої складності.
AI‑інструменти не усувають цих вузьких місць. Навпаки, іноді вони загострюють їх, дозволяючи надто швидко нарощувати складність продукту. У підсумку очікуваний «драматичний розгін» перетворюється на більш тонкий ефект: інженери менше страждають від рутини, але не обов’язково створюють більше цінності для бізнесу.
Чому «AI‑перевага» виявилася меншою, ніж очікували
Історія OpenCode — це не історія провалу AI‑обіцянок. Це історія корекції очікувань. Інструмент, який за лічені місяці виріс до мільйонів користувачів і став, за описом, «найпопулярнішим open source coding harness», безумовно, змінює повсякденну роботу розробників. Але він не перетворює інженерію на щось просте чи тривіальне.
Є кілька причин, чому «AI‑революція» в розробці поки що виглядає більше еволюцією.
По‑перше, інженерія — це не лише написання коду. Це вибір архітектури, розуміння домену, управління технічним боргом, баланс між швидкістю й надійністю. AI‑агенти добре працюють там, де завдання вже сформульоване, але не там, де його ще потрібно осмислити.
По‑друге, доступ до моделей і базових патернів інтеграції став масовим. У сегменті coding‑агентів немає «секретної зброї», яка була б доступна лише одній команді. Це знижує шанси на появу «суперпереможця», який завдяки AI відірветься від усіх інших.
По‑третє, швидкість реалізації без зміни якості рішень може навіть погіршити ситуацію. Якщо команда не встигає осмислювати наслідки кожної фічі, продукт швидко обростає несумісними елементами, які важко підтримувати. У такому середовищі AI лише прискорює рух до хаосу.
По‑четверте, бізнес‑логіка багатьох компаній вимагає не просто «щасливіших інженерів», а вимірюваного зростання продуктивності. Поки AI‑інструменти не демонструють стабільного ефекту масштабу — наприклад, можливості робити вдвічі більше релізів без втрати якості, — їхній вплив сприймається як важливий, але не визначальний.
Усе це не означає, що AI‑coding‑агенти не змінять інженерію глибше в майбутньому. Але сьогодні, на практиці, вони радше перерозподіляють навантаження, ніж радикально його зменшують.
Висновок: AI як фон, а не магічний мультиплікатор
Досвід OpenCode і Дакса Рада пропонує тверезий погляд на те, як AI реально вписується в сучасну розробку. Так, інструменти на кшталт OpenCode вже стали фоном повсякденної роботи інженерів. Вони знімають частину болю, прискорюють рутину, дають змогу менше часу проводити в «механічному» режимі.
Але вони не скасовують потреби думати. Не усувають необхідності робити складний вибір між можливостями. Не гарантують, що команда, яка «найкраще використовує AI», автоматично стане ринковим лідером. І не перетворюють інженерію на професію, де можна розслабитися й працювати «у півсили».
Навпаки, у світі, де AI‑інструменти доступні всім, конкурентні переваги знову зміщуються в зону людських рішень: як саме команди структурують роботу, які ідеї відсікають, як борються зі спокусою «зашипити ще одну фічу», просто тому що це стало легше, ніж будь‑коли.
Парадокс у тому, що чим кращими стають інструменти, тим дорожчими стають помилки судження. І поки що саме це, а не відсутність достатньо розумних моделей, заважає AI‑coding‑агентам перетворити інженерію на щось «драматично легше».
Джерело
Building OpenCode with Dax Raad — The Pragmatic Engineer Podcast