Кент Бек — один із тих, хто задавав стандарти для сучасної розробки: Extreme Programming, TDD, JUnit, Agile Manifesto. У розмові в подкасті The Pragmatic Engineer він уже не захищає старі підручники, а намагається чесно розібратися, що робить із професією нова хвиля AI‑інструментів і «геніїв»‑LLM. Його головний діагноз звучить тривожно: ми накопичуємо код швидше, ніж накопичуємо довіру.
Код без довіри: що саме ми втрачаємо, коли промптимо генія
Бек формулює образ, який миттєво чіпляється: «ми накопичуємо код швидше, ніж накопичуємо довіру». І далі розкладає, що він має на увазі під цією довірою.
Для нього довіра народжується не в моменті, коли тест падає зеленим, а значно раніше — у процесі боротьби з доменом. Інженер бере складну бізнес‑ідею, довго мучиться з тим, щоб зрозуміти її сутність, поступово знаходить адекватне представлення в коді, доповнює це тестами, які демонструють: розуміння справді правильне. Ось тоді з’являється внутрішня впевненість: «я довіряю своїй програмі».
Це не лише технічна, а й соціальна історія. Коли двоє розробників сидять за однією клавіатурою, сперечаються про дизайн, разом полюють на баги, — між ними зростає людська довіра. Коли інженер спілкується з майбутнім користувачем і не просто «ставить кнопку», а раз по раз ставить питання: «яку проблему ви насправді вирішуєте?» — така взаємодія поступово вибудовує довіру вже між бізнесом і технічною командою.
Уся ця багатошарова робота над розумінням і стосунками зникає, якщо процес зводиться до короткого промпта в LLM. Бек карикатурно описує типовий сценарій: ми «даємо промпт генію, отримуємо finger guns, і геній каже: „все закінчено, бос“». Питання «а що саме означає „закінчено“?» лишається у повітрі.
У такому режимі немає боротьби за розуміння домену, немає спільного програмування, немає реального діалогу з користувачем. Є лише артефакт — шматок коду — і відсутність виробленої довіри до нього та одне до одного.
LLM пришвидшили розробку — але не пришвидшили бізнес
Бек визнає очевидне: з появою великих мовних моделей темп написання коду «однозначно прискорився». Він погоджується, що LLMи «просто дуже швидко пишуть код» — те, що раніше займало чимало часу і на друк, і на обдумування, сьогодні можна отримати за хвилини.
Але в цьому контрасті й схований конфлікт. У традиційній розробці друк коду — це не просто механіка. У цей час відбувається мислення: інженер цементує розуміння домену, моделює, переосмислює вимоги. Коли ж за нього пише LLM, ця частина роботи легко розчиняється.
Ще гостріше Бек бачить іншу асиметрію: «темп розробки однозначно прискорився… але темп бізнесу не прискорився, і цей дисбаланс ставатиме все очевиднішим». Процеси ухвалення рішень у великих компаніях, ланцюжки від саппорту до продакт‑менеджерів, маркетингу, sales і керівництва нікуди не зникли. Вони як були налаштовані на роки, так роками й мислять.
Бек наводить типовий сценарій: компанія платить 2 мільйони доларів на рік за SaaS‑продукт. Усередині хтось «вайб‑кодить» — швидко збирає заміну, яка краще відповідає специфічним потребам компанії і не коштує 2 мільйони щороку. Питання, яке цікавить Бека: «Як цей вендор буде на це реагувати?».
Раніше у постачальника було кілька років, щоб побачити, що клієнтам не подобається модуль за 2 мільйони, переосмислити продукт, відреагувати на загрозу. Тепер для деяких частин продукту це може статися за місяць — і не тому, що вендор раптом став гірше писати код, а тому що в його клієнтів з’явився інструмент швидкого «вайб‑кодування» альтернатив.
Вендор, теоретично, також може використати LLM, щоб пришвидшити розробку відповіді. Але бізнес‑процес, яким проходить визначення нових потреб, залишився старим, повільним і багатоступеневим. Машина вже стала Ferrari, а кермувати нею продовжують так, ніби це трактор.
Вайб‑кодинг і айсберги: чому заміна SaaS — це пастка
Бек фіксує ще одну тенденцію: люди почали масово «вайб‑кодити» верхівку айсберга, не бачачи, що під водою. І це загрожує серйозними «даунстрімними» проблемами.
Його опис простий: розробники — або навіть неформальні «напівтехнарі» — за допомогою LLM пишуть частину системи, яку добре бачать. Це може бути фронтенд, проста бізнес‑логіка, конвертація форматів — все, що легко описати словами і візуально сприйняти.
Ілюзія контролю виникає миттєво: «ось, у мене є код, він робить те, що я бачу, все працює». На цій хвилі ентузіазму люди «викидають решту айсберга» — тобто ігнорують частину системи, яка не на поверхні. Бек описує наслідок: «люди вайб‑кодять вершину айсберга, викидають решту айсберга і потім мають проблеми… ти отримуєш ці даунстрімні проблеми, про які навіть не знав».
Ці проблеми не завжди технічні в прямому сенсі. Часто це регуляторні вимоги, нюанси комплаєнсу, інтеграції з державними реєстрами, звітність у кількох юрисдикціях. Все те, що роками «вростало» в корпоративні системи, але майже не видно з точки зору простого UI чи одного запиту до API.
Бек наводить ситуацію з домену, який добре знає: у сфері payroll. Людина запитує LLM: у мене стільки‑то годин, така‑то ставка, ось податкова категорія — порахуй зарплату. Модель видає відповідь, і користувач робить висновок: «я не потребую спеціалізованого сервісу, я сам можу вести payroll». Бек пропонує експеримент: спробуйте таким чином прожити хоча б квартал, а потім розібратися з усіма формами й звітами для різних податкових органів, штатів чи країн. Те, що здається верхівкою айсберга (брутто та нетто зарплати), насправді спирається на величезну приховану масу правил і обов’язків.
LLM‑и дозволяють доволі достовірно відтворити вершину айсберга. Але вони не дають відчуття глибини системи — і саме це перетворюється на міну сповільненої дії.
Коли «геній» каже «готово» — а ніхто не знає, що це означає
У центрі критики Бека — саме інтерфейс взаємодії з LLM як із «генієм, що виконує бажання». Історія з «finger guns» — більше ніж жарт; це опис психології взаємодії.
У звичній інженерній роботі «готово» — це стан, який команда виробляє. Воно спирається на серію дрібних рішень: від юніт‑тестів і договорених критеріїв приймання до колективного розуміння домену й обговорення ризиків. Коли ж «готово» оголошує безтілесний «геній», у цієї декларації немає зрозумілого джерела авторитету.
Бек формулює це питання дуже прямо: «ми накопичуємо код швидше, ніж ми накопичуємо довіру… і нічого з цього не відбувається, якщо ми просто промптимо, отримуємо finger guns, і геній каже: „все закінчено, бос“. А що значить „закінчено“?».
Це не лише про формальні контрактні визначення «done». Йдеться про внутрішній стан інженера, який мусить бути готовий відповісти за наслідки роботи системи. Коли код писався вручну, співвідношення між авторством і відповідальністю було прямолінійним: той, хто писав, зазвичай і відповідає. У світі, де значну частину бізнес‑критичного коду «вигадує» LLM, але підпис під комітом — людський, моральна й професійна вага слова «готово» стає розмитою.
Бек не стверджує, що LLM‑и не можна або не треба використовувати. Він говорить про інше: якщо професія дозволить собі приймати «готово» від моделі, не переосмисливши, як тепер має будуватися довіра до системи, конфлікт між швидкістю коду й швидкістю довіри лише зростатиме.
Дисбаланс, який ставатиме все очевиднішим
Підсумовуючи свій погляд, Бек описує картину, в якій одночасно діють кілька сил.
По‑перше, технічна можливість створювати код зросла драматично — і продовжить зростати. Люди, які раніше не могли дозволити собі команду розробників, тепер «будують свої програми», так само як колись інженери з інших доменів масово прийшли в Smalltalk і створювали власні системи. Цей рух дає свободу і породжує інновації.
По‑друге, бізнес‑процеси, культури ухвалення рішень, системи відповідальності й комплаєнсу залишаються набагато інертнішими. Компанії, які звикли спиратися на високу вартість переходу й інерцію клієнтів, тепер можуть зіткнутися з тим, що ці «стіни» раптово зникли.
По‑третє, між цими шарами виникає напруження довіри. Користувачі — як технічні, так і бізнесові — ще не навчилися відрізняти, де LLM‑код справді достатній, а де замість системи отримали ретельно вимальовану верхівку айсберга без решти льодової глиби.
Бек, як і раніше, дивиться на цю ситуацію не як на кінець професії, а як на черговий цикл «експлорейшену», де старі плейбуки не працюють. Але попри оптимізм, його центральне попередження звучить ясно: без свідомої роботи над тим, як ми будуємо довіру — до коду, до колег, до користувачів, — нові «генії» лише пришвидшать накопичення технічного боргу, організаційних конфліктів і прихованих ризиків.
І в цьому сенсі формула «код росте швидше, ніж довіра» — не просто влучний твіт, а рамка, крізь яку доведеться дивитися на будь‑який AI‑інструмент у розробці.