Ілон Маск відвідав подкаст Дваркеша Патела і Джона Коллісона, і зараз усі цитують його заяву про датацентри в космосі. Але там є багато інших тем. Так, він заявив, що «протягом 36 місяців або менше» (можливо, «ближче до 30 місяців») космос стане «найекономічнішим місцем для розміщення AI», аргументуючи це труднощами масштабування енергосистем на Землі та регуляторними бар'єрами при розгортанні великих сонячних проєктів. Ефективність сонячних панелей у космосі може бути приблизно «в п'ять разів» вищою через відсутність ночі, хмар і атмосфери, і там не потрібні батареї для накопичення енергії (логічно, сонце в космосі є завжди).

Правда, як планується розв'язати проблему з охолодженням датацентрів, він не говорив.

У розмові наводилися практичні оцінки споживання для великих обчислювальних кластерів. За словами Маска, «кожні 110000 GB300» з урахуванням мережевої інфраструктури, CPU, сховища, охолодження та резерву на обслуговування генерації вимагають «приблизно 300 мегаватів», а «330000 GB300» – «приблизно гігават» потужності на рівні генерації (плюс-мінус один енергоблок АЕС). Як приклад він описав досвід xAI з розгортання енергопостачання для проєкту Colossus 2. Через складнощі з дозволами в Теннессі частину рішень, за його словами, довелося переносити через кордон штату в Міссісіпі, з прокладанням ліній електропередачі на кілька миль. Це досить анекдотичний приклад, до речі – датацентр стоїть практично на кордоні штатів, так що електростанцію для нього просто розмістили з іншого боку кордону, реально в парі миль.

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

Маск повідомив, що SpaceX і Tesla «будують плани» щодо виходу на «100 гігаватів на рік» виробництва сонячних елементів, і пов'язав перспективи космічної енергетики з темпами запусків Starship. Він припустив, що через п'ять років «щороку» буде запускатися та експлуатуватися більше AI-потужностей в космосі, ніж сумарно на Землі, і оцінив майбутній масштаб як «кілька сотень гігават на рік» зі зростанням до «близько теравата на рік» до виникнення обмежень по паливу для ракети. В обговоренні прозвучала оцінка, що 100 гігаватів у космосі можуть відповідати «близько 10000 запусків Starship». А також теза Маска про готовність SpaceX «націлюватися» на «10000 запусків на рік» і потенційно «20-30000». При оцінці, що для такого темпу може вистачити «20 або 30» кораблів залежно від циклу повернення.

Окремим блоком обговорювалося виробництво чіпів та ідея TeraFab для логіки, пам'яті та упаковки, а також ризики дефіциту пам'яті (RAM) і зростання цін на DDR. Маск заявив, що виведення фабрики на об'ємне виробництво з високим виходом придатної продукції займає близько «п'яти років», і перерахував використання потужностей TSMC Taiwan, Samsung Korea, TSMC Arizona і Samsung Texas.

Також він згадував плани щодо виведення Tesla AI5 «приблизно до другого кварталу наступного року», а AI6 – «менш ніж через рік» після цього.

Для космічного застосування чіпів він говорив про необхідність більшої радіаційної стійкості й вищої робочої температури. Також прозвучала оцінка цільового масштабу на 2030 рік – «100 гігаватів» по енергії та відповідний обсяг чіпів, включаючи згадку про «100 мільйонів» повнорозмірних (full reticle) чіпів при розрахунку «кіловат на фотошаблон».

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

У частині робототехніки Маск назвав ключовими проблемами гуманоїдів «інтелект у реальному світі», «кисть» і «масове виробництво». Стверджуючи, що в Optimus проблема створення руки вирішується коштом повністю кастомних приводів, електроніки, сенсорів і управління, за відсутності готового ланцюжка постачання. Він заявив, що Optimus 3, за його оцінкою, повинен підійти для виробництва «близько мільйона» одиниць на рік, а Optimus 4 – для масштабування до «10 мільйонів» на рік. Для навчання планується створення «Optimus Academy» з «як мінімум 10000» і, можливо, «20-30000» роботами для самонавчання в реальності та «мільйонами» в симуляції, щоб скоротити розрив sim‑to‑real.

