Примечание редактора: В то время как «более мощные модели» стали ответом по умолчанию в индустрии, эта статья предлагает иное суждение: то, что действительно создает разрыв в производительности в 10, 100 и даже 1000 раз, — это не сами модели, а целостный системный дизайн, построенный вокруг них.

Автор статьи, Гарри Тан, нынешний президент и CEO Y Combinator, долгое время работал в сфере ИИ и экосистемы ранних стартапов. Он предлагает framework «толстые навыки (fat skills) + тонкая обвязка (thin harness)», разбивая ИИ-приложения на ключевые компоненты: навыки, framework выполнения, маршрутизация контекста, разделение задач и сжатие знаний.

В этой системе модель больше не является всей компетенцией, а лишь исполнительным блоком; реальное качество вывода определяется тем, как вы организуете контекст, формализуете процессы и проводите границу между «суждением» и «вычислением».

Что более важно, этот метод не остается на концептуальном уровне, а проверен в реальных сценариях: для задачи обработки и сопоставления данных тысяч предпринимателей система, через цикл «чтение-упорядочивание-суждение-запись», достигла способностей, близких к человеческому аналитику, и продолжает самооптимизироваться без переписывания кода. Такая «обучающаяся система» превращает ИИ из разового инструмента в инфраструктуру с эффектом сложного процента.

Таким образом, ключевой вывод статьи становится ясен: в эпоху ИИ разрыв в эффективности больше не зависит от того, используете ли вы самую передовую модель, а от того, строите ли вы систему, способную накапливать компетенции и автоматически эволюционировать.

Далее оригинальный текст:

Стив Йегге говорит, что люди, использующие ИИ-агентов для программирования, «в 10–100 раз эффективнее инженеров, которые пишут код только с помощью Cursor и чат-инструментов, и примерно в 1000 раз эффективнее инженеров Google 2005 года».

Это не преувеличение. Я видел это сам и испытывал на себе. Но когда люди слышат о таком разрыве, они часто приписывают его неправильным причинам: более сильным моделям, более умному Claude, большему количеству параметров.

На самом деле, человек, повысивший эффективность в 2 раза, и человек, повысивший ее в 100 раз, используют одну и ту же модель. Разница не в «интеллекте», а в «архитектуре», и эта архитектура настолько проста, что ее можно записать на карточке.

Harness (обвязка, framework выполнения) — это и есть продукт.

31 марта 2026 года Anthropic случайно выложила полный исходный код Claude Code в npm — всего 512 тысяч строк. Я прочитал его полностью. Это подтвердило то, о чем я постоянно говорю в YC (Y Combinator): настоящий секрет не в модели, а в «том слое, который оборачивает модель».

Контекст репозитория кода в реальном времени, кеширование промптов, инструменты, разработанные для конкретных задач, максимальное сжатие избыточного контекста, структурированная память сессии, параллельно работающие суб-агенты — все это не делает модель умнее. Но это позволяет дать модели «правильный контекст» в «правильное время», избегая затопления无关щей информацией.

Этот слой «обертки» и называется harness (обвязка, framework выполнения). И вопрос, который должны задавать себе все создатели ИИ, таков: что должно войти в harness, а что должно остаться снаружи?

На этот вопрос есть очень конкретный ответ — я называю его: тонкая обвязка (thin harness), толстые навыки (fat skills).

Пять определений

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

Они терпят неудачу потому, что не понимают ваши данные — вашу схему, ваши соглашения, какую именно форму имеет ваша проблема. А следующие пять определений как раз и предназначены для решения этой проблемы.

1. Skill file (файл навыка)

Файл навыка — это повторно используемый markdown-документ, который учит модель «как делать что-то». Обратите внимание: не «что делать» — эту часть предоставляет пользователь. Файл навыка предоставляет процесс.

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

Например, есть навык под названием /investigate. Он включает семь шагов: определение объема данных, построение временной шкалы, diarize (тематическое профилирование) для каждого документа, синтез и обобщение, аргументация с обеих сторон, цитирование источников. Он принимает три параметра: TARGET, QUESTION и DATASET.

Если вы направите его на ученого-биолога и 2.1 миллиона писем судебной экспертизы, он превратится в аналитика медицинских исследований, чтобы определить, был ли подавлен whistleblower (разоблачитель).

Если вы направите его на shell-компанию и документы Федеральной избирательной комиссии (FEC) США, он станет судебным следователем, отслеживающим скоординированные политические взносы.

Все тот же навык. Все те же семь шагов. Все тот же markdown-файл. Навык описывает процесс суждения, а в реальный мир его воплощают параметры, передаваемые при вызове.

