У час, коли GitHub Copilot, Claude Code та інші AI-асистенти пишуть цілі модулі за один запит, у багатьох інженерів виникає тривожне запитання: чи не знецінюються класичні навички розробки? Британський інженер і викладач Метт Поко́к, автор курсу «Claude Code for Real Engineers», пропонує радикально протилежну відповідь. На його думку, базові принципи програмної інженерії сьогодні важливіші, ніж будь-коли раніше — саме тому, що AI став настільки потужним.
Йдеться не про ностальгію за «старими добрими часами», а про тверезий аналіз того, як великі мовні моделі взаємодіють із реальними кодовими базами. AI здатен прискорити розробку, але так само здатен перетворити проєкт на некерований клубок залежностей у рази швидше, ніж це зробила б будь-яка людська команда. Ключова різниця — у процесі, як саме інженери застосовують інструменти, і в тому, наскільки глибоко вони розуміють фундаментальні поняття складності, ентропії та якості коду.
«Specs to code»: привабливий, але руйнівний анти-патерн
Одним із найяскравіших символів нової хвилі AI-розробки став підхід «specs to code». Його прихильники пропонують майже фабричну модель: інженер пише специфікацію, AI генерує код, а коли щось не працює — змінюється лише спека, і модель знову «перекомпілює» систему.
На папері це виглядає як мрія менеджера: розробники працюють на рівні вимог, а не реалізації, код «дешевий» і завжди може бути перегенерований. На практиці, як показує досвід Поко́ка, цей підхід швидко перетворюється на машину з виробництва сміттєвого коду.
Він описує типовий цикл: перша генерація дає більш-менш прийнятний результат. Друга — вже гірша. Третя — ще заплутаніша. Кожен новий прогін «компілятора» на базі LLM не очищує систему, а додає до неї нові шари випадкових рішень. Замість еволюції архітектури виходить накопичення хаотичних змін.
Ключова проблема в тому, що такий процес заохочує повне ігнорування коду як об’єкта дизайну. Кодова база перетворюється на побічний продукт, який ніхто не читає, не рефакторить і не осмислює. Це не революційний новий підхід, а стара ідея «генерації коду за моделями» в гіршому, прискореному варіанті. Поко́к прямо називає це «v-coding під іншим ім’ям» — натякаючи на давні спроби відокремити дизайн від реалізації настільки, що код стає майже непрозорим артефактом.
У результаті AI не просто не знімає проблему складності — він її підсилює. Кожен новий цикл генерації додає ще трохи заплутаності, ще кілька прихованих залежностей, ще одну ділянку, яку страшно чіпати.
Складність як ворог: Остергаут і небезпека AI-посиленої заплутаності
Щоб зрозуміти, чому «specs to code» так швидко заводить проєкти в глухий кут, Поко́к звертається до класичної роботи Джона Остергаута «A Philosophy of Software Design». Остергаут пропонує чітке й практичне визначення складності: це все, що в структурі програмної системи ускладнює її розуміння та модифікацію.
У цій оптиці «поганий код» — не обов’язково некрасивий або неідеоматичний. Поганий код — це код, який важко змінювати без ризику зламати щось ще. Добрий код, навпаки, легко піддається змінам: інженер може додати функцію, виправити дефект або змінити поведінку, не боячись каскаду неочікуваних побічних ефектів.
AI-генерація без контролю якраз і створює той тип складності, про який попереджає Остергаут. Модель не має інтуїції щодо «вартості» додаткового шару абстракції, ще одного параметра, ще однієї умовної гілки. Вона оптимізує локально: задовольнити поточний запит користувача, пройти тести, зібратися без помилок. Глобальна простота системи при цьому не є її ціллю.
Коли інженер не читає й не коригує цей код, складність накопичується непомітно. З’являються модулі, які ніхто не розуміє повністю, функції з прихованими побічними ефектами, неочевидні залежності між частинами системи. І саме тут вступає в гру ще одна класична ідея — програмна ентропія.
Ентропія коду в епоху LLM: як AI прискорює природний розпад систем
«The Pragmatic Programmer» описує явище, знайоме кожному досвідченому розробнику: програмна ентропія. Будь-яка кодова база, до якої регулярно вносять зміни, має природну тенденцію до деградації. Кожен патч, кожен «тимчасовий» обхід, кожне локальне рішення, прийняте без урахування загального дизайну, трохи погіршує структуру системи.
У традиційній розробці цей процес відносно повільний. Людські команди обмежені часом, ресурсами й власною здатністю тримати в голові складні системи. AI знімає ці обмеження в одному критичному аспекті: він може генерувати величезні обсяги коду майже миттєво.
Поко́к використовує концепцію ентропії саме для опису того, що відбувається, коли AI вбудовують у процес без достатніх запобіжників. Кожна «дрібна» зміна, згенерована моделлю без урахування загальної архітектури, додає трохи безладу. Коли таких змін сотні або тисячі, ентропія зростає лавиноподібно.
У підході «specs to code» це особливо помітно. Замість того щоб обережно вносити точкові зміни, модель щоразу перегенеровує великі фрагменти системи. Кожен прогін — це шанс не лише виправити дефект, а й ненавмисно змінити поведінку в інших місцях, додати нові залежності, зламати раніше стабільні частини.
Класичні поради з «The Pragmatic Programmer» — думати про дизайн системи, уникати «битого вікна» у вигляді залишеного без виправлення поганого коду, підтримувати чистоту архітектури — в епоху AI стають не менш, а більш актуальними. Тепер будь-яка недбалість множиться швидкістю генерації коду.
Міф про «дешевий код»: чому поганий код став дорожчим, ніж будь-коли
Одним із гасел, що підживлюють AI-оптимізм, стало твердження «code is cheap» — код дешевий. Мовляв, якщо модель може за хвилину написати те, на що раніше йшли години, то вартість коду як ресурсу різко впала. Поко́к категорично не погоджується з цим.
Його теза: поганий код сьогодні дорожчий, ніж будь-коли. Причина проста й водночас неприємна: AI здатен генерувати величезні обсяги низькоякісного коду з небаченою швидкістю. Якщо раніше команда могла роками повільно «засмічувати» проєкт, то тепер той самий ефект досягається за місяці або навіть тижні.
Вартість коду не вимірюється кількістю рядків чи годинами, витраченими на написання. Вона проявляється в тому, скільки коштує змінити систему через рік, два, п’ять. Скільки часу займає онбординг нового розробника. Скільки ризику закладено в кожен реліз. Скільки грошей компанія втрачає через неможливість швидко адаптувати продукт до ринку.
AI не скасовує цих витрат, а збільшує їх, якщо кодова база деградує. Коли система стає важкою для розуміння, навіть найпотужніша модель починає давати гірші результати. Вона плутається в суперечливих патернах, не може побачити чітку структуру, генерує ще більше «латок» поверх уже крихкої архітектури.
У цьому сенсі твердження «код дешевий» виявляється небезпечним самообманом. Дешевим став лише акт генерації тексту, схожого на код. Справжня вартість — підтримка, еволюція, надійність — нікуди не зникла. Навпаки, вона зростає, коли система наповнюється погано продуманими фрагментами, створеними без розуміння загального дизайну.
Як якість коду множить ефективність AI
Один із найважливіших висновків Поко́ка стосується того, як AI поводиться на різних типах кодових баз. На добре структурованих, чистих проєктах моделі працюють «неймовірно добре». На заплутаних, хаотичних — значно гірше.
Це спостереження руйнує ще один прихований міф: що AI нібито здатен «підняти» будь-який спадкований код до прийнятного рівня. Насправді ж модель, як і людина, сильно залежить від якості контексту, в якому вона працює. Якщо архітектура чітка, модулі мають зрозумілі межі, назви послідовні, а залежності прозорі, AI може:
генерувати зміни, які природно вписуються в існуючу структуру;
легше знаходити правильні місця для нової логіки;
краще використовувати типи, тести й інші сигнали якості.
Якщо ж кодова база — це суміш стилів, випадкових рішень і прихованих зв’язків, модель починає відтворювати цей хаос. Вона «вчиться» на локальних патернах, які самі по собі погані, і продовжує їх. У результаті кожна нова зміна ще більше ускладнює систему.
Це створює парадоксальний, але логічний ефект: інвестиції в класичні інженерні практики — дизайн модулів, чіткі інтерфейси, послідовну термінологію, рефакторинг — прямо підвищують віддачу від AI-інструментів. Якість коду стає множником ефективності моделей. Чим краща база, тим більше користі приносить AI. Чим гірша — тим швидше він її добиває.
Звідси й головний висновок Поко́ка: «добрі кодові бази важать більше, ніж будь-коли, а отже, софтверні основи важать більше, ніж будь-коли». AI не замінює фундаментальні принципи, а робить їх критично важливими для виживання проєкту.
Спільний дизайн-концепт: чому AI «не робить те, що ви хотіли»
Окрема категорія проблем, яку сьогодні відчувають майже всі, хто працює з LLM, — це розрив між очікуваннями й результатом. Інженер має в голові чітке уявлення про те, що потрібно, але AI генерує щось зовсім інше: іншу архітектуру, інші компроміси, інші деталі.
Поко́к пояснює це через концепцію «design concept» Фредеріка Брукса. Коли над системою працює більше ніж одна людина, між ними існує невидима спільна ідея того, що саме будується. Це не документ, не діаграма й не файл зі специфікацією. Це радше колективна ментальна модель — те, що Брукс називає дизайн-концептом.
У взаємодії з AI виникає та сама проблема, що й у командній роботі: модель не поділяє з розробником спільної дизайн-концепції. Вона бачить лише текст запиту й фрагменти коду, але не має глибинного розуміння того, які компроміси прийнятні, які патерни бажані, які — табуйовані.
Щоб подолати цей розрив, Поко́к створив просту, але показову «навичку» для AI — промпт під назвою «grill me». Його суть: змусити модель не поспішати до генерації коду, а спочатку «допитати» розробника до стану справжнього спільного розуміння. Інструкція звучить приблизно так: «Інтерв’юй мене безжально щодо кожного аспекту плану, поки ми не досягнемо спільного розуміння. Пройдися по кожній гілці дерева дизайну, розв’язуючи залежності між рішеннями одне за одним».
Результат — десятки, а іноді й сотня уточнювальних запитань від AI, перш ніж він візьметься за реалізацію. Модель перетворюється на своєрідного «адвоката диявола», який змушує розробника проговорити й осмислити дизайн-концепт. Цей процес не просто покращує якість плану — він створює спільний ментальний простір, у якому AI і людина працюють як справжні співдизайнери.
Показово, що репозиторій із цією навичкою зібрав близько 13 тисяч зірок на GitHub — явна ознака того, що проблема спільного розуміння з AI болить багатьом. Поко́к навіть стверджує, що такий підхід кращий за стандартний «plan mode» у Claude Code, який надто поспішає створити артефакт — план або код — замість того, щоб спочатку досягти глибокої узгодженості.
Цей приклад ще раз підкреслює: фундаментальні ідеї з класичних книжок — від Брукса до Остергаута — напряму застосовні до роботи з AI. Різниця лише в тому, що тепер «другий дизайнер» — це не людина, а модель.
Спільна мова з AI: як зменшити багатослівність і підвищити точність
Ще одна типова скарга на AI-асистентів — надмірна багатослівність і відчуття, що ви «говорите різними мовами». Модель пояснює очевидне, плутається в термінах, використовує інші назви для тих самих понять, що й команда. У результаті план і реалізація розходяться, а діалог стає виснажливим.
Поко́к бачить у цьому знайому ситуацію з класичної розробки: взаємодію програмістів із доменними експертами. Коли інженер будує систему, скажімо, для виробництва мікрочипів, а сам нічого не знає про цей домен, між ним і експертами виникає мовний розрив. Вони використовують терміни, які йому незрозумілі, він перекладає їх у код, який незрозумілий їм.
Domain-Driven Design (DDD) давно пропонує рішення цієї проблеми — «ubiquitous language», або повсюдна мова. Ідея проста: усі розмови між розробниками, доменними експертами й навіть структура коду мають спиратися на єдину, чітко визначену модель термінів. Це не просто глосарій, а жива мова проєкту, яку всі учасники використовують послідовно.
Поко́к переносить цю ідею у взаємодію з AI. Він створює навичку, яка сканує кодову базу, витягує ключову термінологію й формує markdown-файл із таблицями термінів і визначень — фактично, файл ubiquitous language. Цей документ потім передається моделі й використовується самим розробником під час «допитів» у стилі «grill me» та планування.
Ефект подвійний. По-перше, AI починає мислити менш багатослівно: замість довгих описів він оперує вже узгодженими термінами. По-друге, реалізація стає ближчою до плану: модель використовує ті самі поняття, що й у вимогах, і вплітає їх у код послідовно.
Це не магія, а пряме застосування старої ідеї DDD до нового контексту. Але саме такі «мости» між класичною інженерією та AI роблять різницю між хаотичною генерацією коду й дисциплінованою співпрацею з моделлю.
Фідбек як межа швидкості: чому AI «обганяє власні фари»
Навіть коли AI і розробник досягли спільного розуміння й говорять однією мовою, залишається ще одна пастка: код «не працює». Тести падають, типи не сходяться, UI поводиться не так, як очікувалося. Здавалося б, розв’язання очевидне — додати більше зворотного зв’язку: статичні типи, доступ до браузера для фронтенду, автоматизовані тести.
Поко́к наголошує: усі ці фідбек-цикли справді критично важливі. Якщо ви будуєте веб-додаток і не даєте LLM доступу до браузера, вона буквально «працює наосліп». Якщо ігноруєте TypeScript або інші системи статичної типізації, позбавляєте модель потужного сигналу про помилки. Якщо немає тестів, немає й об’єктивного критерію правильності.
Але навіть за наявності цих інструментів AI часто використовує їх погано. Моделі мають схильність робити «занадто багато за раз»: генерувати великі шматки коду, а потім лише побіжно проганяти типчекер або тести. Це прямо суперечить порадам із «The Pragmatic Programmer», де автори попереджають про небезпеку «out-running your headlights» — рухатися швидше, ніж дозволяє ваш горизонт огляду.
Книжка формулює просте правило: швидкість вашої розробки обмежена швидкістю зворотного зв’язку. Якщо ви отримуєте фідбек повільно, але змінюєте систему великими порціями, ви неминуче будете часто помилятися й витрачати час на виправлення.
AI за замовчуванням не дотримується цього принципу. Він не має інстинктивного страху перед великими дифами, не відчуває болю від дебагу. Тому розробник має нав’язати моделі дисципліну дрібних кроків. Поко́к бачить у цьому ще одну причину повернутися до класики — до тест-орієнтованої розробки (TDD), яка примушує рухатися маленькими, перевіреними кроками: спочатку тест, потім мінімальна реалізація, потім рефакторинг.
Цікаво, що він підкреслює: тестування завжди було складним. Вибір розміру юніта, рішення про те, що мокати, які поведінки перевіряти — усе це вимагає досвіду й розуміння дизайну. AI тут не чарівна паличка, а ще один учасник, якого потрібно навчити працювати в межах цих обмежень.
І знову виходить, що саме класичні інженерні навички — розуміння фідбек-циклів, уміння будувати хороші тести, здатність розбивати задачі на дрібні кроки — визначають, чи стане AI вашим прискорювачем, чи джерелом нескінченних регресій.
Висновок: AI не скасував основи — він зробив їх умовою виживання
Якщо звести всі спостереження Поко́ка до одного висновку, він звучатиме так: AI не «вбиває» професію інженера, а підвищує вимоги до неї. Моделі здатні писати код, але не здатні самостійно керувати складністю, боротися з ентропією, підтримувати цілісність дизайн-концепту чи будувати спільну мову з доменом.
Ці завдання залишаються за людьми — і стають важливішими, ніж будь-коли, бо швидкість, із якою AI може зруйнувати архітектуру, значно вища за людську. Поганий код справді став дорожчим: він множиться швидше, гальмує AI-інструменти й перетворює їх із союзників на прискорювач хаосу.
Натомість добре спроєктовані системи, побудовані на класичних принципах — від Остергаута й Брукса до «The Pragmatic Programmer» і DDD, — виявляються ідеальним середовищем для AI. У таких кодових базах моделі працюють як дисципліновані помічники, а не як генератори спагеті-коду.
У цьому сенсі головне послання до розробників, які хвилюються за свою цінність у нову епоху, звучить несподівано оптимістично. Якщо ви вмієте проєктувати прості системи, боротися зі складністю, будувати спільну мову з доменом і мислити через фідбек-цикли, ваші навички не застаріли. Вони стали базовою інфраструктурою для того, щоб AI узагалі міг працювати на користь, а не на шкоду.