Також у розмові порушувалися теми Китаю та США (включаючи твердження Маска, що тарифи на імпорт сонячних панелей у США становлять «кілька сотень відсотків»), його оцінка залежності США від китайського рафінування сировини (зокрема, згадка про «98%» рафінування галію в Китаї), а також теза Маска, що без «проривних інновацій» США Китай «буде домінувати» у виробництві.

У політичній частині Маск згадав DOGE і заявив, що GAO оцінював обсяг шахрайства за адміністрації Джо Байдена «приблизно в половину трильйона доларів», а також навів приклади з базою Social Security і платежами Treasury на «$5 трлн» на рік. Окремо він сказав, що придбання Twitter і підтримка обрання Дональда Трампа, на його думку, були діями «в інтересах цивілізації». З чого можна зробити висновок, що найважливішим з інтересів цивілізації для нас є поржати.

Маск про перспективи ЦОДів у космосі, виробництво чіпів і робототехніку

Anthropic опублікували маніфест про те, чому в Claude ніколи не буде реклами. Компанія вважає, що рекламна модель несумісна з тим, чим повинен бути AI-асистент.

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

Окремо Anthropic попереджає про довгострокові ризики: історія рекламних продуктів показує, що реклама, одного разу з'явившись, має властивість розширюватися і розмивати межі, які спочатку здавалися чіткими.

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

І в улюбленому стилі коментаторів – їм краще б моделями зайнятися. А то я другий день не чіпаю цікаве завдання – читаю чутки, що вони вже котили чи то Sonnet 5, чи то Opus 4.6, але все впало, відкотили, днями покотять знову.

AI-асистент Anthropic Claude – без реклами назавжди?

Мабуть, головна зміна, яка відбулася у мене у зв'язку з широким використанням LLM, – зникли неможливі завдання. Будь-яка складність або завдання, пов'язані з великою кількістю інформації або автоматизацією чогось рутинного, тепер сприймаються як своєрідний виклик – а ну, як з цим впоратися?

З іншого боку, звичайно, іноді в розпал боїв з Claude Code відчуваєш себе героєм мультика про крила і ноги – «краще день втратити, потім за дві години долетіти». Набагато частіше виходить навпаки.

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

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

У загальних рисах завдання було зрозумілим відразу – запустити Claude Code і перекладати через нього. На відміну від звичайного чату, йому можна показати файл і вказати, що перекладати його треба розділами, щоб не втрачати контекст. Але я вже звик починати вирішення завдань з «установчої» чат-сесії з LLM – як правило, витрачені десятки хвилин на такий мозковий штурм з формулюванням рішень обертаються солідною економією або навіть несподіваним розв'язанням проблеми зовсім з іншого боку.

Так вийшло і тут – Claude відразу сказав, що docx-файл це по суті архів з XML всередині (це я знав, тому і розраховував на успіх всієї справи) і додав, що всі текстові поля (ті самі виноски) там теж прописані. Тому процес нескладний – розпакувати файл, витягнути з xml всі елементи, перекласти їх текстовий вміст, замінити ним оригінальний вміст і запакувати назад.

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

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

У підсумку комплекс виглядав наступним чином:

• python-скрипт, що парсує docx-файл. Після його роботи в робочій директорії вийшов xml вихідного документа, вихідний текст кожного розділу в md-форматі, і json-файл, що містить дані про всі текстові написи.
• субагент translator, який отримував на вхід глосарій, md-файл для перекладу (або фрагмент json з текстовими блоками), перекладав і записував результат перекладу в такий же md-файл для кожного розділу.
• python-скрипт asseble_docx, який, як зрозуміло з назви, збирав перекладений контент в єдиний docx-файл.
• власне, сам Claude Code, який цим всім керував – запускав перший скрипт, передавав завдання субагенту, перевіряв виконання і запускав збирач. Це так зараз гладко описано, а насправді частина рядків залишилася неперекладеною, крім написів на картинках збірка ламалася на списках і таблицях – в цілому, кінцевий файл створювався приблизно 18 разів. Не рахуючи тестових запусків на парі розділів, перш ніж результат став близьким до правильного. Все одно залишилася деяка кількість проблем. Наприклад, українська мова в середньому довша за англійську, тому частину текстових боксів доведеться збільшувати вручну. Десь загубилося форматування жирним шрифтом тощо. Але це в цілому дрібниці, які набагато простіше виправити вручну.

Зате в сухому залишку маємо – технічний документ на 250 сторінок зі схемами й таблицями задовільно перекладений за 4 години, включаючи неквапливий мозковий штурм. Скільки днів/ тижнів пішло б на такий переклад живим перекладачем – навіть не хочу собі уявляти.

Цікаві завдання: переклад складного документа

Останні кілька тижнів у соцмережах несеться хвиля розповідей про Clawd (тепер вже Moltbot) – причому я спочатку запідозрив, що це якийсь флешмоб, оскільки в повідомленнях ніхто не давав посилань, зате демонстрували щойно придбані mac mini спеціально для цього. Довелося розбиратися самостійно.

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

Чесно кажучи, сам поки не тестував, оскільки не можу поки придумати відповідне завдання, а тут цілий клас завдань треба придумати. Я, як на гріх, тільки на тижні налагодив собі агента, який читає всі розсилки та робить мені дайджест, а це був би непоганий спосіб застосувати Moltbot.

А ось відповідь на питання «Навіщо ці захоплені зумери купують собі mac mini для запуску?» звучить несподівано – тому що на вайбі та хайпі. Хтось, може, і серйозно переконаний, що локальна модель впорається непогано – зрештою, постами про «Claude Code локально безплатно», де в підсумку пропонується взяти щось на кшталт Qwen 3 Coder 8B, забитий весь Twitter. А решті просто невідомо, що для роботи Clawd (він запускається в Docker-контейнері) достатньо 4 гігабайти пам'яті під базу, так що він цілком поміститься хоч у хмарі за $3-4 на місяць, хоч на старому ноутбуці зовсім безплатно.

Особистий AI-асистент Moltbot

Оскільки до заяв Деміса Гассабіса (Demis Hassabis) із Google DeepMind та Даріо Амодеї (Dario Amodei) з Anthropic ми, скоріше всього, будемо повертатимемося ще кілька місяців, то ось приблизний зміст їхньої дискусії в Давосі з Занні Мінтон Беддос (Zanny Minton Beddoes) із The Economist.

Центральною темою розмови стала розбіжність в оцінках швидкості технологічного прогресу. Амодеї підтвердив прогноз про появу моделей рівня Нобелівського лауреата до 2026–2027 років. Прискорення процесів він пов'язує з виникненням замкненого циклу, в якому AI починає самостійно писати код і проводити дослідження, покращуючи власні характеристики без участі людини. Гассабіс дотримується більш консервативної оцінки, прогнозуючи створення AGI до кінця поточного десятиліття з імовірністю 50%. Він згоден з успіхами в галузях кодингу та математики, але вказує на обмеження в природничих науках, де для верифікації гіпотез потрібні фізичні експерименти, які LLM не може провести.

У контексті корпоративної конкуренції представники компаній відзначили різні траєкторії розвитку. Амодеї повідомив про зростання виторгу Anthropic зі 100 мільйонів доларів у 2023 році до прогнозованих 10 мільярдів у 2025 році, стверджуючи, що домінуюче становище займуть компанії, керовані дослідниками. Гассабіс заявив про повернення Google лідерських позицій із випуском моделей Gemini 3 (о, як він правий!) і відновлення «стартап-культури» всередині корпорації після періоду відставання. Ключовим індикатором прогресу в наступному році обидва вважають здатність AI-систем до автономного самовдосконалення.

