Vibe coding чи Vibe engineering: де різниця?

💡 Усі статті, обговорення, новини про AI — в одному місці. Приєднуйтесь до AI спільноти!

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

І от на цьому фоні Саймон Віллісон, британський розробник та один із творців Django, запропонував інший термін — vibe engineer.

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

Тобто не «ШІ пише за мене», а «я використовую ШІ, щоб працювати швидше і масштабніше».

То що думаєте з приводу цього? Чи бачите ви різницю між vibe coding та vibe engineering у своїй роботі?

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

Типу приємніше робити, знімається когнітивне навантаження. Але це працює лише коли тру вайб кодиш — сів з якимось claude code і кодиш в стилі зроби мені це, а потім то, і ти тільик код ревьювиш. Тобто взагалі на розслабоні.

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

легше код писати ніж специфікації

Так. Перевіряв це на практиці.

З нуля написати проєкт — простіше реальним кодом, ніж його детальним описом.

А ось тесті генерувати чи якісь фрагменти коду (parse this JSON to POJO, щось таке), якісь підказки для себе — дуже класно.

і ти тільик код ревьювиш.

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

Зарплату теж нехай тоді у «вайбах» отримують. :-)

На скільки я памʼятаю, юристів чи лікарів, в яких є асистенти, не називають вайб юрист чи вайб лікар.
Не розумію для чого ці терміни. Просто в програмістів є нова тула — АІ асистент.

Нагадує часи перших мов програмування, і холівари що на асемблері код правильніший ніж на цьому вашому новомодному паскалі, чи то с++ )))))

Раньше копипастили с GitHub и Stack Overflow. Теперть это делает АИ. Вот и вся разница.

Одне іншому не заважає. Дейсь — вайб кодиш (щось не важливе, або тимчасове, або швидкий прототип), десь — вайб інженериш (всі інші випадки).

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

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

Колись комусь на голову впаде черговий Boeing 737max і ші почнуть забороняти)))

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

Тобто люди не можуть якусь чепуху написати?

просто словесна акробатика для тих кому некамільфо називати себе кодер єсічес )
Декого тригерить що вони «кодери»

Часом треба хякхяк, зробив і в продакшен, а іноді треба с толком с чувством с расстановкой

Але вайбкодер — це ж оксюморон. Вайбкодер же не кодить нічо )

Типу вайб-інженер краще? Типу вайб-інженер ніколи «не плюється», що воно не працює, чи що ШІ не те написав?...) Тепер «вайб-інженеру» треба значно більше написати функціоналу, щоб відпрацювати оплату. Краще ніж без ШІ, але...

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

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

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

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

І де тут «вайб»? Тут звичайний інжінірінг з використанням ШІ засобів.

Який «вайб» заслужили, такий і отримали :)

Для мене принципова різниця у відповіді на питання: «Чи зміг би цей „вайбер“ самостійно написати потрібний код чи ні?» Якщо відповідь «так, зміг би, а АІ просто зробив це швидше» — то це вайб інжиніринг, а людина — вайб інженер. А якщо «ні, не зміг би, тому звернення до АІ — було єдиним способом написати код для вирішення цієї бізнес-задачі» — то це вже вайб кодінг, а людина, відповідно — НЕ інженер.

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

О, точно. он отлично справляется для сдвинуться с места.

для мене LLM просто зменшує прокастинацію,

О таааак, реально, іноді так впадлу починати задачу, дав її ШІ, він щось висрав, думаєш «господи, що це за шлак, тут треба було отак, а це що за хрінь <виправляєш>» й оп, вже працюєш. Приємно що я не один такий )

Ще я помітив, що не завжди швидше виходить, але в цілому втома під кінець дня меньше, особливо для задач які ти добре знаєш що робити, але треба поколупатись в документації, бо вже забув як воно так робиться. Й більше сил залишається для високорівневих штук.

Так, дуже гарне гумове каченятко

Блін, я думав, я один так роблю — тупо знущаюсь з ШІ, яку фігню він пише :-D І він таки починає краще працювати :-D

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

