Американський підприємeць і розробник Остін Марчезе, колишній COO технологічного стартапу з виручкою понад $25 млн і нині засновник BuildPartner.ai, системно розбирає, як працювати з Claude Code не на рівні «крутих промптів», а як із реальною продакшн‑системою. Один із найпрактичніших фокусів його підходу — перевірка результатів роботи моделі до того, як щось потрапляє в продакшн або впливає на бізнес.
Марчезе пропонує конкретну «силову фразу» — verify before you build — і вибудовує навколо неї трирівневу архітектуру валідації: від файлу Claude.md і MCP‑інструментів до зон, де людина обов’язково має лишатися в контурі рішень.
Чому «verify before you build» стало обов’язковим правилом
Ключова відправна точка — тверезе визнання обмежень моделей. Claude, як і будь‑яка інша сучасна LLM, може впевнено написати, що завдання виконано, тоді як система не працює, функція не покрита краями кейсів або результат просто не відповідає очікуванням користувача. Марчезе прямо формулює проблему: Claude галюцинує, повідомляє про завершення роботи, коли вона де-факто не завершена або не відповідає бажаному результату.
На цьому фоні з’являється «power phrase number four, verify before you build». Це не ритуальна фраза для промпта, а спосіб змінити режим взаємодії з моделлю: перш ніж дозволити Claude щось «будувати» — від коду до аналітичних звітів — система має продумати, як вона перевірить власний результат.
Тут Марчезе апелює до Бориса Черні, творця Claude Code. Той наполягає: якщо «дати Claude спосіб перевірити свою роботу» і вбудувати для моделі зворотний зв’язок, це здатне «у два‑три рази підняти якість фінального результату». І далі йде ще один крок: «справжній хід — дати Claude інструмент, який дозволяє бачити власний аутпут, а потім явно розповісти моделі про цей інструмент».
Це зміщує фокус із простого «перечитай код» до більш конкретного підходу: агенту потрібен не лише список правил, а й механічний спосіб подивитися на те, що він створив, і на основі цього коригуватися.
Як навчити Claude перевіряти себе: правило «інструмент + правило»
У цій логіці верифікація розпадається на дві частини. Перша — що саме слід перевірити. Друга — як це перевірити технічно або процесно. Марчезе формулює це просто: правило верифікації каже Claude, що перевіряти, а інструмент — як здійснювати перевірку.
Звідси виникають дуже конкретні сценарії. Якщо модель будує сайт, їй слід дати можливість відкрити його в браузері та оцінити фактичний фронтенд, а не лише «довіритися» генерованому коду. Якщо йдеться про підготовку звіту, Claude має отримати спосіб звірити цей документ із бренд‑гайдом, а не покладатися на абстрактне уявлення про «тон голосу» чи формат.
Критичний момент: інструмент сам по собі не спрацьовує, якщо Claude не знає про його призначення. Саме тому Черні й підкреслює — треба не просто увімкнути MCP‑інструменти, а й явно описати для моделі, що саме вони роблять і як допомагають оцінити результат. Лише тоді агент може «бачити» свій аутпут і свідомо запускати петлю самокорекції.
Марчезе пропонує формалізувати цю логіку в трьох рівнях: від системного файлу конфігурації до набору інструментів і, нарешті, до зон, де без людини взагалі не обійтися.
Рівень 1: Claude.md як місце, де починається перевірка
Перший рівень — оновлення Claude.md, того самого файлу, який Claude автоматично підтягує на початок кожного запиту. Саме він визначає базову поведінку агента в сесії. На думку Марчезе, тут має з’явитися одна ключова лінія: «Перш ніж виконувати будь‑яку роботу, поясни, як ти можеш її верифікувати».
Це невелика, але структурна зміна. Якщо раніше модель одразу стрибала в генерацію коду, тексту чи сценаріїв автоматизації, то після цього правки вона спершу схиляється до формування плану верифікації. Тобто замість «ось код» користувач спочатку побачить: «Ось як я планую перевірити, що цей код працює».
За рахунок того, що Claude.md завжди інжектиться на початок промпта, цю звичку не потрібно нагадувати вручну. Вона стає частиною «характеру» агента. Фактично, цей рівень змушує Claude думати про тестування, перш ніж мова взагалі зайде про реалізацію.
Рівень 2: MCP‑інструменти як місток до реальності
Другий рівень — вмикання потрібних інструментів під конкретні завдання. Марчезе пропонує починати з простого запиту до моделі: «Виходячи з того, що я будую, які інструменти можуть допомогти з верифікацією?». Далі Claude само пропонує варіанти — як зовнішні, так і внутрішні, технічні чи нетехнічні.
У прикладах, які він наводить, це виглядає так. Якщо розробник деплоїть застосунок на хостинг і хоче впевнитися, що реліз справді дістався продакшну, можна підключити відповідний MCP‑інструмент, який пінгуватиме ресурс або запитуватиме дані про стан деплою. Це технічний зовнішній кейс.
З іншого боку, є внутрішні нетехнічні сценарії — наприклад, написання постів для соцмереж. Тут доцільно створити «валідатор бренд‑голосу», умовний skill, який автоматично порівнюватиме свіжозгенерований текст із зафіксованим стилем компанії. І Claude знатиме, що перед відправкою пост має пройти через цей фільтр.
У результаті перевірка перестає бути ручною звичкою користувача і перетворюється на конкретні виклики інструментів. Модель отримує змогу не тільки придумати, як варто тестувати роботу, а й фізично виконати цю перевірку — від хитрих MCP до внутрішніх валідаторів.
Рівень 3: «human validation zones» там, де помилка надто дорога
Третій рівень — визнання того, що навіть із найкращими інструментами й найакуратнішим Claude.md людина все одно має лишатися в контурах рішень. Йдеться про концепцію «human validation zones» — зон, де без людського схвалення нічого не має змінюватися.
Марчезе опирається на відоме формулювання: «Що може піти не так, те й піде не так». В епоху, коли агенти беруть на себе левову частку операційної роботи, люди дедалі частіше випадають із потоку виконання. Це означає, що якісь небажані зміни рано чи пізно таки стануться.
Щоб мінімізувати ризики, він пропонує просту рамку: подивитися на всі вузли системи й відповісти на питання, де «вартість помилки» справді висока. Саме ці області й мають стати human validation zones.
У прикладі з застосунком фронтенд і сайт, із якими взаємодіють користувачі, Марчезе відносить до низьковартісної зони — там допустима стратегія «швидко будувати й ламати». Натомість платіжна система, що стоїть за цим інтерфейсом, — це вже зона високого ризику, де будь‑яка помилка може мати серйозні фінансові наслідки. Її він однозначно зараховує до human validation zone, де людина має особисто затверджувати зміни, а агенти не повинні мати повних прав.
Далі, за його словами, можна «копати глибше» — розбудовувати процеси навколо цих зон, налаштовувати права доступу й маршрутинг завдань. Проте навіть базовий рівень — просто вимагати людського підпису і в ряді випадків повністю прибрати автоматичні дозволи агентів — уже суттєво знижує ризики. Це теж варто зафіксувати в Claude.md, щоб агент знав: у низці ситуацій він не має права діяти автономно й повинен просити review.
Як три рівні валідації працюють разом
У підсумку Марчезе пропонує розглядати цю систему як єдине ціле. На першому рівні Claude навчений ще до початку роботи продумати валідацію. На другому рівні в нього є реальні інструменти — від MCP‑конекторів до внутрішніх скілів — якими можна здійснити цю перевірку. На третьому рівні визначені точки, де жоден інструмент не замінює людського рішення, і агент знає про ці обмеження наперед.
Щоб швидко інтегрувати все це у власний робочий процес, він пропонує готовий промпт, який можна «просто вкинути в Claude Code», щоб зібрати всі три шари верифікації воєдино. Та головна ідея не в конкретному тексті промпта, а в зміні парадигми: замість того щоб просити модель «будувати швидше», варто спершу змусити її думати, як вона дізнається, що взагалі побудувала правильну річ.
У світі, де LLM‑агенти дедалі частіше працюють як автономні системи, цей підхід перетворює їх із «креативних генераторів» на більш відповідальних виконавців, які вміють не лише видавати результат, а й ставити його під сумнів — до того, як за нього доведеться платити.
Джерело
YouTube: Type This Into Claude, It’ll Make You Build 10x Faster.