Обговорення впливу на ринок праці виявило консенсус щодо вразливості людей на ринку праці. Амодеї припускає зникнення до половини офісних вакансій початкового рівня в найближчі 1-5 років через те, що швидкість впровадження технологій перевищить адаптаційні можливості економіки. Гассабіс рекомендує фахівцям використовувати AI-інструменти для підвищення ефективності, щоб оминути стадію junior-розробки. У довгостроковій перспективі, після досягнення AGI, обидва прогнозують фундаментальний зсув, при якому економічні питання відійдуть на другий план перед питаннями призначення людини.

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

Дуже цікаве дослідження впливу прогресу LLM на професійну ефективність. У ньому взяли участь понад 500 фахівців (консультанти, аналітики даних, менеджери), які виконували профільні завдання з використанням однієї з 13 моделей різної потужності.

Ось що, коротко, виявилося.

Економічний ефект прямо залежить від технічних параметрів моделей. Кожен рік розвитку фронтир-моделей скорочує час виконання завдань в середньому на 8%. Десятикратне збільшення обсягу обчислень (при ізоляції впливу інших факторів) під час навчання призводить до скорочення часу виконання завдання на 6,3%. При цьому прогрес забезпечується як збільшенням потужностей (на 56%), так і якісно, зміною алгоритмів і даних.

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

При цьому завдання, не пов'язані з використанням агентів – тобто, умовно, одноходові завдання, – показали приріст заробітку на $1,58/хв. Аналогічний показник для agentic-завдань помітно скромніший – лише $0,34/хв.

Але найдивовижніше, що людям краще не втручатися. Якість відповідей моделей лінійно зростає зі збільшенням обчислювальної потужності. Топові моделі демонструють оцінки вище 6,0 з 7 (надлюдський рівень). А участь людини у виконанні завдання, хоча і покращує результати слабких моделей, але потужні моделі в середньому отримують середню оцінку (4,3 бала). Тобто, AI від людей тупішає.

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

Про вплив LLM на професійну ефективність

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

Чому це важливо

1. Культурний код: Перевірка використання питомо українських конструкцій (кличний відмінок, частки «ж», «бо», «адже»).
2. Якість контенту: Виявлення кальок та канцеляризмів, які роблять текст «штучним».
3. Гігієна мови: Запобігання масовій генерації суржику та забрудненню інфопростору.

Як проходила перевірка

Бенчмарк складається з трьох рівнів:

• Блок А: Тести з еталонними відповідями (виправлення помилок, переклад, завдання із ЗНО).
• Блок V: Автоматичний аналіз на наявність кальок (русизмів/англіцизмів) та українських маркерів.
• Турнір: Парні порівняння генерацій с обчислюванням Elo-рейтингу, де якість мови оцінюють відкалібровані моделі-судді.

Ключові результати (Січень 2026)

• Лідери: Найвищий ELO-рейтинг у GPT-5.2 та Claude Opus 4.5. Що правда, GPT досить часто використовує кальки (русизми), переважно синтаксичні.
• Чистота мови: Claude Opus 4.5 – єдина модель із нульовим показником кальок (найкраща для офіційних текстів).
• Open-Source: модель MamayLM (Gemma 12B), що дотренована з використанням українського датасета та токенізатора, посіла 6-те місце, випередивши значно більші моделі від Google та Anthropic. Інша модель українських розробників – Lapa – теж досить достойно виглядає.

Проєкт опубліковано на github (навіть можна поставити зірку), якщо є побажання – пишіть.

Тест LLM на краще знання української

Останні дні року у когось дуже напружені, а у мене зазвичай дуже спокійні та з'являється час для експериментів. Тому, коли я зустрів новину про українські бенчмарки для LLM, навіть порадів, що якраз є час погратися.

