У розпал буму AI‑інструментів для розробників, коли OpenCode — відкритий «coding harness» від Dax Raad — за менше ніж рік піднявся майже до 10 мільйонів активних користувачів, у тех‑індустрії формується несподіваний консенсус: не всі інженери виграють від цієї революції однаково. У розмові на подкасті The Pragmatic Engineer співзасновник OpenCode окреслює доволі конкретну групу, яка, на його думку, отримає непропорційно велику цінність на ринку: інженери віком приблизно від 24 до 29 років.
Цей «клас 24–29» поєднує дві рідкісні сьогодні якості: фундаментальні інженерні принципи, сформовані ще до масового поширення AI, і готовність працювати з максимальною швидкістю в AI‑прискорених робочих процесах. На їхньому фоні старші фахівці, які не перелаштувалися під AI, і зовсім молоді, які одразу «виросли» на підказках моделей, опиняються в менш вигідній позиції.
«Pre‑AI принципи, post‑AI швидкість»: що це взагалі означає
Формула «pre‑AI principles, post‑AI speed» звучить як слоган, але за нею стоїть доволі конкретна картина еволюції інженерної роботи.
За останні роки інструменти на кшталт OpenCode, Claude Code, GitHub Copilot та інших агентів справді зробили частину ремесла простішою. Рутинне написання коду, генерація шаблонів, рефакторинг, навіть складніші зміни в кодовій базі — усе це тепер можна делегувати моделям. Об’єктивно «stuff has become easier», як формулює це Dax Raad.
І водночас є інша, менш очевидна правда: когнітивне навантаження на сильних інженерів не зменшилося. Вони «думають так само важко, як і раніше», попри те, що багато операційних задач тепер виконує AI. Конкуренти в сегменті AI‑агентів так само не демонструють «космічного відриву» один від одного, хоча всі агресивно використовують ті ж самі моделі.
Цей парадокс і підводить до важливого розрізнення: що саме стало легшим, а що залишилося таким самим складним.
Фундаментальні принципи — розуміння архітектури, інваріантів системи, компромісів між простотою й гнучкістю, досвід побудови продукту від нуля до product‑market fit — не автоматизуються підказками. Вони формуються роками через помилки, реальні продакшн‑інциденти, невдалі фічі, які доводиться підтримувати роками. Це і є «pre‑AI principles» — ментальні моделі, які виникли в епоху, коли інженер не міг «запитати модель» про кожен крок.
«Post‑AI speed» — це інше. Це здатність без сентиментів використовувати сучасні агенти, щоб пришвидшити все, що можна пришвидшити: від прототипування до інтеграцій, від аналізу чужого коду до масових правок. Це не просто «користуватися Copilot», а вибудовувати робочий процес так, щоб AI був вбудованим виконавцем, а не екзотичним гаджетом.
Інженер, який поєднує обидві якості, отримує асиметричну перевагу. Він мислить як «старий світ», але діє зі швидкістю «нового».
Чому саме 24–29: вік як маркер досвіду, а не біології
Прив’язка до віку в діапазоні 24–29 років звучить провокаційно, але тут важливий не паспорт, а траєкторія.
Це покоління встигло:
- почати програмувати й будувати перші продукти ще до того, як AI‑асистенти стали масовими;
- пройти хоча б один цикл реальної розробки: від сирого MVP до більш‑менш стабільного продукту, з усіма супутніми боргами, хаками й «фічами, які доводиться підтримувати вічно»;
- увійти в ринок саме в той момент, коли AI‑інструменти стали достатньо зрілими, щоб їх можна було інтегрувати в щоденну роботу, а не сприймати як експеримент.
Це не означає, що будь‑який 26‑річний інженер автоматично стає «найціннішим активом». Йдеться про когортний ефект: у цьому віковому вікні статистично більше людей, які встигли сформуватися як розробники до AI‑буму, але ще не встигли «застигнути» в старих процесах і готові радикально перебудовувати свій workflow.
Вони пам’ятають, як це — тижнями розбиратися в чужій кодовій базі без допомоги моделей, руками писати складні міграції, самостійно тримати в голові архітектуру системи. І саме тому краще відчувають, де AI справді знімає біль, а де створює ілюзію прогресу.
У цьому сенсі «24–29» — це ярлик для певного типу досвіду:
- достатньо років у продакшн‑розробці, щоб мати власні шрами;
- достатньо гнучкості, щоб не сприймати AI як загрозу чи модну іграшку, а як інструмент.
Старші без AI і молодші без фундаменту: дві групи ризику
Якщо «pre‑AI principles, post‑AI speed» — це ідеал, то хто опиняється в менш вигідній позиції?
Перша група — старші інженери, які так і не перелаштувалися на AI‑орієнтовані процеси. Це не про вік як такий, а про небажання змінювати звички. Люди з великим досвідом, які продовжують писати код, як у 2015‑му, і принципово ігнорують нові інструменти, ризикують опинитися в ситуації, коли їхні ментальні моделі сильні, але швидкість і пропускна здатність — нижчі за ринковий стандарт.
У світі, де один інженер із добре налаштованим AI‑агентом може за тиждень зробити те, що раніше вимагало невеликої команди, «повільний сеньйор» стає дедалі менш привабливим активом. Особливо в компаніях, які вже досягли product‑market fit і борються за темп розвитку, як це зараз робить команда OpenCode.
Друга група — наймолодші розробники, які входять у професію вже в епоху повсюдних AI‑асистентів і ніколи не будували фундамент без них. Для них спокуса делегувати моделі не лише рутину, а й сам процес мислення, особливо велика.
Якщо перші роки кар’єри проходять у режимі «prompt the agent» на кожен запит, є ризик, що глибокі ментальні моделі так і не сформуються. Інженер вчиться не розуміти систему, а керувати інтерфейсом до моделі. На короткій дистанції це може виглядати як висока продуктивність, але на довгій — виявляється вразливістю: складні архітектурні рішення, інтеграція багатьох контекстів, передбачення побічних ефектів змін — усе це вимагає того самого «pre‑AI» мислення.
У результаті на ринку формується трикутник:
- старші з глибокими принципами, але без AI‑швидкості;
- молодші з AI‑швидкістю, але без глибоких принципів;
- і середня когорта, яка встигла отримати і те, й інше.
Саме остання, за логікою Dax Raad, стає «найціннішим активом» — не тому, що краща за всіх у кожному вимірі, а тому, що поєднує рідкісну комбінацію якостей, які ринок зараз особливо цінує.
Як виглядає робота такого інженера в реальних AI‑командах
OpenCode — показовий майданчик для спостереження за тим, як змінюється інженерна робота. Продукт, який позиціонується як «найпопулярніший open source coding harness», за лічені місяці виріс із приблизно 650 тисяч до 2,5 мільйона щомісячних активних користувачів, а потім — до 6,5 мільйона, і зараз наближається до 8 мільйонів MAU та близько мільйона DAU. Команда стартувала як трійка співзасновників плюс один ранній інженер, а до запуску додала дизайнера — тобто це класичний «малий, але дуже швидкий» колектив.
Здавалося б, саме тут AI мав би створити драматичний розрив: компанія, яка будує AI‑агента, використовує його «агресивно» у власній розробці, має доступ до найкращих моделей і глибоке розуміння стеку. Проте реальність виявилася складнішою.
По‑перше, AI не знімає потреби в інженерному судженні щодо того, що взагалі варто будувати. Після досягнення product‑market fit команда OpenCode опинилася в ситуації, коли «є мільйон напрямків, куди можна піти»: очевидні фічі, запити користувачів, рухи конкурентів. З технічного боку, за допомогою агентів можна швидко «пропромптити» майже будь‑яку ідею в код. Але це не означає, що всі ці ідеї варто реалізовувати.
Dax описує класичну пастку AI‑прискорення: коли кожен запит користувача, кожна фіча конкурента й кожна внутрішня ідея миттєво перетворюються на код, продукт швидко перетворюється на «Франкенштейна». Кожна нова можливість вимагає підтримки, взаємодіє з іншими, ускладнює систему. Швидкість розробки без фільтрації ідей не дає кращого продукту — лише складніший.
По‑друге, навіть у середовищі, де всі гравці «супер в AI», немає компанії, яка б «настільки добре використовувала AI, що з нею неможливо конкурувати». У сегменті coding‑агентів, де працює OpenCode, усі конкуренти активно інтегрують моделі, але «величезного розриву» не виникає. Це ще раз підкреслює: вирішальним стає не доступ до моделей як такий, а те, як саме команда мислить про продукт, архітектуру й пріоритизацію.
У такому контексті інженер із «pre‑AI принципами, post‑AI швидкістю» виглядає як ідеальний гравець:
- він здатен самостійно оцінити, які фічі з мільйона можливих варто реалізовувати, а які — ні, розуміючи довгострокову ціну підтримки;
- він може використовувати AI, щоб реалізувати обрані рішення максимально швидко, але не дозволяє швидкості підмінити собою якість мислення;
- він розуміє, що кожен рядок коду — це зобов’язання на роки, навіть якщо цей рядок згенерувала модель.
Це поєднання особливо цінне в компаніях, які вже вийшли з фази експериментів і намагаються масштабувати успіх, не втрачаючи керованості продукту.
Як інженерам різних поколінь адаптуватися до нової реальності
Якщо прийняти тезу про особливу цінність «24–29‑річних з pre‑AI принципами і post‑AI швидкістю», постає практичне питання: що робити тим, хто не потрапляє в цю когорту за віком чи досвідом?
Для старших інженерів ключовий виклик — не дозволити власним сильним сторонам перетворитися на баласт. Глибокі принципи, досвід побудови систем, розуміння організаційної динаміки — усе це залишається критично важливим. Але без готовності інтегрувати AI‑інструменти в щоденну роботу ці переваги можуть виявитися недостатніми в середовищі, де швидкість стає новою нормою.
Практично це означає:
- не делегувати моделям мислення, але делегувати їм рутину;
- будувати власні AI‑орієнтовані робочі процеси, а не чекати, поки їх нав’яже компанія;
- зберігати скепсис до хайпу, але не плутати його з відмовою від інструментів.
Для наймолодших розробників завдання протилежне: не дозволити AI‑асистентам вкрасти у них шанс побудувати фундамент. Якщо перші роки кар’єри проходять у режимі «запитав модель — отримав код», варто свідомо створювати ситуації, де доводиться розбиратися самостійно: читати код без підказок, будувати невеликі системи з нуля, відлагоджувати складні баги вручну.
Інакше є ризик опинитися в ролі «оператора AI», а не інженера, який здатен керувати складними системами.
У цьому сенсі досвід самого Dax Raad показовий. Його шлях — від моддингу Minecraft‑серверів і спілкування з досвідченими програмістами в IRC до стартапів, ролі head of engineering у Ride Health, а потім шести років повноцінної open source‑роботи над SST і OpenNext — це класичний «pre‑AI» маршрут. Саме він створив базу, на якій тепер можна будувати OpenCode як AI‑агента для мільйонів розробників.
Висновок: AI не скасовує інженерію, він змінює її ієрархію
AI‑інструменти для розробників, на кшталт OpenCode, справді змінюють повсякденну роботу інженерів. Вони знімають частину механічної праці, прискорюють реалізацію ідей, дозволяють малим командам досягати масштабів, які раніше вимагали цілих відділів. Але вони не скасовують потребу в глибокому розумінні систем, у здатності робити складні продуктові й архітектурні вибори, у вмінні сказати «ні» зайвій фічі.
На цьому тлі особливо вигідно виглядає інженер, який встиг сформуватися до AI‑буму, але не застряг у минулому й готовий працювати з максимальною швидкістю в новому середовищі. Саме тому «24–29‑річний інженер із pre‑AI принципами і post‑AI швидкістю» сьогодні виглядає як один із найцінніших активів у технологіях.
Решті ринку це сигнал не стільки про вік, скільки про напрямок розвитку. Чим би ви не займалися — будуєте AI‑агента для мільйонів користувачів чи працюєте в невеликому продукті, — завдання одне: зберегти й поглибити фундаментальні ментальні моделі, одночасно безжально автоматизуючи все, що не потребує людського судження.
AI може зробити роботу інженерів легшою й приємнішою. Але хто саме отримає від цього найбільшу вигоду, залежить не від моделей, а від того, як ми вчимося мислити й працювати поруч із ними.