Это не prompt engineering, а проектирование программного обеспечения: только здесь markdown используется как язык программирования, а человеческая способность к суждению — как среда выполнения. Фактически, markdown даже лучше подходит для инкапсуляции компетенций, чем жесткий исходный код, потому что он описывает процессы, суждения и контекст, а это как раз тот язык, который модель лучше всего «понимает».

2. Harness (обвязка, framework выполнения)

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

Вот и все. Это и есть «тонкий (thin)» harness.

Анти-паттерн — это: толстый harness, тонкие навыки.

Вы точно видели такое: 40+ определений инструментов, где одни описания съедают половину контекстного окна; универсальный God-tool, на один запуск MCP уходит от 2 до 5 секунд; или когда каждая конечная точка REST API обернута в отдельный инструмент. В результате использование токенов утраивается, задержка утраивается, частота отказов утраивается.

Идеальный подход — использовать инструменты, созданные для конкретной цели, быстрые и с узкой функциональностью.

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

Современному ПО больше нет необходимости быть «выточенным до ожирения». Вы должны: строить только то, что вам действительно нужно, и ничего больше.

3. Resolver (резолвер, распознаватель)

Resolver, по сути, это таблица маршрутизации контекста. Когда появляется задача типа X,优先 загрузить документ Y. Skills говорят модели «как делать»; resolvers говорят модели «когда и что загружать».

Например, разработчик изменяет какой-то промпт. Без resolver он может изменить и сразу выпустить релиз. С resolver модель сначала прочитает docs/EVALS.md. А в этом документе написано: сначала запустите набор оценок, сравните баллы до и после; если точность упала более чем на 2%, откатитесь и исследуйте причину. Этот разработчик изначально даже не знал о существовании набора оценок. Resolver в нужный момент загрузил правильный контекст.

Claude Code имеет встроенный resolver. У каждого skill есть поле description, и модель автоматически сопоставляет намерение пользователя с описанием навыка. Вам даже не нужно запоминать, существует ли навык /ship — само description и есть resolver.

Честно говоря: мой старый CLAUDE.md был аж на 20 тысяч строк. Все особенности, все шаблоны, все уроки, которые я усвоил, — все было затолкано туда. Это абсурдно. Качество внимания модели явно ухудшилось. Claude Code даже прямо велел мне его сократить.

Окончательное решение заняло около 200 строк — остались только указатели на несколько документов. Какие документы действительно нужны, resolver загружает их в ключевые моменты. Таким образом, 20 тысяч строк знаний все еще доступны по требованию, но не загрязняют контекстное окно.

4. Latent и deterministic (латентное пространство и детерминированность)

В вашей системе каждый шаг принадлежит либо к одной, либо к другой категории. И смешение этих двух вещей — самая распространенная ошибка в дизайне агентов.

· Latent space (латентное пространство) — это место, где находится интеллект. Модель здесь читает, понимает, судит, принимает решения. Здесь обрабатывается: суждение, синтез, распознавание образов.

· Deterministic (детерминированность) — это место, где находится надежность. Одинаковый вход всегда дает одинаковый выход. SQL-запросы, скомпилированный код, арифметические операции принадлежат этой стороне.

LLM может помочь вам рассадить 8 человек за ужином, учитывая характер и социальные связи каждого. Но если попросить ее рассадить 800 человек, она с серьезным видом сочинит «выглядящий правдоподобно, но полностью ошибочный» план рассадки. Потому что это уже не проблема для латентного пространства, а детерминированная проблема — задача комбинаторной оптимизации — втиснутая в latent space.

Худшие системы всегда размещают работу не на той стороне этой разделительной линии. Лучшие системы очень холодно проводят границу.

5. Diarization (тематическое профилирование / портретизация)

Шаг diarization — это то, что действительно позволяет ИИ принести ценность в реальной интеллектуальной работе.

Его смысл: модель читает все материалы по теме и пишет структурированный портрет. На одном листе она концентрирует суждения из десятков, даже сотен документов.

Это не то, что может выдать SQL-запрос. Это не то, что может выдать RAG-пайплайн. Модель должна действительно прочитать, держать противоречивую информацию в голове одновременно, заметить, что изменилось и когда, и синтезировать это в структурированную intelligence (разведанные данные).

Это разница между запросом к базе данных и брифингом аналитика.

Эта архитектура

Эти пять концепций можно объединить в очень простую трехслойную архитектуру.

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

Ключевой принцип направленный: выталкивать «интеллект» как можно выше в skills; прижимать «исполнение» как можно ниже к детерминированным инструментам; держать harness тонким.

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