Ukrainian LLM Leaderboard – проєкт спільноти lang-uk для оцінки якості мовних моделей на українських бенчмарках. Лідерборд включає як стандартні тести (MMLU, GSM8K, HellaSwag, ARC), перекладені українською, так і унікальні українські бенчмарки – передусім ЗНО (географія, історія, мова і література, математика).

Наразі перше місце посідає MamayLM-Gemma-3-12B-IT – локалізована версія Gemma 3, дотренована на 75B токенів українських текстів командою INSAIT.

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

Лідерборд використовує lm-evaluation-harness з кастомними тасками. Стандартна конфігурація потребує доступу до logprobs моделі, тому тестування через більшість API неможливе.

Я адаптував конфігурацію для роботи з OpenAI-сумісними API, замінивши multiple-choice таски на generate_until з відповідним парсингом відповідей. Це дозволило протестувати моделі, недоступні для локального запуску. Хоча так, це трохи знижує точність та іноді виникають помилки парсингу.

Було протестовано дві моделі:

• Gemma 3 27B IT – більша модель від Google у порівнянні з лідером, але не локалізована
• Qwen3-30B-A3B – MoE-модель з 30B параметрів, але лише 3B активних

Результати

*Результат FLORES для Gemma 3 27B некоректний через проблеми з парсингом

Висновки

Гіпотеза 1: Чи можна взяти більшу LLM та досягти відповідної якості без локалізації?

Так, частково підтверджується. Gemma 3 27B без жодної українськомовної адаптації показує результати на рівні або краще за MamayLM-12B у більшості тестів на reasoning (MMLU, IFEval, ARC). Водночас локалізована модель зберігає перевагу у перекладі (FLORES) та культурноспецифічних завданнях (ЗНО мова і література).

Гіпотеза 2: MoE-архітектура компенсує менший розмір?

Не підтверджується. Qwen3-30B-A3B з 3B активних параметрів програє обом dense-моделям майже у всіх тестах, попри загальну кількість 30B параметрів.

Практичний висновок: Більші за кількістю параметрів моделі краще узагальнюють та краще справляються з задачами на reasoning. Якщо вам важливо, щоб модель мислила та розмовляла саме українською, то альтернативи локалізації немає – навіть більша модель, але без локалізації, буде мислити іншою мовою та виглядати як дуже розумний іноземець, з артефактами з іншої мови. А якщо вам потрібно, щоб модель знала локальні факти, то вони мають бути присутніми в датасеті або доступними через retrieval.

Схоже національна LLM таки має сенс

Дослідники з Університету Торонто (Gans & Goldfarb, NBER, січень 2026) ставлять під сумнів апокаліптичні прогнози щодо автоматизації. Їхній аргумент простий: більшість оцінок ризику базуються на припущенні, що завдання в професії незалежні одне від одного. Автоматизував 9 із 10 – втратив 90% роботи. Але реальність інша: завдання часто комплементарні, як деталі в механізмі. Якщо одна ланка слабка – весь продукт страждає.

Коли машина бере на себе рутину, працівник не просто «втрачає» ці завдання – він перерозподіляє свій час на те, що залишилося, і виконує це якісніше. Автори називають це «ефектом фокусування». Класичний приклад: банкомати не знищили професію касира – касири стали «relationship bankers», зосередившись на складних клієнтських взаємодіях. Те саме відбувається з радіологами, юристами, аналітиками.

Що це означає практично? Питання не в тому, чи може AI виконати якесь завдання, а в тому, де залишаються «вузькі місця», які люди закривають краще. Поки такі місця є – працівник може стати ціннішим, а не дешевшим. Іронічно, що саму статтю автори написали за допомогою ChatGPT 5.2 Pro та Claude Opus 4.5 – живий приклад власної теорії.

Щоправда, побоюватись є чого – якщо AI опанує всі елементи завдання, включаючи «вузькі місця», тобто почне їх виконувати краще за людину, то людина втратить всю роботу.

AI просто позбавить людей рутини?

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

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

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