У центрі нинішньої хвилі AI‑інструментів для розробників стоїть парадокс: моделі здатні писати тисячі рядків коду за хвилини, але саме це й загрожує перетворити проєкти на некерований хаос. Британський інженер і викладач Метт Поко́к, автор курсу «Claude Code for Real Engineers», пропонує протилежний підхід: не скасовувати класичні інженерні практики, а зробити їх ядром AI‑першого процесу розробки.
У своїй доповіді на каналі AI Engineer він показує, як поєднати промпт‑патерни, доменно‑орієнтований дизайн, типи, браузер, тести та архітектуру глибоких модулів так, щоб LLM працювала не як генератор «спагеті‑коду», а як дисциплінований співрозробник. Ключові елементи цієї системи — власний «grill me»‑промпт, «убіквітарна мова» у форматі markdown, тест‑драйв і архітектура, яка не дає моделі потонути у власних модулях.
Від «специ до коду» до спільної «design concept»
Початкова точка — критика популярної ідеї «specs to code». У цій моделі розробник пише лише специфікацію, а далі багаторазово «компілює» її в код через LLM, майже не дивлячись на результат. Якщо щось не працює, змінюється текст спеки, і цикл повторюється.
Практичний результат такого підходу виявився передбачуваним: кожна нова ітерація погіршує кодову базу. Поко́к описує це як прояв двох класичних концепцій.
Перша — визначення складності Джона Остергаута з «A Philosophy of Software Design»: складність — це все, що робить систему важкою для розуміння та модифікації. Якщо після кількох прогонів «спеки в код» зміни стають небезпечними, а поведінка — непередбачуваною, це не «дешевий код», а дуже дорогий борг.
Друга — «ентропія програмного забезпечення» з «The Pragmatic Programmer»: кожна зміна, зроблена без урахування цілісного дизайну, збільшує безлад. Автоматичне перегенерування великих шматків коду з текстових спеки — майже ідеальний рецепт для такого безладу.
Звідси й головний висновок Поко́ка: код не став дешевим. Навпаки, поганий код ніколи не був таким дорогим, адже саме він блокує можливість повноцінно скористатися потужністю AI. На добре спроєктованих кодових базах LLM працюють помітно краще; на хаотичних — лише прискорюють деградацію.
Щоб цього уникнути, він пропонує починати не з «генерації активів», а з досягнення спільної «design concept» — терміна Фредеріка П. Брукса з «The Design of Design». Design concept — це невидима, спільна для всіх учасників ідея того, що саме будується. Її не можна просто записати в один файл; це радше узгоджена ментальна модель системи.
У взаємодії з LLM проблема в тому, що людина й модель часто не поділяють цієї спільної концепції. Звідси й класичний збій: «AI зробив не те, що я мав на увазі». Вирішення Поко́ка — змусити модель не генерувати код, поки ця спільна концепція не буде досягнута.
«Grill me»: промпт, який перетворює AI на вимогливого співрозмовника
Для цього Поко́к створив окремий «skill» — промпт «grill me». Його суть вкрай проста, але наслідки виявилися масштабними. Промпт наказує моделі:
інтерв’ювати розробника безжально щодо кожного аспекту плану,
проходити всі гілки «дерева дизайну»,
послідовно розв’язувати залежності між рішеннями,
не зупинятися, поки не буде досягнуто спільного розуміння.
Фактично це інверсія звичного сценарію, де людина ставить запитання, а AI відповідає. Тут модель стає майже «ворожим» рев’юером, який не приймає розмитих формулювань, вимагає уточнень і змушує проговорити всі компроміси та крайові випадки до того, як буде написано перший рядок коду.
Результат виявився настільки затребуваним, що GitHub‑репозиторій із цим skill’ом набрав близько 13 тисяч зірок. Розробникам сподобалася не магія, а дисципліна: кілька рядків інструкцій перетворюють LLM на інструмент глибокого прояснення вимог.
У практиці це виглядає так: модель може поставити 40, 60, а іноді й понад 100 запитань, перш ніж «задовольнитися» тим, що спільна design concept досягнута. На виході розробник отримує не код, а насичену розмову, яку можна перетворити на документ вимог, набір задач або безпосередньо передати агентам для реалізації.
Поко́к прямо порівнює цей підхід із вбудованим «plan mode» у Claude Code, яким сам користується. На його думку, стандартний режим надто прагне «створити актив» — швидко видати план і перейти до коду. «Grill me» навпаки затримує цей момент, змушуючи спочатку вибудувати спільну design concept. Саме тому він віддає перевагу власному skill’у: якість плану та відповідність намірам розробника виявляються вищими.
Це зміщує акцент: LLM перестає бути «генератором коду за запитом» і стає співучасником етапу проєктування, де найвища ціна помилок і найскладніше досягти узгодженості.
Убіквітарна мова для людини й моделі: markdown як контракт
Навіть коли спільна design concept досягнута, наступна типова проблема — надмірна багатослівність і «розмови навхрест». Модель пояснює очевидне, плутає терміни, дублює одні й ті самі ідеї різними словами. Це не лише дратує, а й ускладнює планування та рев’ю.
Поко́к проводить тут паралель із класичною взаємодією розробників і доменних експертів. Якщо інженер будує систему для складної предметної області — наприклад, мікрочипів, — без спільної мови сторони неминуче говорять про різне. Експерт оперує термінами домену, розробник — технічними абстракціями, і між ними утворюється перекручений «переклад», у якому губиться сенс.
Доменно‑орієнтований дизайн (Domain‑Driven Design, DDD) пропонує протиотруту — концепцію ubiquitous language, «убіквітарної мови». Це узгоджений набір термінів, який однаково використовується в розмовах між розробниками, у спілкуванні з бізнесом і в самому коді. У DDD це не просто словник, а відображення доменної моделі.
Поко́к переносить цю ідею в контекст AI‑асистованої розробки. Він створив окремий skill, який сканує кодову базу, виявляє ключову термінологію й автоматично формує markdown‑файл — фактично словник убіквітарної мови проєкту. У ньому терміни структуровані у вигляді таблиць із визначеннями, що робить документ зручним і для людини, і для моделі.
Цей файл потім передається LLM як частина контексту. Розробник також тримає його відкритим під час «грилювання» та планування. За спостереженнями Поко́ка, це дає кілька відчутних ефектів.
По‑перше, зменшується багатослівність. Модель більше не намагається щоразу «вигадувати» нові формулювання, а спирається на вже узгоджені терміни. Це робить її міркування компактнішими й зрозумілішими.
По‑друге, покращується відповідність між планом і реалізацією. Коли одна й та сама термінологія використовується в описі вимог, у плані й у коді, зменшується ризик того, що модель «перекладе» одну концепцію в іншу й ненавмисно змінить сенс.
По‑третє, з’являється явний артефакт спільної мови, який можна рев’ювати, доповнювати й використовувати як частину онбордингу для нових учасників команди — як людських, так і AI‑агентів.
У підсумку ubiquitous language у форматі markdown стає ще одним видом контракту між людиною й моделлю, подібно до того, як інтерфейси й типи виступають контрактами всередині коду.
Типи, браузер і тести: як побудувати корисні фідбек‑цикли для LLM
Навіть якщо модель правильно зрозуміла, що будувати, і говорить «правильною мовою», залишається базова проблема: код може просто не працювати. Тут Поко́к повертається до ще одного класичного принципу з «The Pragmatic Programmer»: швидкість розробки обмежується швидкістю зворотного зв’язку. Якщо ви рухаєтеся швидше, ніж отримуєте сигнали про помилки, ви «обганяєте власні фари» — рухаєтеся в темряві.
LLM за замовчуванням саме так і поводяться. Вони схильні робити занадто багато змін за один крок, а потім лише побіжно перевіряти результат. Це різко контрастує з поведінкою досвідченого інженера, який звик до коротких, щільних фідбек‑циклів.
Щоб повернути контроль, Поко́к наполягає на трьох типах зворотного зв’язку, до яких варто обов’язково підключати модель.
Перший — статичні типи. У контексті веб‑розробки він прямо говорить: якщо ви не використовуєте TypeScript, це «божевілля». Типи дають моделі чіткі контракти щодо структури даних і очікуваних інтерфейсів. LLM може аналізувати ці контракти, виявляти невідповідності ще до запуску коду й краще міркувати про наслідки змін.
Другий — доступ до браузера для фронтенд‑застосунків. Якщо модель бачить лише код, вона змушена робити висновки про UI опосередковано. Доступ до реального DOM, стилів і поведінки в браузері дозволяє їй співвідносити зміни в коді з фактичним інтерфейсом, а не з абстрактними уявленнями. Це особливо важливо для діагностики візуальних багів і проблем із взаємодією.
Третій — автоматизовані тести. Вони перетворюють очікувану поведінку системи на перевірювані твердження. Для LLM це ще один канал фідбеку: модель може запускати тести, бачити, що саме ламається, і спрямовувати свої зміни на виправлення конкретних невідповідностей.
Проблема в тому, що навіть маючи всі ці інструменти, LLM не вміє інстинктивно використовувати їх так, як це робить досвідчений розробник. Вона все одно схильна «розганятися» — генерувати великі патчі, а потім лише формально проганяти тип‑чекер чи тести. Це й є класичне «outrunning your headlights».
Щоб змусити модель рухатися дрібнішими кроками, Поко́к пропонує повернутися до ще однієї старої практики — тест‑драйв розробки.
TDD як «обмежувач швидкості» для AI‑розробника
Тест‑драйв розробки (Test‑Driven Development, TDD) традиційно вважається складною дисципліною. Потрібно вирішити, який саме блок тестувати, які сценарії покрити, що замокати, як уникнути крихкості тестів. Усе це — пов’язані між собою рішення, і саме тому багато команд або відмовляються від TDD, або застосовують його фрагментарно.
Парадоксально, але саме ця «важкість» робить TDD корисним у поєднанні з LLM. Поко́к пропонує використовувати його як спосіб примусово зменшити розмір кроків, які робить модель.
У TDD цикл виглядає так: спочатку пишеться тест, який описує бажану поведінку; потім робиться мінімальна зміна, щоб тест пройшов; після цього код рефакториться з урахуванням дизайну. Якщо цей цикл нав’язати моделі як робочий патерн, вона перестає робити масивні, слабо перевірені зміни й починає працювати серією невеликих, перевірених кроків.
Це дає кілька переваг.
По‑перше, з’являється чіткий, автоматизований фідбек після кожної зміни. Модель не може «забути» прогнати тести, якщо це вбудовано в саму структуру промптів і інструментів.
По‑друге, розробник отримує можливість точніше керувати напрямком руху. Замість того щоб просити модель «переписати модуль», він формулює конкретний тест і просить зробити його зеленим. Це зменшує простір для небажаних побічних ефектів.
По‑третє, TDD природно підштовхує до кращого дизайну. Після того як тест пройшов, настає фаза рефакторингу, де можна разом із моделлю обговорити архітектурні покращення, не боячись зламати поведінку, зафіксовану тестами.
Поко́к підкреслює, що тестування завжди було складним, і LLM це не змінює. Але саме тому воно стає критично важливим елементом AI‑першого процесу: без тестів швидкість генерації коду перетворюється на швидкість накопичення ентропії.
Глибокі модулі проти «AI‑архітектури з тисячі дрібних файлів»
Окремий пласт проблеми — архітектура. Навіть за наявності хороших промптів, спільної мови й тестів, погана модульна структура здатна звести нанівець переваги AI‑асистованої розробки.
Поко́к спирається тут на ще одну ідею Остергаута — концепцію «глибоких модулів». Глибокий модуль має простий, зрозумілий інтерфейс, але приховує за ним значний обсяг складної логіки. Він інкапсулює складність, дозволяючи іншим частинам системи взаємодіяти з ним через невеликий набір чітко визначених операцій.
Протилежність — «мілкі модулі»: вони мають складні, роздуті інтерфейси, але за ними стоїть відносно невелика функціональність. Така архітектура розмазує складність по всій системі, роблячи її важкою для розуміння й модифікації — саме те, що Остергаут називає комплексністю.
За спостереженнями Поко́ка, LLM за замовчуванням схильні створювати саме такі мілкі модулі. Модель легко генерує багато файлів, кожен із яких містить невеликий фрагмент логіки, але з надмірно деталізованими інтерфейсами й слабкою інкапсуляцією. На перший погляд це може виглядати як «гарна розбивка на модулі», але на практиці така структура виявляється важкою навіть для самої моделі.
AI‑агенту складно орієнтуватися в кодовій базі, де десятки чи сотні дрібних модулів слабо відрізняються один від одного, мають перехресні залежності й не приховують складність. Кожна зміна вимагає завантаження великої кількості контексту, а ризик ненавмисних побічних ефектів зростає.
Звідси — ще один важливий висновок: хороші, добре спроєктовані кодові бази не лише легше тестувати, вони й краще «засвоюються» LLM. Глибокі модулі з простими інтерфейсами створюють для моделі чіткі «точки входу» й зменшують обсяг контексту, необхідний для внесення змін. Це запускає своєрідне «добре коло»: хороша архітектура полегшує тестування, тести дають кращий фідбек моделі, модель робить менш руйнівні зміни, архітектура зберігається й покращується.
Поко́к наголошує, що саме тут особливо потрібна людська дисципліна. LLM не має інтуїтивного відчуття «глибини» модулів і не відчуває болю від поганої архітектури так, як це робить інженер, змушений підтримувати систему роками. Якщо віддати архітектурні рішення повністю на відкуп моделі, результатом майже неминуче стане ліс мілких модулів, у якому загубиться і людина, і AI.
Висновок: AI‑перший процес як повернення до класики
Підхід, який описує Метт Поко́к, виглядає парадоксально консервативним на тлі хайпу навколо «агентних» систем, що нібито здатні самостійно проєктувати й будувати складні застосунки. Замість того щоб мріяти про повну автоматизацію, він пропонує повернутися до старих книжок — Остергаута, Брукса, «The Pragmatic Programmer», Domain‑Driven Design — і використати їх як основу для AI‑першого процесу.
«Grill me»‑промпт допомагає досягти спільної design concept до того, як буде написано код. Убіквітарна мова в markdown зменшує семантичний шум і вирівнює план із реалізацією. Статичні типи, доступ до браузера й автоматизовані тести створюють щільні фідбек‑цикли, які не дозволяють «обігнати власні фари». TDD змушує модель рухатися дрібними, контрольованими кроками. А архітектура глибоких модулів забезпечує середовище, у якому LLM може ефективно орієнтуватися й еволюціонувати систему без вибуху складності.
У підсумку AI‑інструменти перестають бути заміною інженерів і стають множником їхньої майстерності. Але цей множник працює лише тоді, коли фундамент — дизайн, мова, типи, тести й модулі — залишається в центрі уваги. Саме тому, як стверджує Поко́к, у добу AI‑кодингу програмні фундаментали важать більше, ніж будь‑коли.
Джерело
It Ain’t Broke: Why Software Fundamentals Matter More Than Ever — Matt Pocock, AI Hero @mattpocockuk