Обучающаяся система

Ниже я использую реальную систему, которую мы строим в YC, чтобы показать, как эти пять определений работают вместе.

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

Традиционный подход: команда проекта из 15 человек читает заявки, судит по интуиции и обновляет таблицу.

Этот метод работал на масштабе 200 человек, но на 6000 он полностью проваливается. Ни один человек не может удержать в голове столько портретов и осознать: три лучших кандидата в направлении инфраструктуры AI agent — это основатель инструментов для разработки из Лагоса, предприниматель в сфере compliance из Сингапура и разработчик CLI-инструментов из Бруклина — и в разных 1:1 диалогах они совершенно по-разному описали одну и ту же больную точку.

Модель может это сделать. Метод следующий:

Enrichment (обогащение информации)

Есть навык под названием /enrich-founder, который вытягивает все источники данных, обогащает информацию, делает diarization и отмечает расхождения между «тем, что говорит основатель» и «тем, что делается на самом деле».

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

Вывод diarization может捕捉到 информацию, которую совершенно невозможно обнаружить поиском по ключевым словам:

Такое расхождение «слова vs реальное поведение» требует одновременного прочтения истории коммитов GitHub, заявочных материалов и записей диалогов, и интеграции этого в уме. Никакой поиск по схожести эмбеддингов (embedding similarity search) не может этого сделать, как и фильтрация по ключевым словам. Модель должна прочитать полностью и затем вынести суждение. (Это именно та задача, которую следует помещать в latent space!).

Matching (сопоставление)

Здесь проявляется сила «навык = вызов метода».

Один и тот же навык matching, вызванный три раза, может производить совершенно разные стратегии:

/match-breakout: обрабатывает 1200 человек, кластеризует по domain, по 30 человек в группе (эмбеддинги + детерминированное распределение)

/match-lunch: обрабатывает 600 человек, «случайное сопоставление» across domains, по 8 человек за столом без повторов — LLM сначала генерирует темы, затем детерминированный алгоритм рассаживает

/match-live: обрабатывает участников в реальном времени на месте, на основе ближайших соседей по эмбеддингам, завершает 1 на 1 matching за 200 мс, исключая уже встретившихся

И модель может做出 суждения, которые традиционные алгоритмы кластеризации выполнить не могут:

«Santos и Oram оба из инфраструктуры ИИ, но не конкуренты — Santos делает cost attribution, Oram делает orchestration. Следует поместить в одну группу.»
«Kim в заявке написал developer tools, но 1:1 диалог показывает, что он делает SOC2 compliance automation. Следует переклассифицировать в FinTech / RegTech.»

Эта переклассификация совершенно не улавливается эмбеддингами. Модель должна прочитать весь портрет.

Цикл обучения (learning loop)

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

Затем он предлагает новые правила и записывает их обратно в навык matching:

Когда участник говорит «AI infrastructure», но его код на 80% состоит из billing modules:
→ Классифицировать как FinTech, а не AI Infra

Когда два человека в группе уже знакомы:
→ Понизить вес matching
→ Предпочтительно вводить новые связи

Эти правила записываются обратно в файл skill. При следующем запуске они автоматически вступают в силу. Навык «сам себя переписывает». На июльском мероприятии «нормально» было 12%; на следующем мероприятии упало до 4%.

Файл навыка выучил, что означает «нормально», и система стала лучше без переписывания кода кем-либо.

Эту модель можно перенести на любую область:

Поиск → Чтение → Diarize → Подсчет → Синтез

Затем: Исследование → Опрос → Diarize → Переписать skill

Если вы спросите, какой цикл будет самым ценным в 2026 году, то это именно он. Его можно применить почти к любой сценарию интеллектуальной работы.

Навыки — это постоянное обновление

Недавно я опубликовал в X инструкцию для OpenClaw, отклик был больше ожидаемого:

Этот контент получил тысячи лайков и более двух тысяч сохранений. Многие подумали, что это прием prompt engineering.

На самом деле, нет, это та самая архитектура. Каждый написанный вами skill — это постоянное обновление системы. Он не деградирует, не забывается. Он будет автоматически запускаться в три часа ночи. И когда выйдет следующее поколение моделей, все навыки мгновенно станут сильнее — латентная часть, способность к суждению, улучшится, а детерминированная часть останется стабильной и надежной.

Это и есть источник 100-кратной эффективности, о котором говорил Йегге.

Не более умные модели, а: толстые навыки, тонкая обвязка (Thin Harness, Fat Skills), и дисциплина закрепления всего в виде компетенций.

Система будет расти с сложным процентом. Построить один раз, работать долго.