У світі, де GitHub Copilot, Claude Code та інші агентні інструменти пишуть усе більше коду замість людей, роль розробника стрімко змінюється. Британський інженер і підприємець Луїс Найт-Вебб, засновник стартапу Vibe Canvas і організатор лондонського осередку спільноти AI Tinkers, один із тих, хто не просто експериментує з новими інструментами, а й намагається переосмислити саму структуру роботи інженерів. Його ім’я з’являлося на верифікованому лідерборді SweeBench вище за OpenAI, але останній рік він присвятив іншому експерименту — продукту Vibe Kanban, який мав навчити розробників керувати паралельними AI-агентами, а не просто «спілкуватися з одним чат-ботом».
Парадоксально, але кульмінацією цієї історії стало публічне рішення закрити Vibe Kanban як компанію — прямо під час виступу, в якому Найт-Вебб демонстрував продукт у дії. Попри близько 30 тисяч активних користувачів на місяць, він натиснув «публікувати» під блогпостом про закриття, створеним… у самому ж Vibe Kanban.
За цією видовищною сценою стоїть значно глибша теза: майбутні інструменти програмування мають ставитися до розробника як до менеджера кількох довготривалих агентів, а не як до людини, що «дописує рядки коду». І це вимагатиме зовсім інших інтерфейсів, звичок і способів організації роботи.
Від автодоповнення до 10-хвилинних запусків: як росте час виконання агентів
Перші хвилі AI-інструментів для розробників здавалися майже миттєвими. GitHub Copilot дописував один рядок за секунди, ранні версії Cursor могли завершити файл за кількадесят секунд. Цей режим добре вписувався у звичну модель роботи: розробник пише код, інструмент «підказує» або дописує, а контекст перемикається рідко і майже безболісно.
Але зі зростанням можливостей моделей і, головне, їхнього доступу до інструментів, усе змінилося. Сучасні агентні середовища вже не просто повертають шматок коду у відповідь на промпт. Вони викликають CLI-утиліти, запускають тести, проганяють типізатор, іноді взаємодіють із браузером через Chrome чи Playwright MCP. Кожен додатковий крок — це ще одна хвилина очікування.
Найт-Вебб описує чітку еволюцію:
спочатку — Copilot, який завершує рядок за секунди;
потім — інструменти на кшталт раннього Cursor, що генерують цілий файл за 30 секунд;
потім — Claude Code, який ще минулого року працював хвилину-дві, а нині дає якісні результати після 5–10 хвилин виконання.
Причина в тому, що ми рухаємося від «ось вам код» до повноцінного циклу: згенерувати зміни, прогнати типізатор, запустити тести, можливо, навіть UI-скрипти в браузері. Кожен рівень додає точності, але й збільшує час.
Це не просто технічна деталь. Це змінює саму поведінку людей. Коли агент працює 30 секунд, розробник може спокійно «сидіти в контексті» — дивитися логи, думати про наступний крок. Коли ж середній запуск триває 5–10 хвилин, така стратегія перетворюється на марнування часу.
Поріг у п’ять хвилин: коли чекати вже безглуздо
Найт-Вебб пропонує просту, але жорстку евристику: приблизно на позначці у п’ять хвилин очікування поведінка розробника має змінитися. До цієї межі ще можна «перечекати» — гортати логи, відволіктися на стрічку соцмереж, залишаючись умовно в тому ж завданні. Після — це вже не очікування, а втрата робочого часу.
Якщо агентні інструменти стабільно виходять за цей поріг, а тренд іде до 20-хвилинних, а потім і годинних запусків, класична модель «запустив — сиджу, дивлюся» стає неприйнятною. Розробник, який продовжує працювати так само, фактично перетворюється на оператора, що спостерігає за довгими логами, замість того щоб використовувати власний час як найдефіцитніший ресурс.
Відповідь, яку пропонує Найт-Вебб, — радикальна паралелізація. Якщо один агентний запуск триває 10 хвилин, логічно мати кілька таких запусків одночасно. Поки один агент тестує зміни, інший завершує рефакторинг, третій готує міграцію. Людина в цей час не «чекає», а переходить до рев’ю того, що вже завершилося.
Це схоже на те, як працюють сучасні CI/CD-пайплайни: ніхто не запускає тести послідовно, якщо їх можна рознести по кількох машинах. Але тепер мова не про інфраструктуру, а про саму робочу пам’ять і увагу розробника. Потрібні інструменти, які дозволяють тримати в голові одне завдання, поки інші виконуються у фоновому режимі, і при цьому не змушують людину постійно скакати між десятком вікон.
Vibe Kanban: спроба зробити паралельних агентів керованими
Саме з цієї проблеми й народився Vibe Kanban — проєкт, який Найт-Вебб і команда почали приблизно 14 червня 2025 року. Ідея була проста: якщо агенти стають довготривалими, розробнику потрібен інструмент, який дозволить легко запускати багато таких процесів паралельно й керувати ними як окремими робочими потоками.
Vibe Kanban будувався як щось середнє між IDE, GitHub і таск-трекером. У боковій панелі користувач бачив кілька «воркспейсів» — незалежних робочих просторів, кожен з яких міг бути підключений до різних кодових агентів. Підтримувалося близько восьми популярних інструментів, включно з Codex, ідея полягала в тому, щоб не прив’язуватися до одного вендора чи моделі.
У кожному воркспейсі агент міг виконувати свою задачу: генерувати код, запускати тести, вносити зміни в репозиторій. Коли наставала черга людини, інтерфейс показував дифи у форматі, знайомому користувачам GitHub: зміни по файлах, можливість залишати коментарі, уточнювати правки, просити агента переробити окремі фрагменти.
Якщо потрібно було оцінити результат у візуальному вигляді, Vibe Kanban дозволяв відкривати прев’ю, клікати по елементах інтерфейсу, просити змінити розміри чи стилі. Це була спроба перенести звичний досвід code review та UI-рев’ю у світ, де більшість змін робить не людина, а агент.
Ключова ідея — не просто дати ще один «чат із моделлю», а створити середовище, де розробник одночасно керує кількома агентами, кожен з яких рухає свій шматок роботи. Поки один воркспейс «вариться» 10 хвилин, інший уже готовий до рев’ю, третій щойно стартував. Людина перестає бути пасивним спостерігачем і стає диспетчером, який розподіляє увагу між потоками.
Інтерфейси для менеджера агентів: мінімум контекстних стрибків, максимум фокусу
З досвіду роботи над Vibe Kanban Найт-Вебб формулює більш загальне бачення: майбутні інструменти програмування мають сприймати розробника не як «автора коду», а як менеджера кількох паралельних агентних робочих потоків.
У такій моделі головна проблема — не в тому, щоб «запустити ще одного агента», а в тому, щоб зберегти людський фокус. Якщо розробник змушений постійно стрибати між терміналом, IDE, браузером, таск-трекером і логами кількох агентів, виграш від автоматизації швидко з’їдається вартістю контекстних перемикань.
Найт-Вебб говорить про необхідність інтерфейсів, які:
мінімізують частоту й «вартість» перемикання контексту;
дозволяють тримати в полі зору лише те, що потребує людського рішення прямо зараз;
перетворюють довгі агентні запуски на фонові процеси, які не розривають концентрацію.
У цій картині роль інструментів виходить далеко за межі автодоповнення. Вони мають допомагати формулювати завдання для агентів, розбивати роботу на частини, планувати послідовність кроків, організовувати QA, проводити code review і супроводжувати зміни до самого деплою. Людина стає тим, хто пише завдання, оцінює ризики, приймає рішення про прийняття чи відхилення змін, а не тим, хто руками переносить байти з голови в редактор.
Особливо показовою є перспектива фронтенду. Сьогодні більшість команд не використовують у повсякденній роботі можливості на кшталт Chrome чи Playwright MCP для автоматизованого кліканого QA інтерфейсів. Але Найт-Вебб очікує, що саме тут відбудеться наступний прорив: агенти зможуть самі запускати застосунок, клікати по екранах, шукати баги й перевіряти, чи справді реалізовано потрібну поведінку. Це ще більше збільшить час окремих запусків, але водночас ще сильніше зменшить потребу людини бути «в циклі» на кожному кроці.
У такому світі інтерфейс, який змушує розробника постійно «перескакувати» між десятком вікон, стає гальмом. Потрібні середовища, що дозволяють фокусуватися на одному завданні, поки десяток агентів працюють у фоні, і плавно переключатися лише тоді, коли дійсно є що переглянути чи затвердити.
Паралельні агенти як нова норма — і чому Vibe Kanban не дожив до цієї ери
Попри те, що ідеї Vibe Kanban виглядають напрочуд співзвучними з трендами, сам продукт як компанія не дожив до моменту, коли паралельні агентні робочі потоки стануть мейнстримом. Найт-Вебб розповів, що незадовго до виступу ухвалив рішення закрити Vibe Kanban, і використав сам сервіс, щоб у прямому ефірі додати й опублікувати блогпост про це на сайті компанії.
За його словами, на момент закриття в продукту було близько 30 тисяч активних користувачів на місяць — цифра, яка свідчить про реальний інтерес до ідеї. Але цього виявилося недостатньо, щоб продовжувати розвивати її як окремий бізнес.
Цей крок не скасовує головного висновку, до якого він прийшов: поведінка розробників неминуче зміниться, коли середній час роботи агентів стабільно перевищить п’ять хвилин. Паралелізація стане не «хаком для ентузіастів», а базовою вимогою до інструментів. А інтерфейси, які не вміють працювати з кількома довготривалими агентами одночасно, виглядатимуть так само архаїчно, як ручний деплой на продакшн через FTP.
Vibe Kanban можна розглядати як ранню спробу спроєктувати інтерфейс для цієї майбутньої ролі — ролі менеджера агентів. Те, що компанія закрилася, не означає, що ідея виявилася хибною. Швидше, це натяк на те, що ринок ще не повністю дозрів, а наступні покоління інструментів, можливо, вбудують подібні концепції безпосередньо в IDE, платформи CI/CD чи хмарні середовища розробки.
Що буде далі з інструментами для розробників
Якщо прийняти вихідну тезу Найт-Вебба — що час роботи агентів зростатиме, а їхні можливості охоплюватимуть усе більше етапів розробки, — то майбутнє інженерних інструментів виглядає доволі чітко окресленим.
По-перше, інтерфейси мають навчитися працювати з довгими часовими горизонтами. Замість миттєвих відповідей — 10, 20, 60 хвилин роботи агента. Замість одного «сеансу» — кілька паралельних воркспейсів, кожен зі своїм життєвим циклом.
По-друге, фокус зміститься з «редагування коду» на «керування змінами». Інструменти мають допомагати писати завдання для агентів, планувати послідовність кроків, організовувати QA, проводити рев’ю, стежити за тим, як зміни проходять шлях від гілки до продакшну.
По-третє, головною метрикою стане не швидкість генерації коду, а те, наскільки мало часу людина витрачає на взаємодію з агентами. Якщо додаткові 5 хвилин роботи агента заощаджують розробнику 30 хвилин рев’ю, це вигідний обмін. Якщо інтерфейс дозволяє паралелізувати десять таких запусків, не розриваючи концентрацію, це вже не просто зручність, а конкурентна перевага.
У цьому сенсі історія Vibe Kanban — це не стільки історія про закриття стартапу, скільки про ранню спробу відповісти на питання: що робитимуть розробники, коли AI-агенти стануть достатньо розумними й повільними одночасно? Відповідь Найт-Вебба проста й водночас вимоглива: вони стануть менеджерами агентів. І тим, хто проєктує інструменти для цієї ролі, доведеться навчитися працювати не лише з кодом, а й з людською увагою.
Джерело
Software Engineering Is Becoming Plan and Review — Louis Knight-Webb, Vibe Kanban