Підсумки року у вайб-кодингу

Загалом, мені здається, кінець року – найкращий момент, щоб ще раз поговорити про вайб-кодинг. Про нього пишуть, його вчать і намагаються відучити, про нього говорять усі підряд і навіть обрали словом року. Колеги з подкасту Радіо-Т весь рік зі згасаючим ентузіазмом обіцяли, що ось-ось все те, що не відповідає високому званню програміста навайбкоділи, нарешті перестане працювати та весь світ прийде до них на уклін за виправленнями – ну, і раз вже я закінчив рік випуском вже третьої версії цікавого проєкту, де весь код написаний і налагоджений різними версіями AI, то цілком можна і підбити підсумки.

Ілюстрація того, як повинна змінитися робота програміста (prompt: Claude Opus 4.5, picture: IMAGEN 4

Ймовірно, коли-небудь у майбутньому ми зможемо озирнутися назад, вказати пальцем на 2025 рік і сказати – ось той момент, коли штучний інтелект перестав бути розвагою для гіків і почав цілком реально застосовуватися в роботі, замінюючи людину. Повторення – мати навчання, тому я, можливо, повторю зараз те, що вже казав протягом року. З іншого боку, минув певний час, тож у мене або додалося деталей, або впевненості для таких тверджень.

Ключова користь вайб-кодингу для мене – це не заміна людини-розробника, а поява завжди доступного розробника (а то й багатьох розробників) і не тільки розробника. Я почав таку розробку з того, що автоматизував завдання, яке регулярно повторюється – підготовка чернеток і перевірка текстів для телеграм-каналу. Залучення AI розв'язало дві проблеми – проблему чистого аркуша в написанні коментаря і проблему помилок і неточностей, які я міг допустити, побіжно читаючи новину, що коментується. Але перш за все використання LLM – це був Sonnet 3.5 на той момент, – дозволило мені розробити рішення, яке інакше не було б реалізовано ніколи.

Так і продовжувалося – за цей рік я обріс цілим набором дрібних і не дуже програм і сервісів, які розв’язують якісь рутинні завдання. Я, мабуть, кілька років мучився з додаванням новин для обговорення в Радіо-Т – там треба вказати посилання, після чого робот намагається завантажити новину і виділити текст, але в половині випадків він стикається з блокуванням роботів. На розробку розширення для Chrome, яке відправляє контент поточної сторінки з посиланням, картинкою і без зайвих тегів через API сервісу, пішло в підсумку менш як годину й з того часу цей процес більше не дратує. Подивившись в черговий раз на свій блог, я зрозумів, що тримати величезний IDE тільки для написання тексту в блозі мені огидно, і за пару днів, точніше за 8 годин розробки, у мене з'явився спеціальний редактор під MacOS, який просто пише тексти, вставляє картинки та публікує в блозі.

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

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

Ні, якщо ви подумали, що це ми так пристосували AI, то ні, в самому процесі обробки жоден AI не страждає. Але він неабияк попрацював у процесі розробки прототипу.

Перш за все, процес пошуку рішення почався з декількох deep research в декількох LLM і довгих чатах за результатами досліджень – що може бути оптимальним джерелом сигналів? Кілька гіпотез, що виникли, були оперативно перевірені тут же написаними AI скриптами й відкинуті, а одна здалася цікавою. Потім була перехресна перевірка (на цьому, та й на будь-якому етапі такого спілкування з LLM дуже важливо вказувати на необхідність критичного аналізу, а то вони норовлять вигукнути «Прекрасна ідея» і сенс перевірки пропадає), і ми зайнялися безпосередньо реалізацією.

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

В одному випадку початкова ідея «нумо шукати в потоці певні ключові слова» в результаті реалізувалася в компактну ML-модель, яка фільтрувала записи не регулярними виразами, а використовувала Random Forest, показуючи 97% точності. Все необхідне для складання датасетів, навчання моделі й бібліотеку для inference написав, звичайно, AI – моя робота полягала в генерації гіпотез і написанні промптів. Так, всі метаморфози ідеї від гіпотези до архітектури рішення теж обговорювалися з AI.

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

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

Я ж у підсумку так розійшовся, що частина прототипів почала писатися на Go – компільованій мові, на якій я сам не напишу ні рядка. Але, коли прототип на Python почав з'їдати по 300 мегабайтів пам'яті й довелося вибирати між незнанням мови (хоча я і на Python не писав, весь код писався AI) і перспективою розтягнути тест фільтра на пару днів, довелося довіритися машині.

Зрозуміло, я не втримався і показав частину написаного коду колезі по подкасту Радіо-Т Умпутуну, який вважається авторитетом у розробці на Go. Женя, зрозуміло, сказав, що так ніхто не пише, він би такий код не прийняв і взагалі все погано, але до цих заперечень я ще повернуся.

Про другий проєкт я можу розповісти більше, тим більше, що це абсолютно публічна річ, доступна з літа десяткам тисяч користувачів. Мова піде про чатбот, який працює вже кілька місяців на українському порталі dtkt.ua. Чатбот відповідає на питання про податковий і бухгалтерський облік, може дати рекомендації з питань звітності, непогано орієнтується в змінах законодавства. Технічно це RAG (Retrieval-Augmented Generation) бот, який використовує як джерело дані самого порталу, що включають закони, новини, відповіді на питання, підготовлені консультантами, інструкції, інструктивні листи податкової тощо.

Початковий план виглядав зовсім інакше. Запит від порталу був скоріше на помічника для тих самих консультантів, і ідея полягала в тому, щоб невелике рішення, схоже на те, яке допомагає мені писати коментарі в телеграм-канал, готувало б чернетку відповіді на питання користувача, а потім перевіряло фінальну відповідь, відкориговану професіоналом. Але вийшло зовсім не так.

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

Питання вибору основної моделі теж не вирішилося швидко. Хоча мені було легше, оскільки я не знав правильних відповідей, але ось консультанти посперечалися. У підсумку я згадав минуле, взяв набір з декількох десятків питань і відповідей (вже наявні консультації) і влаштував нормальний evaluation – кілька кандидатів-LLM відповіли на питання, а потім їхні відповіді порівняли з еталоном – консультант і ще одна LLM-суддя. Переконавшись, що оцінки суддів корелюють (збігатися вони не будуть, але те, що вище оцінювалося машиною, вище оцінювала і людина), я прогнав через тест вже 200 питань, відповіді на які оцінювалися тільки LLM. На мій подив, перемогла, обійшовши таких солідних суперників, як OpenAI o1, GPT-4o і Sonnet 3.5, модель Google Gemini 2.5 Pro, яка тоді тільки вийшла.

І тут у клієнта з'явилося бажання зробити не помічника консультанта, а повноцінний чат-бот. А я, хоч і нагадував кілька разів, в тому числі самому собі, що граю роль консультанта з AI, в результаті подумав, а чому б нам і не замахнутися, розумієте? І сів писати ТЗ на другу версію.

Результат виглядає як повноцінний чатбот на порталі, який доступний майже 100 тисячам підписників, правда, користуються, зрозуміло, кілька тисяч на тиждень. Технічно це кластер в Google Cloud, де використовується цілий комплекс LLM – питання користувача потрапляє у швидку модель, яка вирішує, наскільки воно складне (і чи треба взагалі відповідати, наприклад, попросити рецепт чізкейка не вийде) і обробляє його для кращого пошуку. Ми її додали, коли в закритому тесті туди зайшов один з тестерів, написав «Привіт» і через 50 секунд отримав відповідь, що в наданих документах відповіді на його питання не міститься.

Після швидкої моделі (практично пишаюся, що придумали router до запуску GPT5) оброблений запит потрапляє в пошук, який шукає у векторній базі, де складений контент порталу, і результати віддає в ще одну LLM для переранжування. Ми тестували в різних конфігураціях і в підсумку прийшли до того, що пошук збирає до 100 документів (схожих і відповідних ключовим словам), після переранжування залишається 25 кращих, які й відправляються разом з довгим промптомом у фінальну LLM для генерації відповіді.

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

Ось саме тут я цього тижня після тестування випустив нову версію – присвятивши початок грудня тестуванню декількох параметрів і побудові автоматичної системи оцінки.

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

Назвіть це вайб-кодингом, якщо хочете.

Треба, звичайно, сказати, що я не гуманітарій з неясним уявленням про інтернет-сервіси, яким заведено зображати «вайб-кодера». Все ж, свій перший сайт я зробив приблизно 26 років тому, копатися в скриптах на рівні «завантажив, не працює, написав команду, запрацювало, змінив в коді, зламалося, ще раз змінив, запрацювало як треба» я почав 25 років тому і якось весь цей час розбирався з проблемами що виникали й тими завданнями, що ставив собі сам. Багато спілкуючись з розробниками дуже серйозних речей (на кшталт пошуку в інтернеті для мільйонів людей), я, звичайно, не намагався давати поради з області тензорного аналізу, але на рівні застосування розроблених технологій намагався не плавати. І багато з того, що я чув або читав 10-15 років тому, я із задоволенням згадував і застосовував протягом цього року – хоча і повторюю регулярно «Не чекайте, що я вам тут зараз Google напишу».

Тому популярний аргумент «Він (тобто вайбкодер) поняття не має, що там в коді робиться» зі мною не проходить – я знаю, що там робиться принаймні в загальних рисах, причому набагато детальніше, ніж будь-який менеджер і керівник знає, що робиться в коді, написаному програмістом-людиною. Щобільше, на відміну від такого керівника, я можу цей код показати іншій LLM, повернутися до першої, довго тикати курсором і ставити питання «А що тут робиться?» і отримувати максимально докладні відповіді й жодного разу не образити геніального інтроверта-розробника і не дізнавшись, що я знецінюю роботу, при тому, що все одно не розберуся в ній ніколи.

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

Це мало чим відрізняється від роботи з людьми – як я згадав вище, у випадку з живим розробником ви навіть менше знаєте, що саме написано в коді, поки самі не почнете його читати та розбиратися краще, ніж розробник. Але, вибачте, навіщо вам тоді власне розробник?

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

Ба більше – далеко не факт, що цей код взагалі треба підтримувати навіть силами AI. Не хочу зараз глибоко занурюватися в концепцію disposable code, але в більшості випадків може виявитися простіше не розбиратися в наявному коді, а просто переписати його новою версією LLM з нуля.

Іронія з аргументом про підтримку ще й у тому, що зараз розробники регулярно стикаються з проблемою розібратися в чужому коді, чужій системі й підтримувати проєкт, автор якого давно звільнився або навіть помер від старості – але це вважається священною проблемою legacy і в ній нічого дивного не вбачають.

Важливий висновок – в описаних проєктах використання AI в розробці прискорило процес у рази. Я все ж мав відношення до програмних проєктів і точно знаю, що розробити систему від ТЗ до початку розгортання за місяць – це дуже серйозне завдання для команди з людей-розробників. Переведіть час у гроші й ви отримаєте бюджет на кілька місяців і кілька десятків тисяч доларів проти 200-250 доларів на підписку в Claude/OpenAI/Gemini плюс зарплата «оператора» – мені здається, «швидше в рази й дешевше на порядок» буде адекватним результатом порівняння.

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

Підсумки року у вайб-кодингу

Стратегія охолодження ЦОД для епохи AI