Мене ChatGPT слухається, але його якось не надовго вистачає. Скажеш: не шукай мені будь-яке лайно російською. Він місяць пам’ятає, а потім забуває :)
Або скажеш: використовуй тільки надійні джерела інформації, він слухається, але на наступні 10-20 запитів. Потім знову починає тягнути в рота русняву та зелену брехню :)

В мене вже чатгпт підлаштувався під мої мати, вже й відповідає «ой, ссорі, тупанув» (дослівно), «за пизд*на приймаю, по ділу сказано» (теж дослівна цитата). Але це 4о, chatgpt 5 відповідає мемним «you’re absolutely right!»

Так-собі критерій.
Я майже все професійне життя пишу на С++, трохи на пайтоні.
Мені треба створити додаток з UI та розгорнути його в клауді. Ні UI ні роботу з клаудами я нормально не вмію, але вмію вайбкодити і знаю архітктуру, патерни, best practices і решту необхідного.
Я можу написати руками бекенд, навіть розбити це на мікросервіси і т. д.
Але я не вмію писати фронт і не вмію в деплоймент і решту девопсятини.

Я поспілкувався з Чатом, він нагенерив мені фронтенд і написав детальні інструкції по деплою. Бекенд я теж навайбкодив, ну але це чесно міг написати сам. В результаті ми за тиждень маємо повністю робочий проект, на який би раніше пішло 6 місяців і 3-5 різних колег.

Чи є я інженером в цьому кейсі?

Навайбкодив.

To be or not to be,

чи є я інженером в цьому кейсі?


— вайбженер, як компроміс між вибором серед женерів :)

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

Чи є я в результаті вайбкодер-юайщик + вайбдевопс? Можливо, мені якось пофіг на ці дефініції.

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

Це така ілюзія, як на мене. Робити в парі з LLM мені приємніше, тому я намагаються переконати себе що це ефективніше, коньяк корисний, ...

Зворотній приклад, налаштовував якусь фігню (NDA). Витратив два дні з різними LLM. Потім плюнув, погуглив, знайшов гарну статтю, все розписано, зробив за дві години. Але, якщо припустити, що наприкінці другого дня воно б запрацювало, то психологічно мені було б дуже комфортно вважати, що без LLM я би займався цим два тижні!

Для мене робота з ЛЛМ це та роль архітектора, навіть дерижера, про яку я завжди мріяв.
Задизайнив систему, скормив промтики із необхідним контекстом, згенерувало один модуль, інший, наваяв UI, підняв інфраструктуру, все робе.
На крайняк згодував повідомлення про помилку чи сконфігурував новий промт із уточненнями, воно миттєво поправило код і стала цукерочка.
Щось в процесі створення такої системи я розумію краще, щось гірше, щось міг би створити сам, щось ні( ну точніше все міг би сам, але на то пішли б години і дні гуглинга і читання ).

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

У мене навпаки. LLM це прекрасний архітектор, але на рівні бла-бла-бла, який нічого не може закодити, щоб щось не зламати. Що в принципі зрозуміло, наприклад, коли подивитися на чемпіонат LLM з шахів: гарне обґрунтування, але тактика на нулі.

Я пишу гру футбол на листі паперу з Claude Code. Там була проблема, що зациклювання в серії пенальті інколи створювали цикли, з яких AI ніяк не виходив. Я почав писати детектор циклів, розʼяснив як він має працювати, взяв гру з бази, де виникла така ситуація, та сказав, що тут цикл виникає на десятому кроці. Вона чомусь впиралася: ви не праві, тут цикл виникає на дев’ятому кроці. Я намалював на папері. На десятому. Сказав, що перевірив. Вона простиню тексту з ручним трасуванням, що на дев’ятому. Я попросив написати скрипт на Python з прототипом. Вона написала, й така: «Ваша інтуїція спрацювала brilliant, цикл дійсно на десятому кроці!»

Це в принципі показує всю небезпеку, тому що прорахуватися вона може майже будь-де, ну може окрім зовсім тупого перекладання з JSON в базу.

