Технічний контекст
Я подивився виступ Matt Pocock не як глядач, а як людина, яка постійно впирається в одну й ту саму проблему: AI implementation у розробці ламається не на моделі, а на процесі. І ось тут його набір прийомів реально влучає в ціль.
Перше, що я одразу відзначив, це /grill-me перед Plan Mode. По суті, я бачу в цьому не «секретний промпт», а режим жорсткої перевірки постановки завдання. Я й сам часто стикаюся з тим, що кодовий асистент занадто охоче погоджується, а потім тягне невірні припущення далі по ланцюжку.
/grill-me хороший саме тому, що змушує ШІ сперечатися, шукати діри, уточнювати обмеження та крайні випадки до того, як він почне писати план або код. Для реальної розробки це дешевше, ніж потім розгрібати красиво оформлену, але невірну реалізацію.
Другий сильний момент, на якому я кивнув майже автоматично, це TDD як обов'язковий мінімум. Не як ідеологія заради ідеології, а як страховка від фантазій моделі. Якщо я змушую асистента спочатку формалізувати поведінку тестом, він менше «творить» і краще тримається контракту.
Ще один корисний патерн, який обговорювали, це /domain-model. За описом це схоже на короткий виклад доменної моделі з накопиченням знань у CONTEXT.md та ADR. Мені такий підхід подобається саме своєю стриманістю: без величезного DDD-вівтаря, але з фіксацією рішень, щоб наступний прохід ШІ не починався з амнезії.
І так, /improve-codebase-architecture я б теж не сприймав як чарівну кнопку. Це скоріше спосіб направити асистента в архітектурну ревізію, але дизайн інтерфейсів я б все одно не віддавав цілком машині. Чим простіший інтерфейс, тим менше шансів, що модель «оптимізує» його в монстра.
Вплив на бізнес та автоматизацію
Для команд тут практичний висновок дуже приземлений. Виграють ті, хто будує automation with AI навколо перевірок, тестів і явного контексту. Програють ті, хто просить «зроби красиво» і потім дивується зайвій складності.
Другий ефект, який я бачу у клієнтів, це економія на переробках. Коли доменна модель та архітектурні рішення фіксуються коротко, AI integration у пайплайн стає стабільнішим: менше повторних пояснень, менше дрейфу рішень між ітераціями.
І головний висновок мені тут взагалі не здається тривожним для розробників. Ні, це не виглядає як «ШІ замінить усіх». Це виглядає як підсилювач для тих, хто вміє тримати рамку, а не як заміна інженерного мислення.
Якщо у вас команда вже пише код з Claude, Cursor або схожими інструментами, але результат плаває від відмінного до дивного, я б почав саме з таких рейок. А якщо хочете зібрати це в нормальний робочий процес без шаманства, в Nahornyi AI Lab ми якраз допомагаємо вибудувати AI automation так, щоб бізнес отримував передбачувану швидкість, а не ще одне джерело хаосу.