Розробка ПЗ у нову епоху: агенти, ролі та трансформація команд

Зміна індустрії розробки

Коли основний обсяг коду починають писати не люди, а агенти, це кардинально впливає на структуру великих організацій. Історично цифрові компанії будувалися як конвеєр створення цінності, поділений на дві великі частини:

Discovery — визначення того, що робити (продукт-менеджери, аналітики);
Delivery — реалізація рішення, виведення на продакшн та подальша підтримка.

Індустрія прийшла до моделі стрім-команд і платформених команд (за концепцією Team Topologies), де кожна стрім-команда мала «по одній тварі кожної професії» — фронтенд- та бекенд-розробників, QA-інженерів, аналітиків тощо, щоб автономно доставляти зміни.

Коли код значною мірою пишуть агенти, з'ясовується, що окремі вузькоспеціалізовані посади (фронтенд, бекенд, QA-інженери, які пишуть автотести, аналітики, що транслюють бачення продукт-менеджерів у специфікації) стають менш потрібними як окремі штатні одиниці. Команду з 10–15 людей теоретично можна суттєво скоротити, вмістивши необхідні ролі в меншу кількість людей, підсилених агентами.

Перехідний період: асистенти vs агенти

У попередній фазі (умовно 2025 рік), коли ще не було повноцінних агентів, а були асистенти, кожен спеціаліст просто прискорював свій власний етап роботи за допомогою чат-помічників: аналітики генерували вимоги, інженери — коментарі й код. Проблема була в тому, що робота накопичувалась на кожному етапі, але до фінального результату (продакшену) доїжджало відносно мало — передача роботи між ролями залишалася вузьким місцем.

Справжня зміна настає, коли ставиться мета не пришвидшити кожен окремий етап, а скоротити саму кількість передач роботи між людьми — тобто дати змогу меншій кількості людей закривати більше ролей самостійно за допомогою агентів. У стартапах це вже природно відбувається, бо там і так немає жорстких процесів. У корпораціях же це складний шлях, оскільки там історично склалися окремі посади, прив'язані до конкретних етапів конвеєра (за аналогією з тейлоризмом і конвеєром Форда), і люди звикли відповідати саме за свою ділянку.

Які ролі залишаються потрібними

Не самі ролі зникають — зникає потреба мати під кожну роль окрему штатну посаду. Цільова модель команди виглядає приблизно так:

людина, що відповідає за Discovery (продуктовий напрямок): формулює інтенти, гіпотези, за допомогою агента збирає прототипи;
людина (або кілька), що відповідає за Delivery: перетворює інтент на специфікації, код, pull request, код-рев'ю, тести, доводить до продакшену;
люди, що відповідають за operations/підтримку, щоб не всі проблеми з продакшену напряму падали на команду розробки.

Окремих штатних QA-інженерів, аналітиків та інших вузьких спеціалістів на цій цільовій картинці немає — їхні компетенції закриває правильно налаштований агент.

Ідеальна (цільова) модель команди

Описується гіпотетична «плоска» модель: продакт-менеджер, підсилений агентом, формулює гіпотези й навіть збирає прототипи самостійно; продуктовий інженер (теж підсилений агентом) бере це і доводить від інтенту до продакшену, враховуючи всі наскрізні (горизонтальні) вимоги — безпеку, надійність, відповідність регламентам компанії тощо.

Ключова умова, щоб це працювало: усі горизонтальні вимоги (безпека, надійність, юридичні, брендові тощо) мають бути екстерналізовані у вигляді політик (policy as code) — доступні агенту через скіли на етапі проєктування вимог, а не перевірятися постфактум людьми-ревьюерами, коли pull request уже готовий і його «на два тижні» відправляють на перевірку безпеки. Ідеал — щоб ці політики застосовувались ще у внутрішньому циклі розробки фічі, а до продакшену вели автоматичні гейти без ручних затримок.

Проте автор чесно визнає: це «магічний світ», до якого дійти надзвичайно складно.

Вайб-кодинг проти AI-native інжинірингу

Ключове розмежування — між вайб-кодингом і повноцінним AI-native інжинірингом. Правильний підхід поєднує:

Policy as code — рекомендації та правила, оформлені як скіли, які застосовує агент;
Набір детермінованих перевірок, через які має пройти кожна зміна.

На практиці кількість детермінованих перевірок у проєкті постійно зростає: щоразу, коли виникає нова проблема, додається ще одна автоматична перевірка — з часом їх накопичуються десятки.

Проєктування архітектури під нову модель

Стартуючи проєкт з нуля, важливо чітко визначити для себе:

яку метрику ви оптимізуєте (наприклад, готовність пояснювати агенту завдання один раз, але небажання пояснювати одне й те саме багато разів);
потребу в self-healing архітектурі — проблеми мають виявлятися на етапі внесення змін, а не на етапі експлуатації;
що інкремент можна перевірити руками, а регрес — ні, тому регрес має перевірятися максимально автоматично;
який профіль змін стандартний (наприклад, типовий контент), а який — нестандартний (масштабний рефакторинг), і оптимізувати архітектуру насамперед під стандартний потік, свідомо не вкладаючись у пришвидшення рідкісних нестандартних випадків.

Відповівши собі на ці питання, технічний керівник/архітектор може чітко спроєктувати процес, архітектуру та інфраструктуру під нову реальність. Проблема в тому, що більшість існуючих (brownfield) проєктів спроєктовані під зовсім іншу метрику, тож впровадження ШІ в такі процеси тягне за собою величезний шлейф необхідних змін.

Як це влаштовано у великих компаніях

Платформа vs бізнес-вертикалі

У великих організаціях (банки, інші технологічні компанії) типово існує дуалізм:

Платформена інженерія надає загальні інструменти:

Model Gateway — єдина точка доступу до різних моделей (внутрішніх і зовнішніх), керування квотами тощо;
MCP Hub — каталог доступних API/можливостей для агентів;
Skill Hub — сховище перевірених скілів зі спільним доступом;
інфраструктура для сендбоксингу запуску агентних задач (не лише на комп'ютері користувача).

Ключова проблема платформених команд — їхні інтерфейси історично оптимізувалися під графічний користувацький інтерфейс, а не під агента. Коли API просто «виставляють» через MCP без переосмислення, вони виявляються надто вербозними чи занадто дрібно нарізаними — агенту доводиться робити величезну кількість викликів, щоб зібрати потрібну інформацію.

Бізнес-вертикалі (інвестиції, банк для юросіб, банк для фізосіб, мобільний зв'язок тощо) — це фактично окремі великі організації всередині компанії, які самі відповідають за власні продуктові процеси. У них подвійне навантаження:

Перебудова власних процесів розробки (склад команд може бути дуже різним — десь уже є продуктові інженери, а десь досі довгий ланцюжок: продакт → бізнес-аналітик → системний аналітик → кілька рівнів інженерів → автотестувальник → мануальний тестувальник);
Взаємодія з платформеними командами за доступ до інструментів.

Нерівномірний розподіл можливостей

У великій компанії швидкі й ініціативні команди можуть отримати пілотний доступ до найкращих (SOTA) інструментів в обмін на обіцянку продемонструвати результат. Менш ініціативні команди залишаються на стандартних, менш просунутих можливостях платформи. У результаті виникає ефект «майбутнє вже настало, просто розподілене нерівномірно»: є окремі яскраві приклади (наприклад, команда, яка отримала підписку на Claude замість стандартних ресурсів і побудувала процес на базі інтентів і специфікацій, суттєво прискоривши розробку меншою командою), але в середньому по компанії суперефекту може й не спостерігатися — сусідні команди, що не отримали таких умов і не мали «гринфілдної» терміновості, просто спрямовують вивільнений час на технічний борг, і бізнес не бачить очевидного впровадження ШІ.

Хто має рухати зміни процесів

Виникає питання: чи потрібна окрема людина/команда, задача якої — не пиляти фічі, а спеціально вдосконалювати сам процес розробки, ставити гейти, впроваджувати практики (щось на кшталт ролі «власника workflow»). У великих бізнес-вертикалях (масштабу тисячі інженерів) зазвичай уже є власні централізовані платформені функції (надійність, продуктивність тощо) — і додати туди людину, відповідальну саме за трансформацію процесів розробки, не є великою проблемою, якщо вдається знайти достатньо кваліфікованих людей.

Реальна складність — не в наявності заряджених ентузіастів у окремих вертикалях (вони, як правило, є й успішно щось змінюють), а в масштабуванні цих напрацювань на всю компанію. Типовий сценарій:

сильна бізнес-вертикаль домовляється собі про особливі умови, які неможливо поширити на всю компанію;
вона випереджає централізовану функцію безпеки/платформи у своїх напрацюваннях;
спроба поширити ці напрацювання на всіх наштовхується на централізовані вимоги, які були пом'якшені для пілоту, але не адаптовані для масштабування;
виникає замкнене коло: команда безпеки вимагає відповідності стандартам (наприклад, ще не реалізованим специфікаціям для MCP, запланованим на далеке майбутнє), і формальна вимога «має бути безпечно» починає домінувати над практичною метою «має працювати».

Ця напруга між швидкістю впровадження окремих команд і централізованими вимогами безпеки/відповідності є однією з ключових перешкод для рівномірного масштабування ШІ-трансформації в масштабах великої корпорації.

Спеціалізація ролей у розробці: чи повертаємось ми назад?

Парадокс фулстек-розробників

Індустрія роками наполягала на глибокій спеціалізації — фронтенд-розробники, бекенд-розробники, кожен домен вважався окремою складною дисципліною, яка вимагає власного набору навичок. І раптом усі почали говорити протилежне: «нам потрібні фулстеки, всі мають бути універсальними». Це виглядає як колективна відмова від усього, що індустрія стверджувала раніше.

Пояснення лежить у теорії менеджменту: питання насправді звучить не «яка спеціалізація правильна», а під яку метрику ми оптимізуємо виробничу систему.

Чому спеціалізація виникла історично

Поділ праці на етапи (конвеєр) був вигідний, коли:

кожен етап вимагав різних, доволі складних навичок;
спеціалізація дозволяла здешевити виробництво та підвищити пропускну спроможність, не збільшуючи кількість людей — за аналогією з класичною економічною ідеєю порівняльної переваги (навіть якщо один працівник робить усе краще за іншого, вигідніше розподілити задачі за відносною перевагою кожного).

Складність кожного домену з часом штучно нарощувалась: фронтенд перетворився на повноцінний «десктопний застосунок у браузері» зі своїм станом і динамікою, бекенд і мобільна розробка проходили той самий шлях ускладнення. У підсумку виник конвеєр, де кожен етап вимагав окремої професії, а робота передавалася між ними.

Дисфункція передачі роботи

Проблема конвеєра — координація на стиках. Показовий приклад: доповідь, де для реалізації однієї фічі потрібно було координувати чотири команди, — це не про архітектуру, а про дисфункцію організації праці. Причина в тому, що вся складність задачі не вміщалася в голову однієї людини (а якщо вміщалася — така людина ставала «золотою» і небезпечним bus-фактором). Рішенням стало розділення на етапи, щоб інженери всередині свого етапу давали передбачуваний, повторюваний результат.

Як агенти змінюють розрахунок

Агенти навчені на всьому публічному коді, величезній кількості синтетичних даних і задачах з reinforcement learning — вони здатні писати і фронтенд, і бекенд, і будь-що інше однаково компетентно. Це перетворює їх на своєрідний «великий вирівнювач»: тип задачі стає менш важливим, ніж уміння правильно її сформулювати й перевірити результат.

Якщо в людини є фундаментальні інженерні навички та розуміння домену, вона з агентом може закрити і фронтенд, і бекенд, занурюючись у деталі за потреби. Це фактично повернення до моделі «staff/principal-інженера» — суперкваліфікованого фахівця, який вирішував задачу, а не ідентифікував себе як «Java-розробника» чи «JS-розробника», і завдяки авторитету міг залучити команду до делегування рішення.

Різниця в тому, що тепер поріг входу в таку роль різко знижується: очікується, що навіть продуктовий інженер-початківець (умовно, з рівня джуна) зможе працювати з агентом у такому ж форматі — ближче до продуктового бачення, ніж до вузької технічної спеціалізації.

Design review замість code review

У сильних інженерних компаніях існувала практика: код-рев'ю менш цінне, ніж дизайн-рев'ю — обговорення того, що і навіщо ми хочемо зробити, ще до написання коду. Раніше дизайн-рев'ю робили лише для великих, «дорогих» (one-way door) рішень: команда фіксувала компроміси в лозі архітектурних рішень (Architecture Decision Record), рецензенти погоджували вибір із доступних опцій.

Тепер із агентами цю практику стало набагато простіше застосовувати на рівні окремої задачі:

є інтент від продуктової людини;
є написані специфікації (PRD);
є план, який пропонує агент і який рев'юється людиною;
агент пише код за планом;
людина перевіряє готовність результату відповідно до критеріїв приймання.

Для тих, кому важливий саме результат, а не сам процес написання коду, — це благо: вони можуть охопити більше. Але частина інженерів, орієнтованих саме на стан потоку («flow») під час написання коду, втрачає звичний спосіб роботи, бо нові моделі працюють асинхронно: ти ставиш задачу — і переключаєшся на щось інше, поки агент виконує роботу.

Чому попереднє узгодження вимог критично важливе

Дослідження інтерактивних бенчмарків (від дослідницьких команд, що вивчали, як агенти працюють у режимі часткового розкриття інформації та уточнення вимог на льоту) показало: інтерактивний режим, коли людина підправляє агента в процесі та докидує вимоги по ходу, драматично знижує якість розв'язання задачі. Це підтверджує підхід Spec-Driven Development: моделі працюють значно краще, коли всі вимоги розкладені й узгоджені заздалегідь (специфікації відрев'юєні на відповідність тому, що потрібно), а вже потім агент автономно виконує задачу та перевіряє критерії приймання наприкінці.

Особистий досвід: спрощення важких процесів

Практики, які раніше вважалися «важким ентерпрайзним оверхедом» (RFC, ADR, документування рішень, обговорення компромісів) і були недоступні для маленької команди, завдяки агентам стали простими, природними й автоматизованими. Приклад: перетворення Local-First застосунку на мультитенантну систему за допомогою агента — проходження через «візард» уточнюючих питань дало ADR такої якості, на написання якого раніше пішов би тиждень, ще два тижні пояснень команді та цілий квартал очікування реалізації. Натомість робочий прототип був готовий за день.

Ключовий висновок: коли ти детально розумієшся на предметній області, ти можеш сформулювати архітектурні компроміси мовою домену — і це різко підсилює якість роботи з агентом. Якщо ж домену не знаєш — отримуєш лише узагальнену («дженерик») відповідь.

Доменна експертиза важливіша за інженерну

Дослідження в галузі (зокрема огляд літератури про стан ШІ в архітектурі, а також матеріали від Anthropic) підтверджують: під час делегування задачі агенту рівень доменної експертизи часто важливіший за рівень софтверної інженерії. «Супербухгалтер», що не є інженером, може отримати кращий результат від агента у своїй сфері, ніж «суперінженер», який не розбирається в бухгалтерії.

Термінологія як інструмент підсилення агента

Пряме практичне спостереження: якщо в проєкті історично склалася неоднорідна або застаріла термінологія (наприклад, в освітньому проєкті частина понять іменувалася не так, як прийнято в індустрії), агент без підказки не робить правильних висновків. Рішення — привести внутрішню термінологію у відповідність до загальноприйнятої в домені: з'ясувати в агента, як певний процес називається в індустрії (наприклад, «admission» для процесу вступу), і провести рефакторинг перейменування. Це не просто косметика: коли агент бачить термінологію, на якій він навчався, він видає значно якісніші висновки та рекомендації.

Проблема кастомних платформ у великих компаніях

Чому open source «не витримує» масштабу біг-техів

Великі компанії традиційно стикалися з тим, що популярні open-source-інструменти (черги повідомлень, месенджери для внутрішньої комунікації, ноутбуки для аналітиків) розвалювались на масштабі десятків тисяч користувачів. Типовий шлях вирішення:

Спроба взяти готовий open source.
Спроба законтриб'ютити свої зміни в апстрім — відхилено, бо масштаб і вимоги занадто специфічні й ускладнюють архітектуру для всіх інших.
Форк і доопрацювання «напильником» під власні потреби.
У процесі доопрацювання з'являється спокуса зробити продукт «краще» за задумом власних продакт-менеджерів (частково через бажання продемонструвати креативність і виправдати свою роль/грейд).

У результаті компанія отримує не просто масштабування й потрібні корпоративні фічі, а фактично нову, несумісну з апстрімом поверхню — власну кастомну платформу.

Як агенти перетворюють цей актив на пасив

Раніше кастомізовані внутрішні платформи були конкурентною перевагою — активом, що дозволяв заощаджувати на масштабі. Тепер це стає пасивом: агенти чудово навчені працювати зі стандартними open-source-рішеннями «з коробки», але не знають специфічних локальних особливостей кастомної платформи компанії. Щоб агент запрацював з такою платформою, доводиться:

або згодовувати йому величезний обсяг контексту про локальні особливості (що працює гірше, ніж навчання моделі на цьому інструменті під час претрейну);
або наближати внутрішню платформу назад до сумісності за інтерфейсом з апстрімним рішенням, щоб агенти могли працювати з нею «з коробки», без надлишкового контексту.

Цей самий принцип — «занадто дорого робити кастомні рішення» — підтверджується й практикою: замість підтримувати власні патчі, вигідніше віддавати фікси в апстрім через pull request'и (що, до речі, стало значно простішим завдяки агентам — щоденні PR у сторонні проєкти замість накопичення локальних «костомчиків»).

Аналогія з гуманоїдними роботами

Показова паралель: гуманоїдні роботи актуальні саме тому, що виробничі середовища історично спроєктовані під людину — компанії вклали мільярди в автоматизацію конвеєра, роборуки закривають частину етапів, а решту досі виконують люди. Замість повного перепроєктування лінії (що дорого) простіше «замінити людину роботом» у тому самому середовищі. Якби виробництво проєктувалося з нуля (greenfield), гуманоїдна форма, ймовірно, не знадобилася б — можна було б обрати колісні платформи та інакше розташовані маніпулятори. Так само й із внутрішніми ІТ-платформами: середовище історично «спроєктоване під людину», і повне перепроєктування під агента коштує дорого.

Майбутнє баз знань

Постає питання: чи збережуться традиційні корпоративні бази знань (Confluence, Jira тощо), чи все перейде в Git/репозиторій як єдине джерело істини (у дусі Spec-Driven Development). Ключовий фактор — хто саме користується цими знаннями. У великих компаніях процеси роботи з вимогами історично залучають велику кількість ролей поза інженерією: топ-менеджерів, продуктових менеджерів, дизайнерів, аналітиків різних напрямків (бізнесових, системних, кількісних, ризикових), а також підтримку та QA. Це і визначає, чому Wiki/Jira залишаються зручними для широкого кола нетехнічних користувачів, тоді як перехід джерела істини безпосередньо в репозиторій демонструє чудові результати там, де з ним працюють переважно технічні команди.

Досвід трансформації бази знань у великій організації

У мобільному банку існувала практика писати вимоги на нову версію продукту, повністю копіюючи опис попередньої, з переліком екранів і специфікацій. Реально цей текст ніхто не читав — окрім саппорту, якому потрібно було зрозуміти, що змінилось. Показова ситуація: технічний директор, спробувавши розібратися в описі головного екрана, побачив документ обсягом у «50 прокруток», написаний настільки деталізовано, що зрозуміти концепцію було неможливо. Це класичний Стокгольмський синдром документації — люди, які роками з нею працювали, звикли, а ті, хто мали читати, читали, решта просто ігнорували.

Продуктові менеджери й дизайнери натомість повністю жили у Figma зі сценаріями, а вимоги для розробки перетворювались на «потворність» окремим шаром.

Було ухвалено рішення перейти від опису вимог по екранах до опису по фічах, щоб документація стала зрозумілою ширшому колу людей, а не лише вибраним продуктовим і дизайнерам. Ключові спостереження з цього досвіду:

Зміну процесу роботи з інформацією в великій організації реалізовував не сам ініціатор, а знайдений «суперналітик», який очолив трансформацію і планомірно вів її два роки.
Компанія в результаті не «переїхала» з Wiki — фактично змінили структуру всередині того самого інструменту (від екранів до фіч, де екрани стали похідними від набору задач).
Паралельний експеримент — переведення управління конфігураціями через GitOps і змушування аналітиків працювати в Git — виявився надзвичайно складним навіть за наявності влади й відповідальності в ініціатора.

Чому глобальний перехід «усі в Git» неможливий у корпорації

Уявити, що велика компанія (десятки тисяч співробітників) відмовляється від Jira/Confluence/Wiki на користь єдиного репозиторію-джерела істини, складно. Реалістичніший сценарій — побудова внутрішнього «перплексіті»: системи, що індексує всі наявні джерела (Wiki, GitLab Pages, Git тощо), має повнотекстовий і семантичний пошук, векторну базу і генеративну частину для відповідей.

Проблема такого внутрішнього пошуку — відсутність фідбек-лупа. На відміну від публічних пошукових систем, де онлайн-метрики використання дозволяють постійно покращувати релевантність, у корпоративному масштабі (навіть на десятки тисяч користувачів) немає достатньо сигналу, щоб зрозуміти, яка відповідь дійсно релевантна. Приклад: запит про ІТ-стратегію компанії видає топ-5 фрагментів — інтерпретацій різних бізнес-напрямків, бо оригінальний загальний документ переглядали рідко, а локальні версії різних команд індексуються вище через частіші перегляди.

Висновок: у великій організації людську поведінку часто змінити неможливо, тому проблему намагаються вирішити технічно — так, щоб агенти отримували потрібний їм контекст, і це стає базовим рівнем (baseline). Далі найзацікавленіші люди адоптують нові підходи, і через «сарафанне радіо» («у нас так працює краще») ці практики поширюються за кривою дифузії інновацій (Roger's adoption curve).

Позиція вендорів (Atlassian тощо)

Вендори на кшталт Atlassian усвідомлюють загрозу і намагаються перепозиціонувати себе не просто як зберігачів документації, а як зберігачів робочих workflow і знань, які потім можна віддавати агентам. За кордоном молодші, гнучкіші команди тяжіють до інструментів на кшталт Linear, які легше підлаштувати під себе, не прив'язуючись до «монстра». В Росії ситуація ще специфічніша через обмежений доступ до хмарних версій Atlassian і використання застарілих локальних інсталяцій усупереч ліцензійним обмеженням — тому саме на цьому ринку локальні вендори, ймовірно, втратять позиції, тоді як за кордоном попереду ще справжня битва за vendor lock-in.

Метрики впровадження ШІ: трирівнева модель

Рівень 1: Використання та проникнення технології

Перший крок — подивитися на метрики використання: чи взагалі люди користуються виданими їм інструментами, і в яких сценаріях агенти автоматично виконують роботу (код-рев'ю, виправлення багів тощо), скільки роботи вони покривають. Кількість згенерованого коду як метрика визнана такою ж непридатною, як колись Lines of Code — вона збиває з пантелику. Але сам факт відхилень у використанні (частина організації не користується інструментами) — корисний сигнал для подальшого розслідування причин.

Рівень 2: Вимірювання часу на джоби (за прикладом Google)

Google ще у 2019 році побудував систему Measuring Developer Goals: для інженерів створили аналог customer journey map — набір типових «джобів» (створення сервісу, прийняття архітектурного рішення, код-рев'ю чужого коду, усунення інциденту тощо) і виміряли, скільки часу витрачається на кожен.

Методологія:

Збір логів з різних інструментів.
Перетворення логів у події.
Злиття подій у сесії.
Прив'язка сесій до типу роботи (ідентифікатор задачі/інциденту) і артефакту (код, merge request).
Побудова метрик відносно цих даних.

Це дозволяє бачити, як зміни в платформних інструментах впливають на час виконання конкретного джоба — наприклад, наскільки швидше проходить весь шлях від заведення репозиторію та узгодження прав доступу до деплою нового сервісу на продакшн.

Проблема інструменталізації: у власному досвіді автора спроба виміряти прискорення від агента показала ефект лише на етапі «від ідеї до першого merge request», але не далі — на етапі доопрацювання за коментарями. Виміряти повний шлях «від інтенту до деплою» не вдалося, оскільки команда, на відміну від Google, не збирала дані про момент початку роботи над задачею.

Рівень 3: Економіка

Третій рівень — спроба замкнути економіку: порахувати заощаджений час на джобах і зіставити з витратами на платформену команду, інструменталізацію та токени. Важливий нюанс: зекономлений час автоматично не конвертується в ефект — робота, як газ, займає весь доступний час; звільнений час людина може витратити на щось, що не приносить бізнес-цінності.

Альтернативний, спрощений шлях розрахунку економіки — метрики потоку (throughput команди, time-to-market, lead time / cycle time). Приклад із Meta: контрольовані експерименти з поетапним впровадженням автоматизації тестування (для старих проєктів) і посилення типізації (у тестовому коді на Hack) — прокатили зміну на частині проєктів, порівняли з контрольною групою і виміряли реальне прискорення (10–15%).

Пастка зростання пропускної здатності без розширення Discovery

Якщо throughput команди зростає (наприклад, на 20%), але при цьому не розширюється воронка Discovery (пошук і опрацювання нових цінних задач), то за законом спадної корисності додаткові задачі виявляються менш цінними за попередні. Команда «вигрібає» бэклог, включно з nice-to-have і технічними задачами, а бізнес каже: «ми й без цих задач жили нормально». Розповідається особистий приклад: компанія прискорила розбір накопиченого роками беклогу, і продуктові команди з подивом виявили, що встигають розвантажувати задачі швидше, ніж встигають придумувати нові цінні ідеї — черга на генерацію ідей (Discovery) стала вузьким місцем замість реалізації (Delivery).

Метрики як інструмент управлінської аргументації

Наявність інструменталізації й метрик дозволяє говорити мовою цифр із людьми, які інакше кажуть «у мене й так усе працює, я змінюватися не буду». Показавши, що сусідня команда після зміни підходів працює ефективніше, отримуєш сильний аргумент для масштабних організаційних змін. Особистий приклад невдачі: спроба переконати керівництво інвестувати в систему інструменталізації роботи інженерів була відхилена як «занадто академічна» на тлі майбутніх великих організаційних змін — і залишається невідомим, чи вдалося б передати цю історію по-іншому.

Чи знадобляться фахівці з «нижнього рівня» знань у майбутньому

Порушується питання: індустрія вже певний час перебуває в режимі скорочень і обмеженого найму (частково через економічні причини, частково підсилено впровадженням ШІ), але цей стан колись зміниться — прийде приплив нових людей, знадобиться навчати новачків. Постає питання про деградацію фундаментальних знань: чи зможуть люди без глибокого розуміння «нижнього рівня» (наприклад, статистичних методів прогнозування) працювати на тому ж рівні, що досвідчені фахівці з 10–15-річним стажем.

Відповідь через призму невизначеності й «парі Паскаля»

Однозначної відповіді бути не може, оскільки на операційні й стратегічні міркування накладається невизначеність щодо наближення технологічної сингулярності — чи з'явиться суперінтелект і як він узгодиться з намірами людства (згадується книга Еліезера Юдковського «Якщо хтось це побудує, ми всі помремо», а також його твір «Гаррі Поттер і методи раціонального мислення»).

Пропонується підхід за аналогією до парі Паскаля: незалежно від того, настане технологічна сингулярність чи ні, раціональніше діяти проактивно вже зараз, а не «сидіти склавши руки» в очікуванні.

Стратегія виділення на конкурентному ринку праці

У капіталістичному суспільстві критично важливо розуміти, за рахунок чого виділятися на фоні інших. Якщо праця людини як товар нічим не відрізняється від праці інших — вона потрапляє в «кровопролитну» зону досконалої конкуренції з мінімальними ставками (аналогія — водії у шерингових економіках на кшталт Убера, де байдуже, хто саме виконує роботу). Одна з можливих стратегій виділення — вміти робити з агентом щось краще за інших.

Витікаючі абстракції та особиста стратегія диференціації

Ключова технічна теза: будь-яку проблему можна розв'язати додатковим рівнем абстракції, окрім проблеми надмірної кількості самих абстракцій. Але абстракції завжди течуть («leaky abstractions»): коли агент не справився із завданням, є два шляхи — спробувати ще раз і сподіватися, що вийде, або зазирнути під капот, прочитати помилки та подебажити самостійно.

Якщо колись з'явиться справжній суперінтелект, він, імовірно, впорається сам — і тоді незрозуміло, яка роль залишається людині в цьому процесі. Якщо ж сингулярність не настане найближчим часом, здатність розбиратися в деталях під абстракцією стає точкою диференціації відносно інших фахівців.

Два напрямки диференціації

Рух «вниз» від абстракції — розуміти, як усе працює під капотом, вміти дебажити, коли інструмент не впорався.
Рух «вгору» від абстракції — навчитися користуватися інструментом настільки ефективно, що робота виконується вдвічі швидше чи якісніше, а коли щось не працює, просто залучати спеціаліста, який закриє прогалину. Саме так часто діють продакти: швидко перевіряють ідеї, запускають їх, а потрібні технічні деталі делегують комусь іншому.

Важливо чесно відповісти собі, за рахунок чого саме ви хочете вирізнятися. Особисто ближче перший шлях — цікавість до того, як влаштований світ, змалку тягнула до природничих наук, математики, фізики, хімії, тоді як взаємодія з людьми (емпатія, розуміння емоцій) давалася важче, ніж раціональний аналіз систем. Ця схильність глибоко розбиратися допомагає краще передбачати тенденції: розуміючи взаємозв'язки між шарами системи (агентські обв'язки, моделі, інфраструктура, вузькі місця), можна побачити, чому певне архітектурне рішення «вистрелило», навіть якщо в його основі лежить ідея, якій уже 50 років. Для людини на позиції візіонера чи технічного топ-менеджера здатність бачити далі за інших — це не розкіш, а професійний обов'язок: потрібно «дивитися туди, де шайба буде», а не туди, де вона зараз.

Як міняється робота з джуніорами в епоху агентів

Стара модель найму та навчання

Раніше джуни отримували задачі рівня багфіксів чи простих фіч, виконували їх самостійно, і за готовим артефактом (успішний прогін тестів, полагоджений баг) можна було судити, що людина справді щось зрозуміла в процесі.

Чому ця модель ламається

З агентами артефакт може бути готовий, а розуміння — відсутнім. Тому, якщо компанія хоче вирощувати повноцінних інженерів, підхід має змінитися:

Маленькі баги й фічі варто закривати через луп інженерингу — нехай їх лагодить агент, а не джун вручну.
Джунам варто давати задачі більшого масштабу, які вони можуть подужати разом з агентом.
На виході потрібно перевіряти не сам факт готовності фічі, а як людина взаємодіяла з агентом: чи вміла специфікувати задачу, ставити критерії приймання, оцінювати запропоновані агентом рішення.
Варто перевіряти, чому людина навчилася: чи може вона пояснити, як фіча влаштована і чому вирішує вихідну проблему, а не просто передати готовий пул-реквест, зроблений агентом.

Це потрібний дизайн процесу, якщо мета — не просто закривати задачі, а розвивати компетенції співробітників, оскільки за зміни, що потрапили в продакшн, зрештою відповідає людина, а не агент. Якщо джун просто «годує» задачу агенту і котить результат у прод, у нього не формується ані розуміння, ані відчуття відповідальності.

Аналогія з переходом на мови високого рівня

Найімовірніше, покоління джунів, що зростають з агентами, втратить частину низькорівневих компетенцій — так само, як індустрія колись втратила масове вміння писати й читати асемблер із появою мов вищого рівня. Але відповідальність за результат залишилася — просто змістилася на новий рівень абстракції. Тепер специфікації стають «новим кодом», а результат роботи агента — тим, що потрібно вміти пояснити й за що відповідати.

Проблема найму в епоху агентів

Як традиційно влаштований конвеєр найму

У великих техкомпаніях найм побудований як конвеєр із незалежними етапами (скринінг, кілька технічних інтерв'ю, фіт-інтерв'ю, офер), спроєктований для неупередженої й відтворюваної оцінки великого потоку кандидатів. Пріоритет зазвичай — не пропустити слабкого кандидата, навіть ціною відсіювання частини сильних (це відрізняється від точкового найму під конкретну позицію, де шукають сильних людей за спеціальним процесом).

Чому традиційні сигнали найму знецінюються

Багато усталених сигналів найму були влаштовані так, щоб перевіряти саме те, що людям робити складно, а машинам — легко:

Кодинг-інтерв'ю на алгоритми й структури даних раніше було непоганою проксі-метрикою знайомства з комп'ютерними науками та вміння мислити структуровано. Тепер агент вирішує таку задачу миттєво, і сигналу про людину майже не залишається.
Систем-дизайн інтерв'ю страждає схожою проблемою: отримати від агента правдоподібну розповідь про дизайн системи теж легко.

Що потрібно натомість

Компанії хочуть зберегти цінність цих сигналів, але тоді інтерв'ю мають проходити без ШІ — а зрозуміти, як це організувати онлайн, поки незрозуміло; офлайн-перевірка можлива, але дорога й неефективна. Водночас з'являється потреба в новому етапі інтерв'ю — оцінці того, як людина працює з інструментами. Цей етап складно стандартизувати й оцінювати, оскільки:

у кожного кандидата може бути свій робочий флоу (за різними специфікаціями чи методологіями);
оцінювати такий етап повинен хтось, хто сам глибоко розуміється на темі;
незрозуміло, кого саме компанія хоче найняти — продакт-інженера, що вміє швидко котити фічі, чи методолога-розробника, здатного пояснити, чому рішення працює.

Джуни й економіка малих та великих компаній

Для багатьох середніх і малих компаній зараз вигідніше найняти досвідчених інженерів з інструментами, ніж інвестувати в навчання джунів, — бракує ні потоку задач, ні грошей на навчання. У великих компаніях стажування продовжує працювати, оскільки:

туди йде складно відфільтрований потік талантів (олімпіадне програмування, освітні програми), які вже вміють писати код;
компанія навчає їх промисловій розробці за власними правилами, даючи всі інструменти, процеси й систему;
за рахунок цього стажер може почати видавати результат на рівні мідла відносно швидко.

Виникає ризик «трагедії спільних ресурсів»: усій індустрії вигідно переманювати вже готових досвідчених інженерів замість того, щоб інвестувати в навчання джунів, але на рівні окремих великих компаній із розвиненою системою це продовжує працювати. Загалом дефіцит фахівців у майбутньому саморегулюється вільним ринком: попит із затримкою породжує пропозицію з боку освітніх систем і компаній, що займаються навчанням.

Особистий приклад: межі розуміння коду навіть в експерта

Наводиться особистий приклад: людина розуміє код на Go концептуально, хоча сама на ньому не пише, і починає новий проєкт у режимі вайб-кодингу. З кожною новою згенерованою фічею накопичується «яма нерозуміння» — конкретний код стає дедалі менш зрозумілим, хоча загальна структура проєкту (де що лежить) залишається ясною. У якийсь момент доведеться зупинитися, запустити тести вручну і по-справжньому розібратися в деталях, щоб отримати те саме «відчуття на кінчиках пальців», яке дає глибоке практичне розуміння. Питання, чи обов'язково писати код руками для складніших задач (наприклад, невелику бібліотеку на Rust), поки залишається відкритим навіть для досвідченого інженера.

Різниця між простими й живими системами

Важливе застереження: успіхи агентів у переписуванні коду (наприклад, легендарний випадок повного переписування бази даних) часто пов'язані з тим, що йдеться про відносно прості системи — без стану, з майже чистими функціями і нескладним входом-виходом. Це принципово відрізняється від:

живих production-систем зі складними побічними ефектами;
міграцій даних і легасі-коду, де неможливо просто застосувати рішення «в чистому вигляді» — потрібен обережний перехід від старого формату до нового;
систем, що накопичили роками «архітектурну археологію» — код, поведінка якого зафіксована історично, і ніхто вже не пам'ятає першопричини (аналогія з історією про індичку, яку розрізають навпіл «бо завжди так робили», хоча причина була в розмірі старої каструлі бабусі).

У такому реальному світі в агента немає нескінченних прогонів і можливості відкотити спробу без зовнішніх побічних ефектів — на відміну від, скажімо, робота на змаганнях, який просто впаде, розігнавшись занадто сильно: у софтверному інжинирингу часто немає вбудованого «механізму гальмування».

Окремо згадується приклад складних систем, завʼязаних на фізичне середовище: телекомунікаційні компанії досі відправляють тестувальників фізично ходити по регіону з кількома телефонами й сімками, щоб перевірити якість звʼязку — таку роботу поки нічим не замінити.

Моделі світу як можлива наступна хвиля

Згадуються дослідження в напрямку World Models — на відміну від звичайних генеративних моделей, що передбачають результат токен за токеном, модель світу з латентного стану одразу передбачає цільовий результат — те, яким стане світ. Дослідники в цій темі давно займаються self-supervised навчанням, а у Meta подібні спроби (зокрема coding world models) просувалися завдяки одному з головних науковців компанії. Це поки радше дослідницька, ніж мейнстримна тема (на відміну від GPT-подібних систем, у які вже вкладені мільярди доларів), але вона може стати відповіддю на проблему передбачення складних технічних ефектів у реальному світі — якщо навчити модель на різних фізичних процесах. Можливо, це стане наступним витком розвитку, який знову вимагатиме на порядок більше обчислювальних потужностей — і індустрія знову опиниться в ситуації, коли Nvidia багатіє, а всі інші купують собі відеокарти.