Штучний інтелект уже не просто «допомагає писати код» — він змінює саму суть професії розробника. Про це говорить Луї Найт-Вебб, засновник стартапу Vibe Canvas і лондонського осередку спільноти AI Tinkers, який встиг очолити SweeBench verified leaderboard навіть попереду OpenAI. У своїх експериментах з код-агентами він бачить чіткий тренд: люди все менше пишуть код руками і все більше займаються плануванням та перевіркою того, що генерує AI.
Це не просто косметична зміна інструментів. Фактично формується нова модель роботи: інженер як менеджер AI-агентів, який вирішує, що саме треба зробити, як це розбити на задачі, і наскільки ретельно перевіряти результат. І в цій моделі ключовим стає не швидкість друку, а якість плану та ефективність рев’ю.
Коли «писати код» означає планувати й перевіряти
Традиційний робочий день розробника довгий час складався з трьох основних блоків: планування задач, написання коду та рев’ю — свого й чужого. Співвідношення було очевидним: більшість часу йшла на власне кодинг, а планування й рев’ю займали меншу частку.
Поява GitHub Copilot змінила баланс, але не миттєво. Спочатку це були автодоповнення на рівні рядків, які економили хвилини, а не години. Потім з’явилися інструменти на кшталт ранніх версій Cursor, здатні дописувати цілі файли. Далі — більш потужні агенти на кшталт Claude Code, які можуть виконувати складніші зміни в кодовій базі.
У певний момент стає помітно: людина вже майже не «пише код» у класичному сенсі. Вона формулює завдання, запускає агента, отримує дифи, читає, править, перезапускає. Час, який раніше йшов на ручне програмування, не зникає — він перетікає в інші види роботи.
Найт-Вебб описує це як «дислокацію» праці: AI не просто забирає шматок роботи, а перерозподіляє її. Так, продуктивність зростає — за той самий день можна зробити більше. Але замість умовних чотирьох годин кодування розробник тепер витрачає значну частину цього часу на детальніше планування й набагато більш інтенсивне рев’ю AI-змін.
У результаті роль інженера зміщується від «виробника коду» до «оркестратора змін»: людина визначає, що треба зробити, задає рамки, а потім контролює якість і коригує курс.
Дві стратегії роботи з код-агентами: план проти рев’ю
У цій новій реальності Найт-Вебб виділяє два базові підходи до взаємодії з AI-агентами: план-орієнтований і рев’ю-орієнтований.
Перший можна описати як «спочатку думаємо, потім запускаємо». Другий — як «спочатку запускаємо, потім розгрібаємо».
План-орієнтований підхід: більше думати, менше виправляти
У план-орієнтованому режимі інженер вкладає багато зусиль у підготовку. Це може бути розгорнутий markdown-документ зі специфікацією, використання формалізованих фреймворків для спеки, чітке описання інтерфейсів, інваріантів, edge cases. Часто це супроводжується діалогом з моделлю ще до старту основної роботи: агент ставить уточнювальні запитання, доки не «вичерпає» всі неясності.
Сенс такого підходу простий: чим більше контексту й обмежень отримує модель на вході, тим менше шансів, що вона зробить щось принципово не те. Інженер ніби переносить частину майбутнього рев’ю в минуле — у фазу планування.
Перевага очевидна: менше ітерацій, менше сюрпризів, менше болісних правок. Найт-Вебб формулює це у вигляді практичного співвідношення: приблизно п’ять хвилин якісного планування можуть заощадити близько тридцяти хвилин рев’ю AI-коду. У масштабі дня, тижня чи спринту це перетворюється на суттєвий виграш.
Недолік теж зрозумілий: планування займає час і вимагає дисципліни. Потрібно змусити себе не «просто запустити агента», а спочатку чітко сформулювати, що саме він має зробити й за якими правилами.
Рев’ю-орієнтований підхід: швидкий старт, довге виправлення
Альтернативна стратегія — мінімум плану, максимум інтерактиву. Інженер дає агенту відносно розмиту інструкцію на кшталт «додай форму зворотного зв’язку на сторінку», дивиться на результат, потім уточнює: змінити стилі, поправити валідацію, переробити поведінку в окремих станах.
Це схоже на «YOLO-режим»: швидко кинути задачу в AI, подивитися, що вийде, і вже потім через серію рев’ю та доопрацювань довести до потрібного стану.
Плюс такого підходу — низький поріг входу. Не потрібно витрачати час на формалізацію, можна одразу рухатися вперед. Мінус — висока вартість людського часу на кожній ітерації. Кожен цикл «запустив — подивився — поправив» вимагає уваги, контексту, перемикання між задачами.
Найт-Вебб наголошує: якщо вважати людський час головною цінністю, план-орієнтований підхід майже завжди виграє. Постійне «пінг-понг рев’ю» з агентом виявляється дорожчим, ніж додаткові хвилини, витрачені на початку.
Фронтенд проти бекенду: де потрібен «людина в циклі»
Вибір між план- і рев’ю-орієнтованою стратегією залежить не лише від особистих уподобань, а й від типу задачі. Найт-Вебб пропонує дивитися на це через просту матрицю: фронтенд проти бекенду, фічер-девелопмент проти міграцій і підтримки.
Фронтенд-фічі: хаотичний світ, де плану мало
Фронтенд-фічер-девелопмент — це, за його спостереженнями, найменш придатна сфера для жорстко план-орієнтованого підходу. Причина — у природі фронтенду.
Інтерфейси надзвичайно станні: безліч варіантів поведінки, анімації, переходи, адаптивність, інтеракції з користувачем. Візуальні деталі, які важко описати словами, але легко побачити очима. Кількість edge cases зростає лавиноподібно, щойно з’являються складніші сценарії.
У таких умовах спроба «заспецифікувати все наперед» часто або провалюється, або виявляється дорожчою за поступову інтерактивну роботу. Найт-Вебб визнає, що для фронтенд-фіч йому значно комфортніше залишатися «в циклі» разом з агентом: дивитися на проміжні результати, одразу коригувати, уточнювати, змінювати дрібні деталі.
Це класичний рев’ю-орієнтований режим: AI виступає швидким виконавцем, але людина постійно поруч, щоб направляти.
Бекенд, рефакторинги й міграції: територія плану й тестів
На протилежному полюсі — бекенд-розробка, рефакторинг і міграції. Тут, на думку Найт-Вебба, значно легше й доцільніше працювати в план-орієнтованому, майже тест-драйвен режимі.
Бекендові зміни частіше можна описати формально: є чіткі контракти, схеми даних, інваріанти, бізнес-правила. Для рефакторингів і міграцій узагалі природно мислити через тести: задано поточну поведінку, бажану поведінку, набір інваріантів, які не можна порушити.
У такому середовищі агенту можна дати детальну специфікацію, набір тестів і дозволити виконати значну частину роботи без постійної участі людини. Інженер повертається в гру вже на етапі підсумкового рев’ю: перевірити дифи, прогнати тести, переконатися, що інваріанти збережено.
Найт-Вебб доходить до доволі радикального формулювання: для рефакторингів і міграцій людина взагалі не повинна бути «в циклі» під час виконання роботи. Усе має бути побудовано навколо тестів і чітких планів, а не навколо постійного ручного втручання.
П’ять хвилин проти тридцяти: економіка уваги розробника
Ключова теза, яку він пропонує запам’ятати, звучить майже як правило великого пальця: п’ять хвилин планування економлять тридцять хвилин рев’ю AI-коду.
Це не математично виведена формула, а емпіричне спостереження, але воно добре описує нову економіку уваги. У світі, де AI бере на себе «середину» роботи — власне написання коду, — головним вузьким місцем стає не швидкість моделей, а здатність людини якісно думати наперед і ефективно перевіряти результат.
Якщо інженер щоразу «економить» на плані, він платить за це довгими циклами рев’ю, контекстними перемиканнями, фрустрацією від повторюваних помилок агента. Якщо ж він системно інвестує час у чіткі спеки, хороші тести й продумані промпти, AI-агенти стають набагато передбачуванішими, а рев’ю — коротшим і менш виснажливим.
Це зміщує фокус компетенцій. Цінність набувають не стільки навички «як написати цю функцію», скільки вміння:
формулювати вимоги так, щоб їх міг зрозуміти як комп’ютер, так і людина;
бачити edge cases ще до того, як вони вистрілять у продакшені;
будувати тести й інваріанти, які дозволяють довіряти великим автоматизованим змінам.
У цьому сенсі AI не стільки «спрощує» роботу розробника, скільки піднімає планку абстракції: замість боротьби з синтаксисом і дрібними багами доводиться більше думати про архітектуру, контракти й сценарії використання.
Коли агент працює довше за п’ять хвилин: нова логіка робочого дня
Ще один важливий зсув, який описує Найт-Вебб, стосується часу виконання агентів. Чим потужнішими стають інструменти, тим довше вони працюють над кожною задачею.
GitHub Copilot доповнює рядок за секунди. Ранні версії Cursor могли генерувати файл за кілька десятків секунд. Claude Code спочатку працював хвилину-дві, а тепер, за його словами, дає хороші результати при виконанні завдань протягом п’яти-десяти хвилин.
Причина — у зростанні складності того, що робить агент. Якщо раніше він просто повертав шматок коду, то тепер може запускати тайпчекер, тести, інструменти на кшталт Playwright MCP для енд-ту-енд перевірок. Кожен додатковий крок збільшує час виконання, але водночас підвищує якість результату й зменшує потребу в людському рев’ю.
Це створює нову дилему: що робити розробнику, поки агент «думає»?
Найт-Вебб пропонує орієнтуватися на п’ятихвилинний поріг. До приблизно п’яти хвилин людина ще може дозволити собі «просто почекати»: подивитися логи, відволіктися на щось дрібне. Але щойно середній час виконання перевищує цей поріг і наближається до десяти, двадцяти хвилин і більше, така стратегія стає нераціональною.
Сидіти й дивитися, як агент працює двадцять хвилин, — це пряме спалювання людської уваги. На цьому етапі змінюватися має не лише інструмент, а й сама організація роботи.
Паралельні агенти й нові інтерфейси для «менеджера AI»
Відповідь, яку пропонує Найт-Вебб, — паралелізація. Якщо один агент виконує задачу десять хвилин, немає сенсу чекати його в бездіяльності. Набагато ефективніше запустити кілька таких задач одночасно.
У такій моделі робочий цикл виглядає інакше. Інженер:
запускає кілька агентів на різних задачах;
перемикається в режим рев’ю там, де агент уже закінчив;
поки він перевіряє одну задачу, інші агенти продовжують працювати;
щойно рев’ю завершено, наступний агент, імовірно, уже теж готовий до перевірки.
Це перетворює розробника на координатора кількох паралельних потоків роботи. Важливо вже не лише «як сформулювати задачу», а й «як організувати чергу задач так, щоб не простоювати між рев’ю».
Саме з цієї логіки виріс проєкт Vibe Kanban, який Найт-Вебб почав будувати близько 14 червня 2025 року. Його мета була простою: зробити паралелізацію агентів тривіальною.
Інтерфейс Vibe Kanban пропонував бічну панель із кількома робочими просторами, кожен з яких міг запускати різні код-агенти — від Codex до інших популярних інструментів. Для кожного воркспейсу можна було дивитися дифи, залишати коментарі у стилі GitHub, відкривати прев’ю, змінювати дрібні деталі інтерфейсу.
Ідея полягала в тому, щоб зібрати в одному місці те, що зараз розкидано між терміналом, IDE, браузером і CI-системою. Якщо агенти працюють по десять хвилин і більше, інтерфейс має допомагати людині не губитися між ними, а фокусуватися на рев’ю там, де це потрібно саме зараз.
Найт-Вебб дивиться на це ширше: майбутні інструменти програмування мають сприймати розробника як менеджера кількох одночасних агентних воркстрімів. Інтерфейси повинні мінімізувати хаотичні перемикання контексту й допомагати «максимізувати фокус», поки агенти виконують довгі операції у фоновому режимі.
Що означає «бути розробником», коли AI «з’їдає середину»
Якщо звести всі ці спостереження докупи, вимальовується досить чітка картина майбутнього програмування.
По-перше, ручне написання коду перестає бути центральною частиною роботи. Воно не зникає повністю, але стає дедалі меншою часткою дня. Натомість зростає значення планування, формалізації вимог, побудови тестів і рев’ю.
По-друге, з’являється необхідність свідомо обирати стратегію взаємодії з AI: коли варто інвестувати в детальний план, а коли неминуче доведеться працювати в рев’ю-орієнтованому режимі — як у фронтенд-фічах.
По-третє, збільшення часу виконання агентів змушує переосмислити організацію робочого дня. Паралельні воркстріми, черги задач, інтерфейси, що зменшують когнітивне навантаження, — усе це стає не «приємним бонусом», а необхідністю.
І нарешті, змінюється профіль навичок, які роблять інженера ефективним. Уміння швидко писати код поступово відходить на другий план. Натомість критично важливими стають:
здатність мислити системно й наперед;
вміння будувати чіткі, машинно-читабельні спеки;
дисципліна в тестуванні й роботі з інваріантами;
організація власного часу й уваги в умовах паралельних агентних процесів.
У цьому сенсі формула Найт-Вебба — «п’ять хвилин плану проти тридцяти хвилин рев’ю» — добре резюмує нову епоху. AI справді «з’їдає середину» програмування, але те, що залишається людям, стає не менш складним — просто інакшим. І саме від того, наскільки швидко інженери навчаться планувати й рев’ювати роботу машин, залежатиме, чи перетвориться ця еволюція на справжній стрибок продуктивності, чи лише на зміну інструментів без якісного виграшу.
Джерело
YouTube: Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban