Жорсткий Harness, пухкий Skill: справжнє джерело 100-кратної AI-продуктивності

Заголовок оригіналу: Тонка обв’язка, багаті навички
Автор оригіналу: Гаррі Тан
Переклад: Пеггі, BlockBeats

Автор оригіналу: BlockBeats

Джерело оригіналу:

Перепублікація: Mars Finance

Передмова редактора: Коли «більш потужна модель» стає стандартною відповіддю в галузі, ця стаття пропонує інше судження: справжня різниця у 10, 100 або навіть 1000 разів у продуктивності полягає не в самій моделі, а у цілій системній архітектурі, побудованій навколо моделі.

Автор цієї статті Гаррі Тан, нині президент і CEO Y Combinator, довгий час займається AI та екосистемою ранніх стартапів. Він пропонує рамкову концепцію «жирні навички + тонка обв’язка», розбиваючи застосування AI на ключові компоненти: навички, виконавчий каркас, маршрутизація контексту, розподіл задач і стиснення знань.

У цій системі модель вже не є всім можливостям, а лише виконавчим елементом системи; справжній фактор, що визначає якість виходу, — це як ви організовуєте контекст, конденсуєте процеси та чітко розмежовуєте «судження» і «обчислення».

Що ще важливіше, ця методика не залишилася на рівні концепцій, а була перевірена у реальних сценаріях: при обробці даних та задачах співставлення тисяч стартаперів система через цикл «читання — узагальнення — судження — запис назад» досягає здатності, близької до людського аналітика, і при цьому без переписування коду постійно самовдосконалюється. Така «навчальна система» перетворює AI із одноразового інструменту у базову інфраструктуру з ефектом складного відсотка.

Звідси й чітке нагадування: у епоху AI різниця у продуктивності вже не залежить від того, чи використовуєте ви найсучаснішу модель, а від того, чи побудували ви систему, здатну постійно накопичувати можливості та автоматично еволюціонувати.

Нижче наведено оригінальний текст:

Steve Yegge каже, що використання AI-агентів для програмування «продуктивність у 10-100 разів вища, ніж у тих, хто пише код лише за допомогою Cursor і чат-інструментів, приблизно у 2005 році Google-інженери були у 1000 разів продуктивнішими.»

Це не перебільшення. Я бачив це особисто і переживав. Але, почувши таку різницю, люди зазвичай звинувачують у цьому неправильний напрямок: більш потужні моделі, розумніший Claude, більше параметрів.

Насправді, люди, що підвищують продуктивність у 2 рази і у 100 разів, використовують один і той самий набір моделей. Різниця не у «розумі», а у «архітектурі», і ця архітектура настільки проста, що її можна записати на картці.

Harness (виконавчий каркас) — це і є продукт.

31 березня 2026 року Anthropic несподівано опублікувала повний вихідний код Claude Code на npm — всього 512 тисяч рядків. Я переглянув його. Це підтвердило те, що я постійно говорю у YC: справжня таємниця не у моделі, а у «шарі, що обгортає модель».

Реальний контекст коду, кеш Prompt, інструменти для конкретних задач, максимально стиснені зайві контексти, структурована пам’ять сесій, паралельні підагенти — все це не робить модель розумнішою. Але вони здатні у «правильний час» подавати моделі «правильний» контекст і уникати засмічення зайвою інформацією.

Цей «обгортковий» шар називається harness (виконавчий каркас). І всі розробники AI мають запитати себе: що саме має входити у harness, а що залишати зовні?

Це питання має дуже конкретну відповідь — я називаю її: тонкий каркас (thin harness), багаті навички (fat skills).

П’ять визначень

Проблема ніколи не у розумності моделі. Модель вже давно вміє робити висновки, узагальнювати інформацію, писати код.

Її провал — у тому, що вона не розуміє ваші дані — вашу схему, ваші домовленості, конкретну форму вашого питання. І ці п’ять визначень саме для вирішення цієї проблеми.

1. Skill file (файл навичок)

Файл навичок — це повторюваний markdown-документ, що навчає модель «як зробити одне». Зверніть увагу, це не вказівка «що робити» — цю частину дає користувач. Файл навичок описує процес.

Ключовий момент, який багато ігнорують: файл навичок — це як один виклик методу. Він може приймати параметри. Ви можете викликати його з різними параметрами. Одна й та сама процедура, але з різними вхідними даними, проявляє різні можливості.

Наприклад, є навичка /investigate. Вона складається з семи кроків: визначення обсягу даних, побудова хронології, diarize кожного документа, узагальнення, аргументація з обох сторін, цитування джерел. Вона приймає три параметри: TARGET, QUESTION і DATASET.

Якщо ви вкажете її для безпеки науковця і 2,1 мільйона електронних листів з доказами, вона перетвориться на медичного аналітика, щоб визначити, чи був свідок під тиском.

Якщо ж ви вкажете її для компанії-офшору і звітних документів FEC, вона стане юридичним слідчим, щоб відслідкувати політичні пожертви з ознаками змови.

Знову ж, це той самий навик. Ті самі сім кроків. Та сама markdown-інструкція. Описує процес судження, а реальне застосування — у параметрах, що передаються при виклику.

Це не prompt engineering, а проектування програмного забезпечення: тут використовується markdown як мова програмування, а людське судження — як середовище виконання. Насправді, markdown навіть краще за статичний код для інкапсуляції можливостей, оскільки він описує процес, судження і контекст — саме ті мови, які модель «розуміє» найкраще.

2. Harness (виконавчий каркас)

Harness — це шар програми, що керує роботою LLM. Він виконує чотири функції: запуск моделі у циклі, читання і запис файлів, управління контекстом і забезпечення безпеки.

Ось і все. Це і є «тонкий» (thin).

Протилежний приклад — товстий harness, тонкі навички.

Ви напевно бачили таке: понад 40 інструментів, опис яких займає половину вікна контексту; універсальний «бог-інструмент», що виконує MCP за 2-5 секунд; або кожен endpoint REST API обгорнутий у окремий інструмент. Результат — у три рази більше витрачених токенів, у три рази більша затримка, у три рази вищий рівень помилок.

Ідеальний підхід — використовувати цільові, швидкі та вузькоспеціалізовані інструменти.

Наприклад, Playwright CLI, де кожна операція браузера займає 100 мс; а не Chrome MCP, що робить скріншот → пошук → клік → очікування → читання за 15 секунд. Перший у 75 разів швидший.

Зараз вже не потрібно «вдосконалювати» програмне забезпечення до надмірної складності. Вам потрібно просто створювати те, що дійсно потрібно, і більше нічого.

3. Resolver (解析器)

Resolver — це по суті таблиця маршрутизації контексту. Коли з’являється тип задачі X, він пріоритетно завантажує документ Y. Навички говорять моделі «як зробити»; резолвери — «коли що завантажувати».

Наприклад, розробник змінив один з промптів. Без резолвера він міг просто випустити оновлення. З резолвером модель спершу читає docs/EVALS.md, де описано: спочатку запустити тест оцінки, порівняти бали; якщо точність знизилася більш ніж на 2%, зробити відкат і розслідувати. Розробник навіть не знав, що існує тест оцінки. Саме резолвер у потрібний момент підвантажує правильний контекст.

Claude Code має вбудований резолвер. Кожен навик має поле description, і модель автоматично співставляє наміри користувача з описом навику. Вам навіть не потрібно пам’ятати, чи існує навик /ship — description сам є резолвером.

Чесно кажучи, раніше мій CLAUDE.md налічував 20 тисяч рядків. Там були всі дивні особливості, патерни, досвід і уроки, що я зібрав. Це було надмірно. Я помітив, що якість уваги моделі знизилася. Claude Code навіть змусила мене його видалити.

