У 2026 році Андрій Карпаті, колишній керівник AI у Tesla, активно просуває підхід до роботи з великими мовними моделями, який радикально відрізняється від звичного «просто запитай у чат-бота». Підприємець і розробник Остін Марчезе, який будує продукти навколо Claude та Claude Code, розклав цей підхід на три шари. Перший — це специфікація завдання. Другий — верифікація результатів. Третій — середовище, в якому все це живе.
Перший шар уже детально розбирали інші аналітики. Тут зосередимося на двох наступних: як побудувати жорсткий шар перевірки навколо Claude і як створити середовище — від Claude.md до власної бази знань — яке вбудовує цю перевірку в кожну сесію. Саме ці два шари перетворюють LLM з «розумного співрозмовника» на інженерний інструмент, придатний для реальної роботи.
Від «тварин» до «статистичних схем»: чому верифікація — єдиний надійний важіль
Ключ до другого шару Карпаті — правильна ментальна модель того, чим насправді є сучасні AI-системи. Карпаті описує їх не як «тваринні інтелекти», а як «статистичні симуляційні схеми». Це не істоти з мотиваціями, страхами чи амбіціями, а складні алгоритмічні механізми, що відтворюють патерни з даних.
Це має прямі наслідки для того, як з ними працювати. Людей можна «тиснути» дедлайнами, надихати, лякати звільненням, мотивувати бонусами. Якщо сказати співробітнику: «Стань експертом з SEO за 14 днів, інакше тебе звільнять», — він, швидше за все, мобілізується, знайде курси, менторів, експериментуватиме, щоб вижити в системі стимулів.
З AI так не працює. У нього немає внутрішніх мотивацій. Його не можна «вмовити старатися більше» чи «налякати» поганою оцінкою. Фрази на кшталт «будь максимально уважним», «постався до цього як сеньйор-інженер» або «якщо помилишся — це коштуватиме мені роботи» не змінюють фундаментальної поведінки моделі. Вона все одно залишається тим самим статистичним механізмом, який комбінує ймовірні токени.
Марчезе пропонує замінити метафору «примар», яку використовує Карпаті, на більш приземлену: «робот-бібліотекар». Такий бібліотекар шукає відповіді лише в тих «книжках», які є в його бібліотеці. Якщо потрібної книжки немає, він цього не усвідомлює — і може впевнено вигадати відповідь. Саме це пояснює, чому моделі блискуче справляються з формальними задачами, де в «бібліотеці» є чіткі правила, але провалюються в контекстно-залежних ситуаціях.
Звідси випливає головний висновок: єдиний важіль, яким користувач може надійно керувати, — це не «натхнення» моделі, а верифікація. Не варто очікувати, що додаткові заклики «будь точнішим» магічно піднімуть якість. Натомість потрібно системно будувати перевірки, які працюють поверх специфікації.
Шар 2: верифікація як інженерна дисципліна, а не післямова
Другий шар методу Карпаті — це верифікаційний контур, який накладається на вже створену специфікацію. Його завдання — не довіряти внутрішній «логіці» моделі, а оцінювати лише вихідні артефакти за заздалегідь визначеними правилами.
Марчезе пропонує дивитися на цей шар як на основний інструмент оптимізації роботи з Claude. Якщо перший шар — це трансфер людського розуміння в структурований документ, то другий — це система, яка не дозволяє моделі «зійти з рейок» непомітно.
Цей шар складається з трьох ключових практик.
Чіткі критерії якості до того, як Claude почне працювати
Перша практика — визначати критерії оцінки результату до старту роботи моделі. Не після того, як Claude щось згенерував, а до першого токена.
У повсякденній роботі з AI користувачі часто обмежуються розмитими формулюваннями: «зроби це краще», «оформи красиво», «напиши якісний звіт». Для людини в контексті команди такі фрази можуть бути зрозумілими: є спільний досвід, попередні приклади, негласні стандарти. Для моделі це порожній звук.
Марчезе пропонує перетворювати такі розмиті побажання на операційні правила. Наприклад, замість «зроби звіт кращим» — конкретне обмеження: звіт має складатися рівно з трьох розділів, і кожен розділ повинен закінчуватися конкретною рекомендацією. Це вже не естетичне побажання, а чіткий тест, який можна автоматизувати: чи три розділи? чи є рекомендація в кінці кожного?
Цей підхід тісно пов’язаний із першим шаром (специфікацією), але верифікаційний фокус інший: не «що саме будувати», а «як ми зрозуміємо, що побудоване відповідає стандарту». У своїх промптах Марчезе радить прямо змушувати Claude формулювати такі критерії: просити модель спочатку описати, за якими точними правилами вона оцінюватиме власний фінальний результат.
Фактично це перенесення практик інженерного тестування в світ LLM: спочатку визначити, що таке «пройшов тест», а вже потім писати «код», тобто генерувати текст, звіт чи конфігурацію.
Другий AI як критик: бібліотекар з іншої бібліотеки
Друга практика — використання іншої моделі як незалежного критика. Якщо продовжити метафору бібліотекаря, це означає звернутися до другого бібліотекаря з іншої бібліотеки, щоб той оцінив роботу першого.
Ідея проста: різні моделі навчені на різних даних, мають різні архітектурні особливості й помиляються по-різному. Якщо одна модель згенерувала складний технічний артефакт — наприклад, фрагмент коду чи конфігурацію інфраструктури, — інша може виступити в ролі рецензента, який шукає логічні суперечності, порушення специфікації чи очевидні помилки.
Марчезе пропонує таку схему для користувачів Claude Code: встановити Codex plugin, який дозволяє прямо з сесії Claude звертатися до Codex. У складних збірках можна явно прописати правило: якщо завдання перетворюється на комплексний білд, прогнати фінальний результат через Codex і перевірити, чи обидві системи погоджуються з рішенням.
Це не гарантує абсолютної правильності, але створює додатковий рівень захисту. Якщо дві незалежні «бібліотеки» сходяться на одному висновку, ризик грубої помилки зменшується. Якщо ж Codex вказує на проблеми, це сигнал повернутися до специфікації або змінити підхід.
Такий «AI-рев’ю» нагадує практику code review в розробці: навіть найкращий інженер не відправляє складний код у продакшн без погляду іншого фахівця. Тут роль другого фахівця виконує інша модель.
Зовнішні сигнали: коли верифікація виходить за межі тексту
Третя практика — підключення зовнішніх сигналів, які дозволяють перевіряти твердження моделі не лише за формою, а й за фактом.
У технічних сценаріях це може бути інтеграція з системами деплойменту. Наприклад, якщо Claude налаштовує пайплайн розгортання застосунку, перевірка не повинна обмежуватися тим, що модель «каже», ніби деплой успішний. Сесія Claude має бути підключена до системи, де можна програмно перевірити статус розгортання. Тоді твердження «деплой пройшов успішно» підкріплюється реальними даними, а не лише текстовою впевненістю моделі.
У нетехнічних задачах логіка та сама. Якщо Claude готує щомісячний звіт, варто підвантажити історичні звіти як референси. Це дає моделі чіткий шаблон формату, структури, тону, а верифікаційний шар може порівнювати новий документ із попередніми, перевіряючи відповідність стандартам компанії.
Марчезе підкреслює, що саме поєднання цих трьох практик — чітких критеріїв, другого AI-критика та зовнішніх сигналів — перетворює верифікацію на системну функцію, а не на ручну «перечитку» результатів людиною. Борис Черні, творець Claude Code, за його словами, оцінює ефект такого фідбек-лупу як дво- чи трикратне зростання якості фінального результату.
Шар 3: середовище як невидима інфраструктура для перевірок
Якщо перший шар — це «що будувати», а другий — «як перевіряти, що побудовано правильно», то третій — це «де все це живе». Карпаті називає цей шар середовищем: контекстом, файлами, інструментами й правилами, які автоматично підтягуються в кожну сесію з моделлю.
Марчезе пропонує дивитися на це як на майстерню. Специфікація — це креслення, прикріплене до стіни. Верифікатор — це станція контролю якості біля виходу. А середовище — це сама майстерня: інструменти, розкладені по місцях, інструкції на стінах, внутрішні стандарти.
Проблема більшості користувачів, за його спостереженнями, в тому, що вони кожного разу заходять у «порожню майстерню». Новий чат — і все починається з нуля. Навіть довгі історії в одному діалозі не вирішують проблему: це радше безладний архів, ніж структуроване середовище.
Claude.md: файл, який читається першим
Центральним елементом такого середовища в екосистемі Claude Марчезе робить файл Claude.md. Це конфігураційний документ, який автоматично інжектується в кожну сесію з моделлю і стає першим, що Claude читає перед тим, як відповідати користувачу.
Саме в Claude.md можна зафіксувати правила, які забезпечують постійну присутність верифікаційного шару. Наприклад, додати інструкцію: перед будь-якою багатокроковою збіркою обов’язково сформувати план верифікації. У такому разі перевірка перестає бути тим, про що потрібно «пам’ятати» щоразу в промпті, і стає частиною базової поведінки моделі в цьому середовищі.
Марчезе використовує свій Claude.md для кількох завдань. По-перше, він описує, як влаштований репозиторій, з яким працює Claude. Репозиторій у цьому контексті — це робочий простір: структура папок, типи проєктів, основні артефакти. Такий опис дає моделі карту території, з якою вона має справу, замість того, щоб щоразу «вгадувати», де що лежить.
По-друге, у Claude.md фіксуються кастомні навички й те, як вони маршрутизуються. Якщо в середовищі є власні інструменти, скрипти чи плагіни, файл пояснює моделі, коли й як їх використовувати. Це важливо і для верифікації: частина перевірок може бути реалізована як окремі інструменти, які Claude викликає за певних умов.
По-третє, там же задаються ключові робочі правила, включно з вимогою, щоб усі багатокрокові білди містили верифікаційний план. Таким чином, другий шар методу Карпаті вбудовується в третій: середовище примушує модель думати про перевірку ще до початку роботи.
LLM як база знань: папки як контекст, а не просто історія чату
Ще одна ідея, яку просуває Карпаті й на яку спирається Марчезе, — це LLM knowledge base: папкова система користувацьких даних, яку модель може інжестувати й використовувати як контекст.
На відміну від хаотичної історії чатів, така база знань — це структурований набір документів, кодових баз, політик, звітів, які організовані в логічні папки. Для Claude це частина середовища: модель не просто «пам’ятає» попередні розмови, а має доступ до чітко організованого сховища знань.
З погляду верифікації це критично. Якщо історичні звіти лежать у визначеній папці, Claude може використовувати їх як еталон для нових документів. Якщо в окремій директорії зберігаються специфікації продукту, модель може звіряти нові фічі з офіційними вимогами. Якщо є папка з інцидентами продакшну, її можна використовувати як базу для перевірки, чи не повторюються старі помилки.
Таким чином, LLM knowledge base стає частиною третього шару — середовища, яке робить другий шар — верифікацію — значно ефективнішим. Без такої бази перевірка обмежується формальними правилами на кшталт «три розділи, кожен із рекомендацією». З нею — з’являється можливість змістовної перевірки: відповідність політикам, історичним патернам, технічним обмеженням.
Від «просто промптити» до інженерії середовищ і перевірок
Разом другий і третій шари методу Карпаті формують іншу парадигму роботи з Claude та подібними моделями. Замість культури «спробуй ще раз, може вийде краще» формується інженерний підхід, де:
специфікація фіксує цілі й контекст у формі, придатній для моделі;
верифікація визначає, як саме буде оцінюватися результат, ще до старту роботи;
середовище гарантує, що ці правила діють у кожній сесії, а модель має доступ до релевантних знань і інструментів.
У цій парадигмі користувач перестає сприймати AI як «розумного стажера, якого можна підганяти», і починає бачити в ньому те, чим він є насправді: статистичну систему, з якою потрібно працювати через чіткі специфікації, тести й контроль середовища.
Це не робить Claude чи інші моделі менш вражаючими. Навпаки, такий підхід дозволяє розкрити їхній потенціал у реальних робочих процесах — від генерації звітів до складних технічних білдів — без постійного страху, що десь у кутку ховається впевнена, але фатальна помилка.
Висновок
Метод Карпаті, у викладі Остіна Марчезе, показує, що майбутнє продуктивної роботи з LLM — не в магічних промптах і не в емоційних зверненнях до «штучного інтелекту», а в суворій інженерії: специфікаціях, верифікації та середовищах.
Другий шар — верифікація — змушує нас перестати довіряти «інтуїції» моделі й почати довіряти лише тим виходам, які пройшли чітко визначені тести, перевірені іншими моделями й підкріплені зовнішніми сигналами. Третій шар — середовище — робить цю дисципліну частиною повсякденної роботи: через Claude.md, через організовану базу знань, через інтеграції з реальними системами.
У підсумку Claude перестає бути просто чат-ботом і стає елементом інженерної інфраструктури. А користувач — не «промптером», а архітектором середовища й верифікаційних систем, які дозволяють цій інфраструктурі працювати надійно.
Джерело
Stop Prompting Claude. Use Karpathy’s Method Instead. — Austin Marchese