Я бачу твій комент так: «Я думав, що АІ мені все зробить, а він без мене робить не так, як я хочу».

Як тут вже хтось писав, АІ це просто ще один з інструментів в твоєму тулсеті, а не заміна тебе, принаймні поки що.
Навіть самий швидкий болід формули 1 потребує пілота, який буде його направляти і казати, де газувати, а де повертати.

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

Головні проблеми: треба розібратися з кодом та перевірити на помилки. Простіше написати. Плюс часто треба думати як виправити помилки, інколи ти чогось не помічаєш. Інколи довіряєш (код тупий помилитися неможливо). Але на ревʼю можеш помітити тупі помилки, щось може дільне ляпнути, а може в молоко.

При навчанні дуже корисний, можна обговорити, задавати тупі питання (може помилятися у конкретних речах, але на рівні бла-бла-бла пристойно).

З однієї сторони — добре. А з іншої — в результаті програміст отримає приблизно таку ж оплату за тиждень, яку за тиждень отримав би і раніше. А потім — просто іншу роботу буде виконувати. Тобто реальна вигода під питанням для програмістів.
А далі — ШІ буде писати все і програмісти в принципі будуть не потрібні.)
[А зараз же ті 3 програмісти кілька місяців будуть сидіти без роботи, або ж працювати за копійки і створять вам же конкуренцію. Типового програміста зараз досить просто замінити на іншого.]

реальна вигода під питанням для програмістів

Розглядайте програмістів (як і ШІ нп), в якості інструменту для вирішення якихось задач. Задачі не вони ставлять, їм ставлять завдання, тобто вони (умовно скажемо) також «інструмент» для вирішення завдань.
З цієї точки зору — вигоди для «інструменту» — це питання далеко не на перших позиціях для тих хто користується «інструментами», по ідеї десь так.

Я не питав порад, як мені розглядать.

Як трохи інженер і трохи науковець я бачу ситуацію з ШІ з різних боків.
ШІ не замінить програмістів, не зможе писати все, із багатьох причин цього не станеться, на наш вік ще вистачить роботи.
Тут мова не йде про якісь позиції, де треба було писати якісь прості скрипти( колись, в далекому 2010, моя перша робота на 2 курсі універа звучала як HTML-верстальщик, є зараз такі вакансії? ), такі позиції зникнуть, але там, де треба буде працювати над рішенням / фічою / модулем з різних боків і на різних етапах, починаючи від збору вимог і до деплою в прод або хоча б в Дев енв, такі позиції будуть і їх кількість тільки буде рости.

Стосовно того, добре чи погано це для програміста який виконує роботу в соло на яку раніше треба було 2-3 людей і в рази більше часу — так, це добре, знову ж таки, з різних причин.
З очевидного — програміст підвищує свою цінність для компанії і цінність себе на ринку, розширює свою ’T-shape model’ і через різносторонню обізнаність, об’єктивно, росте як спеціаліст.

Стосовно того, що типового програміста легко замінити, тут диявол буде в деталях.
Що таке типовий прогріміст?
Який скіллсет у нього? Які навички, досвід, доменна експертиза і т.д.
Якщо маєте на увазі, що будь-хто може написати промт до ЛЛМ і отримати якийсь згенерований код, то це ж лише початок шляху. Це код треба примусити запуститись і впевнитись, що робить саме те, що треба. Ось тут вже людина радикально виграє в ШІ і тут вже починаються розбіжності між рядовими програмістами.
Хоча в той же час, завжди можна було замінити будь-кого.

P.S. Я погуглив і щиро здивувався, що у 2025 році все ще існують вакансії html верстальщиків.
Ось це реально ШІ може замінити.
Якщо навіть такі вакансії лишились, то решта ІТ з дуже великою ймовірністю лишиться також.

Що таке типовий прогріміст?

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

Як трохи інженер і трохи науковець я бачу ситуацію з ШІ з різних боків.