Останній варіант — близько 200 рядків, з кількома посиланнями на документи. Саме ці документи резолвер підвантажує у потрібний момент. Так 20 тисяч рядків знань залишаються доступними, але не засмічують контекст.

4. Latent і deterministic (潜在空间 і детермінізм)

У вашій системі кожен крок — або належить до латентного простору, або до детермінованого. І змішувати їх — одна з найпоширеніших помилок у агент-дизайні.

·Latent space — це місце розуму. Модель тут читає, розуміє, судить, приймає рішення. Тут працює: висновки, узагальнення, розпізнавання шаблонів.

·Deterministic — це місце довіри. За однакових вхідних даних завжди однаковий результат. SQL-запити, скомпільований код, арифметичні обчислення — належать цій стороні.

Наприклад, LLM може допомогти вам розсадити 8 людей за столом, враховуючи їх характер і соціальні зв’язки. Але якщо потрібно розсадити 800 людей, він напише «здається, логічно, але неправильно» — таблицю, яка виглядає розумною, але є повною нісенітницею. Це тому, що це вже не питання латентного простору, а завдання, що належить до детермінованої частини — задачі комбінаційної оптимізації.

Найгірша система — це та, що неправильно розподіляє роботу між цими двома зонами. Найкраща — чітко розмежовує їх.

5. Diarization (структурування документів / образ теми)

Цей крок — справжній ключ до цінності AI у реальній роботі з знаннями.

Він означає: модель читає всі матеріали, що стосуються однієї теми, і створює структурований образ. Одним аркушем стискає висновки з десятків або сотень документів.

Це не те, що може зробити SQL-запит. Це не те, що може RAG-пайплайн. Модель має справді читати, одночасно тримати у голові суперечливу інформацію, помічати зміни, і консолідувати їх у структурований інтелект.

Це різниця між запитами до бази даних і аналітичними звітами аналітика.

Ця архітектура

Ці п’ять концепцій можна об’єднати у дуже просту трирівневу архітектуру:

·Верхній рівень — жирні навички (fat skills): процеси, описані у markdown, що містять судження, методології і галузеві знання. 90% цінності — саме тут.
·Середній рівень — тонкий CLI harness: приблизно 200 рядків коду, що приймає JSON, видає текст, за замовчуванням лише читає.
·Нижній рівень — ваше застосування: QueryDB, ReadDoc, Search, Timeline — це детерміністна інфраструктура.

Основний принцип — мати напрямок: максимально переносити «інтелект» у навички; максимально зменшувати «виконання» до детермінованих інструментів; зберігати harness легким і тонким.

Результат — кожного разу, коли покращується модель, автоматично покращуються всі навички; а базова детерміністична система залишається стабільною і надійною.

Навчальні системи

Нижче я покажу на прикладі реальної системи, яку ми створюємо у YC, як ці п’ять визначень працюють разом.

Липень 2026 року, Chase Center. Startup School бере участь 6000 засновників. У кожного структуровані заявки, відповіді на анкети, транскрипти 1:1 з наставниками і публічні сигнали: пости на X, коміти на GitHub, використання Claude Code (можна побачити швидкість їхнього розвитку).

Традиційний підхід — команда з 15 людей по черзі читає заявки, інтуїтивно оцінює і оновлює таблицю.

Цей метод ще працював при 200 учасниках, але при 6000 — повністю зламався. Люди не здатні одночасно тримати у голові таку кількість образів і усвідомлювати: три найкращі кандидати у сфері AI-інфраструктури — це засновник інструментів у Лагосі, регуляторний підприємець із Сінгапуру і розробник CLI у Брукліні — і вони описують одне й те саме болюче питання у зовсім різних формах.

Модель може. Ось як:

Enrichment (збагачення інформації)

Є навичка /enrich-founder, яка витягує всі джерела даних, виконує збагачення, diarization і позначає «що сказав засновник» і «що реально робить».

Низькорівнева детерміністична система відповідає за: SQL-запити, дані з GitHub, браузерне тестування Demo URL, збирання соціальних сигналів, запити CrustData тощо. Щоденне планове завдання оновлює всі 6000 образів засновників.

Вихід diarization здатен виявити інформацію, яку повністю пропускає пошук за ключовими словами:

Це «речення проти дій» — потрібно одночасно читати історію комітів GitHub, заявки і транскрипти, і консолідувати у голові. Ні embedding, ні пошук за ключовими словами цього не зроблять. Модель має повністю прочитати і зробити висновки. (Саме цю задачу має виконувати латентний простір!)

Matching (відповідність)

Тут «навичка = виклик методу» проявляє себе найкраще.

Один і той самий навик відповідності можна викликати тричі, отримуючи різні стратегії:

/match-breakout: обробляє 1200 людей, кластеризує за галузями, по 30 осіб у групі (embedding + детерміноване розподілення)
/match-lunch: обробляє 600 людей, випадкове співставлення між галузями, по 8 осіб за стіл, без повторів — спершу модель генерує теми, потім — детермінований розподіл місць
/match-live: обробляє учасників у реальному часі, базуючись на найближчих embedding, за 200 мс виконує 1:1 відповідність і виключає вже знайомих

Модель також може робити висновки, які неможливо отримати за допомогою класичних алгоритмів кластеризації:

«Santos і Oram — обидва у сфері AI-інфраструктури, але не конкуренти — Santos займається аналізом витрат, а Oram — оркестрацією. Їх потрібно об’єднати у одну групу.»
«Kim подав заявку як розробник інструментів, але у 1:1 розмові видно, що він займається автоматизацією SOC2. Треба перекласифікувати у FinTech / RegTech.»

Таке повторне класифікування — це те, що embedding не може захопити. Модель має прочитати весь образ цілком.

Learning loop (цикл навчання)

Після завершення активності навичка /improve зчитує результати NPS-опитування, виконує diarization тих, що «близькі до хорошого», — не погані відгуки, а ті, що «майже добре» — і виявляє закономірності.

Після чого вона пропонує нові правила і записує їх у навички відповідності:

Якщо учасник каже «AI infrastructure», але його код на 80% — це модуль оплати: → класифікувати як FinTech, а не AI Infra
Якщо двоє з однієї групи вже знайомі: → зменшити вагу відповідності, пріоритетно додати нові зв’язки

Ці правила автоматично записуються у файл навичок і при наступному запуску починають діяти. Навички «самовдосконалюються». У липні «задовільна» оцінка становила 12%, у наступній — знизилася до 4%.

Файл навичок навчився розпізнавати, що означає «задовільно», і система без людського втручання ставала кращою.

Ця модель може бути застосована у будь-якій галузі:

збір → читання → diarize → підрахунок → узагальнення

потім: дослідження → опитування → diarize → переписування навичок

Якщо запитати, яка найцінніша ітерація 2026 року, — це саме ця. Вона застосовна майже у всіх сценаріях знань.

Навички — це постійне підвищення рівня

Недавно я виклав у X інструкцію для OpenClaw, яка отримала понад тисячу лайків і дві тисячі закладок:

Багато хто думав, що це техніка prompt engineering.

Насправді — ні, це та сама архітектура, про яку йшлося вище. Кожен навик — це постійне оновлення системи. Він не деградує, не забуває. Він автоматично запускається о 3-й ночі. А коли з’явиться наступне покоління моделей, усі навички миттєво стануть сильнішими — здатність латентної частини робити висновки зросте, а детермінована залишиться стабільною.

Саме це й є джерелом 100-кратної ефективності, про яку говорив Yegge.

Не у більш розумних моделях, а у: жирних навичках, тонкому каркасі (Thin Harness, Fat Skills), і дисципліні, що перетворює все у можливості.

Система зростає за складним відсотком. Побудував — працює довго.