Я теж знаю як працюють моделі ШІ. І розумію, що ШІ потрібно пояснити всі фічі у програмі, які повинні бути. Але це(теоретично) може зробити і той, хто не вміє програмувати.
Далі. Беремо кілька агентів. Один пише код. Другий перевіряє код по архітектурі. Третій по рефакторингу. Четвертий запускає і тестує. І всі вони дають фідбек першому. Навіть при нинішньому рівні моделей ШІ типу ChatGPT підозрюю що вже можуть писати зовсім прості програми досить адекватно.
А ШІ ще тільки на початковому етапі свого розвитку.

ШІ не замінить програмістів, не зможе писати все, із багатьох причин цього не станеться, на наш вік ще вистачить роботи.

Якби ж воно так було.

Дайте мені рік на підготовку і я напишу будь-який функціонал програми, яку ви можете написати

Або напишите, або не напишете. Я теж можу сказати, дайте мені 10 років на підготовку і я стану гросмейстером. Або стану, або не стану.

ШІ потрібно пояснити всі фічі у програмі, які повинні бути.

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

Далі. Беремо кілька агентів. Один пише код. Другий перевіряє код по архітектурі. Третій по рефакторингу. Четвертий запускає і тестує. І всі вони дають фідбек першому.

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

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

Або напишите, або не напишете. Я теж можу сказати, дайте мені 10 років на підготовку і я стану гросмейстером. Або стану, або не стану.

Не треба бути «гросмейстером», щоб успішно писати 95% програм до рівня, щоб їх можна було нормально використовувати. (В цьому суть)
В результаті, якщо один програміст не захоче писати код, то можна знайти іншого чи інших. (Так, можливо з більшими в рази затратами)

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

Невже ШІ не можна навчити абстракції? Або ж ділити проект на менші частини(як ви і написали). Для перебору, потрібно, щоб модель не лізла у певні сценарії, які вже раніше продивилась. Теоретично, у нейромережу можна додати можливість зменшувати ваги у певної групи вузлів. (щоб нейромережа знову туди не полізла). З цим може бути складність. Але це теж можна вирішити.

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

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

Невже ШІ не можна навчити абстракції?

Абстракції запросто, проблема якраз у конкретиці. Припустимо, що ШІ виконує елементарний крок з надійністю 99%. Тоді 10 кроків поспіль це 90%, 50 кроків це 60%, 1000 кроків це 0.005%.

Так, я впевнений, що LLM можна навчити, але проблема в навчальних даних, їх просто немає у правильному вигляді. Ми маємо чистовики, з яких викреслено невдалі спроби, перерівки, червоні прапорці. Тому LLM бачить тільки фінальний результат і намагається вгадати відповідь одразу, замість того щоб йти покроково: зробив, передивився, перевірив, зробив крок назад, ... Для LLM фактично простіше написати скрипт та виконати його, ніж виконувати «в умі». tool use працює набагато краще за pure reasoning.

Тут треба зібрати навчальні дані, то обʼємна задача, і то не факт, що запрацює. Є варіанти reinforecement learning, але тут як раз невідомо як вийде.

Абстракції запросто, проблема якраз у конкретиці. Припустимо, що ШІ виконує елементарний крок з надійністю 99%. Тоді 10 кроків поспіль це 90%, 50 кроків це 60%, 1000 кроків це 0.005%.

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

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

Для цього треба вчити модель оцінювати саму задачу. Щоб зрозуміти робити її покроково чи відразу. По дефолту задача, напевно, спочатку повинна розглядатися, як багатокрокова. А, якщо задовольняють певні умови, то тоді можна робити за один крок.
Тобто треба змушувати модель робити покроково, а не вгадувати.

Для LLM фактично простіше написати скрипт та виконати його, ніж виконувати «в умі». tool use працює набагато краще за pure reasoning.

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

В ШІ така кількість грошей заливається, що складно уявити, що вони не знайдуть за кілька років, потрібні рішення.

Щоб з цим боротися потрібно на кожному кроці перевіряти відповідь на адекватність. Щоб підвищувати ймовірність правильної відповіді.

Ой, якби це було так, то всі давно би так робили. З точки зору теорії надійності це не покращує ситуацію, бо це послідовний зв’язок — надійності перемножуються. Якщо перша має 0.9, друга 0.9, то разом буде 0.81, а не 0.99.

Тобто треба змушувати модель робити покроково, а не вгадувати.

Хто це має робити? Тут теж можна помилитися навіть людині. Я згоден, що те що можуть вирішувати LLM, треба давати LLM. Що не можуть треба робити самому. От тільки як відрізнити?

В ШІ така кількість грошей заливається, що складно уявити, що вони не знайдуть за кілька років, потрібні рішення.

А в термояд скільки? Коли буде? Тут також можливо ми на фундаментальної межі того, можливо буде прорив. Якщо брати шахи, то Leela Zero вийшла майже на плато.

Ой, якби це було так, то всі давно би так робили. З точки зору теорії надійності це не покращує ситуацію, бо це послідовний зв’язок — надійності перемножуються. Якщо перша має 0.9, друга 0.9, то разом буде 0.81, а не 0.99.

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

Ні, теорема про відсутність безкоштовних обідів (free lunch theorem) забороняє такі фокуси. Закон, полігон, самогон, ветрогон та просто гон. Ми не можемо покращити кращу модель через гру в наперстки.

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

про відсутність безкоштовних обідів

буде працювати, якщо одні і ті ж дані(промпти) і одна й та ж модель.

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

буде працювати, якщо одні і ті ж дані(промпти) і одна й та ж модель.

Ні, скоріше про те, що ми не можемо покращити кращу модель. Так, можемо заточити під наш датасет. Можемо якось вирівняти. Наприклад, є модель, яка дає 95%, але плутає людей та свиней. Є модель, яка дає 90% але не робить цю помилку. Можна оркестрацією отримати систему, яка буде давати 94% та не припускатися цієї помилки. З точки зору датасету конкретного клієнту (скотоферма) це може бути неабияким бустом. Але формально це оптимізація під інший розподіл даних.

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

Ні, скоріше про те, що ми не можемо покращити кращу модель.

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

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

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

Знову ж таки якщо у нас є навчальні дані, то простіше перенавчити на них модель.

Тут треба зібрати навчальні дані, то обʼємна задача, і то не факт, що запрацює. Є варіанти reinforecement learning, але тут як раз невідомо як вийде.

По ідеї модель сама під час навчання повинна перевіряти які дані 99.(9)% вірні, а які ні. Тобто годуємо всі дані моделі при навчанні, а вона сама обирає вірні. (або ж починати вчити на аксіомах(на 99.9% вірних даних), а вже потім давати все підряд(щоб модель сама фільтрувала) — так вийде значно швидше навчити)

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

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

Ще раз, модель не може, треба зовнішній агент. Наприклад, можна брати мови програмування зі залежними типами, там математичний доказ це об’єкт мови, і тоді компілятор не пропустить неправильний доказ, і тоді ми можемо використовувати beam search та мати принаймні коректний код на виході. Але це складно і я цього не бачу.

Можна відкидати код, який не пропускає статичний аналіз, це дуже відчувається, як на мене, бо моделі дуже неохотно генерують код проти існуючих практик, та часто додають код із серії make compiler happy, плюс дуже багатослівний код за замовчуванням. Але це дуже обмежено.

Або ж ділити проект на менші частини(як ви і написали).

Проблема в тому, що ніхто цього не вміє робити ідеально. Вся історія інженерії розробки саме про це. Всі методології по суті вчать, як розбивати на менші частини: модулі, пакети, інкапсуляція, невеличкі класи в Smalltalk, мікросервіси.
Але це просто перенесення складності з одного рівня на інший: або у нас метод на 1000 рядків, у якому розібратися нереально, або у нас 1000 простих класів чи мікросервісів, і тоді незрозуміло, як вони взаємодіють між собою.
І кожен новий проєкт розробники починають з мріями про елегантну архітектуру (читай: незалежні невеличкі зрозумілі частини). А закінчують legacy-кодом. І тут питання, а чи це можливо взагалі? Та й звідки брати навчальні дані як це робити?

І тут питання, а чи це можливо взагалі?

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

Я під час кодингу генерую кілька варіантів і обираю найкращий.

Це є оркестрація. Зазвичай там дуже невеличкий виграш.

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

LLM показують такі проблеми: (1) ламають існуючий функціонал; (2) підганяють тести під результат. Майже ніколи не намагаються розібратися. Впав тест? Добре, замінимо більше дорівнює на строго більше. Замість того, щоб побудувати ланцюг міркувань та отримати свідчення, що дійсно має бути строго більше.

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

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

Ми впроваджували AI-Assisted Coding у команді з понад 500 інженерів і дуже швидко стало зрозуміло, що це не просто «дати промпт і отримати код». Насправді це еволюція, яка проходить кілька чітких стадій.

— Перша стадія була автокомпліти, з яких усе почалося. Наприклад, GitHub Copilot. Це був старт, коли AI просто допомагав швидше писати код та не всім.

— Друга стадія — це AI Chat-помічники, такі як Cursor або Windsurf, які дозволяють спілкуватися з моделлю безпосередньо в IDE, уточнювати контекст, писати тести, оптимізувати фрагменти, фактично співпрацювати з ШІ в реальному часі.

— Третя стадія зараз це Agentic AI Coding, який ми бачимо у рішеннях на кшталт Cloud Code. Тут модель вже бере участь у плануванні, розбиває задачі, координує кроки і частково самостійно виконує їх. (Насправді багато хто додав це в AI Chat також)

Тому, чесно кажучи, не зовсім розумію, навіщо вигадувати нові терміни на кшталт "vibe engineering"🙂. Як на мене, краще просто визнати, що це абсолютно нова навичка.

Та незалежно від того, ви Senior, Staff чи Principal Engineer ми всі починаємо з нуля. І потрібно заново вибудовувати підходи, процеси й отримувати компетенції ефективної роботи з AI.

Головне зараз, я вважаю, не в тому, як назвати процес, а в тому, як швидко адаптуватися і зрозуміти принципи Agentic AI, щоб використовувати його максимально ефективно у своїй розробці. (Наш рекорд був в пришвидшенні створення компонентів на фронтенді в 8 разів за допомогою Agentic AI та MCP інтеграції.)

Головне зараз

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

Тут зараз найбільші виклики не прикрутити ще одного агента, а якісно покращити «мета-програмування», а саме роботу з вимогами, архітектурою, definition of done, аналітикою і т.д.
А з цим завжди була проблема в «Класичній розробці».

АІ дозволяє дуже швидко кодити, валідувати гіпотези і т.д. Але ти маєш знати, що саме ти хочеш отримати і що саме провалідувати.

АІ дозволяє дуже швидко кодити, валідувати гіпотези і т.д. Але ти маєш знати, що саме ти хочеш отримати і що саме провалідувати.

Так проблема програмування у тому, що ти цього не знаєш, доки не напишеш. Саме тому й не працюють водопади, та популярний agile.

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

Плюсую. У мене теж було саме 3 описані стадії.)

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

Гроші друкують швидко. Просо овни так і залишаються в акціях а не йдуть до людей.

Vibe coding стало мати негативні іконотації — треба придумати новий термін!

Як казав один персонаж з гри Expedition 33: “I’M SPEED!!!” та “ACCELERATION!”

Термін Vibe coding взагалі безобідний, він просто описував написання коду з допомогою чатгпт, щоб можна було отримувати частину коду через промт. Він взагалі не виключав людину із процесу і ніколи не мав на увазі написання цілого софту на 100% лише з допомогою промтів в чатгпт.

Це ШІ дисиденти почали добавляти негативні ікотонації і додумувати неіснуючі сценарії щоб поржати і почесати своє ЧСВ типу «ага, продукт менеджмент вайб кодер, зараз напише а нам інженерам розгрібати». Ні, вайб кодинг для інженерів і ввів термін інженер (Карпати, який далеко не продукт).

так-с. я все ще жду вайб-архітекторів, вайб-тестерів та вайб-менеджерів! НЕДОПРАЦЬОВУЄТЕ! :D :D :D

2-3 тижні і все буде :)))

Підписатись на коментарі