Словарь ИИ

Подвижное обозначение, а не технология. «AI» не называет нечто постоянное, как модель или токен: оно указывает на то, что компьютеры научились делать нового и впечатляющего. Сейчас этим словом называют большие языковые модели. Раньше оно обозначало совсем другое:

Смена значения происходит по известному механизму, который иногда называют эффектом AI: как только метод начинает надёжно работать, его переименовывают — это «просто» поиск, «просто» статистика, — а термин «AI» переносится на следующую нерешённую задачу. Это наблюдение старое. В 1971 году Bertram Raphael выразил его так: «AI — общее название проблем, которые мы пока не умеем как следует решать с помощью компьютера». Версия Larry Tesler, примерно 1979 год: «Интеллект — это всё, чего машины ещё не умеют».

Вот почему разговоры об AI часто идут мимо друг друга. Утверждение вроде «AI не умеет рассуждать» или «AI переоценён» несёт скрытую временную отметку: речь может идти об экспертных системах, классификаторах изображений 2010-х или прошлогодней LLM, и каждое толкование приводит к другому выводу. Если обсуждение AI зашло в тупик, обычно нужно заменить это слово точным понятием: моделью, harness, агентом или предоставленным ему контекстом.

Избегайте: слова «AI» в технических утверждениях — вместо него называйте конкретную составляющую. «Разработка с AI» подходит как обозначение практики, а «AI галлюцинирует» — нет.

Пример использования:

«Технический директор хочет знать, может ли AI разбирать очередь заявок».

«Уточни это перед оценкой объёма: она имеет в виду LLM в harness с доступом к системе задач. Само по себе слово „AI“ — ещё не спецификация».

Параметры. Без состояния: выполняет только предсказание следующего токена. «Claude Opus 4.x» и «GPT-5.x» — примеры моделей. Сама по себе модель не может действовать как агент: её нужно подключить к каркасу.

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

Поставщики моделей предлагают модели разных уровней: крупная модель наиболее способна, но медленнее и дороже; модели поменьше быстрее и дешевле, но уступают ей в возможностях. Выбор уровня имеет практическое значение: более мощная модель подходит для планирования и сложной отладки, более лёгкая — для механических изменений. Каркасы позволяют переключать модели посреди сессии.

Точное значение этого слова также помогает лучше находить причину проблемы. Фраза «модель плохо справляется с этой задачей» — конкретное утверждение: та же модель с другим каркасом или контекстом часто ведёт себя совсем иначе. Прежде чем обвинять модель, проверьте, что ей передали: чаще всего неудовлетворительный результат вызван контекстом или каркасом, а не параметрами.

Пример использования:

«Стоит ли переключить модель с Sonnet на Opus для этапа планирования?»

«Попробуйте, но в этой задаче основную работу выполняет каркас. Замена модели не поможет, если неверно настроены системный промпт и инструменты.»

Числа внутри модели — часто их миллиарды, — настраиваемые во время обучения. Всё, что модель «знает», хранится в них. Обучение задаёт их; вывод использует их без изменений. Их также называют весами.

С точки зрения механики именно параметры преобразуют вход в выход. Предсказание следующего токена — это огромный расчёт: токены из контекстного окна проходят через параметры, умножаются на них, и получается предсказание следующего токена. Внутри модели нет базы фактов или таблицы поиска по коду — есть только эти числа, упорядоченные так, чтобы расчёт обычно давал полезный результат. Факты, которые модель может воспроизвести из обучения, например API стандартной библиотеки, — это параметрические знания: они хранятся в параметрах, а не извлекаются откуда-то ещё.

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

Пример использования:

«Можно дообучить её на нашей кодовой базе?»

«Тогда параметры обновятся — получится другая модель. Для одного проекта почти всегда дешевле загрузить кодовую базу в контекст, чем переобучать модель.»

Процесс, который задаёт параметры модели: модель получает огромные объёмы текста, а параметры корректируются, чтобы улучшить предсказание следующего токена. Это однократный дорогостоящий процесс, который выполняет поставщик модели. Он включает и предварительное обучение (основной этап), и последующее обучение (позднейшие доработки, например обучение следованию инструкциям и требованиям безопасности); на уровне этого словаря различие несущественно.

Механизм основан на многократном повторении в большом масштабе: модели показывают фрагмент текста, просят предсказать следующий токен, сдвигают параметры в сторону фактического следующего токена и повторяют это на протяжении триллионов токенов. Факты или правила отдельно не сохраняются — всё, что модель «знает», является побочным результатом улучшения предсказаний и сжато в параметрах как параметрические знания.

В повседневной работе важны два следствия. Обучение заканчивается в определённый момент, поэтому у модели есть дата отсечения знаний: она не видела версию библиотеки, на которую вы перешли в прошлом месяце. А обучать модель самостоятельно вы не можете: если ей неизвестны ваша кодовая база, соглашения или внутренние API, решение — никогда не «научить модель», а поместить эти материалы в контекст, единственный вход, который вы контролируете.

Пример использования:

«Можно научить её нашему внутреннему API?»

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

Запуск обученной модели для генерации результата — так происходит при каждом запросе к поставщику модели. Параметры остаются неизменными; модель лишь выполняет предсказание следующего токена на основе предоставленного ей контекста. Это дешевле, чем обучение, но тарифицируется за токен и составляет основную часть затрат на использование модели.

Жизненный цикл модели делится на два этапа:

Во время вывода ничто из сделанного вами не записывается обратно в параметры — поэтому сегодняшнее исправление не сохраняется до завтра. Если в следующей сессии модель повторяет ту же ошибку после вашего подробного объяснения, она не проигнорировала вас: она просто не способна учиться на этом обмене. Модель не хранит состояние — непрерывность должна обеспечиваться извне, через контекстное окно или систему памяти.

Этот механизм также объясняет принцип тарификации. Каждый запрос запускает модель на всём контексте, поэтому стоимость зависит от количества входных токенов и выходных токенов, а агент, который десятки раз вызывает инструменты, оплачивает вывод при каждом обмене. Поэтому размер контекста влияет и на качество, и на стоимость.

Пример использования:

«Почему счёт растёт вместе с использованием, а не представляет собой фиксированную лицензию?»

«Вы платите за вывод: каждый запрос к поставщику модели запускает её на оборудовании поставщика. Обучение уже завершено, но вывод тарифицируется за запрос, а один ход может превратиться во множество запросов, если вы вызываете инструменты.»

Уровень усилий задаёт, сколько рассуждений модель проводит перед ответом. Параметр устанавливается для каждого запроса к поставщику модели и определяет, насколько долго модель обдумывает ответ, прежде чем начать писать то, что вы увидите. Как и всё остальное, эти рассуждения генерируются во время инференса; harness часто скрывает их, но модель действительно выполняет эту работу.

Более высокий уровень усилий стоит дороже и работает медленнее. Рассуждение выводится в виде токенов, оплачивается как выходные токены, даже если вы их не видите, и создаётся по одному токену за раз. Поэтому увеличение уровня усилий удлиняет ожидание ответа и увеличивает счёт. Это обмен дополнительных раздумий на скорость и стоимость.

Большинство harness предлагает несколько уровней:

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

Выбирайте уровень по задаче, а не по сессии. Повышайте его для действительно сложной части и снижайте для рутинной работы вокруг неё.

Пример использования:

«Он постоянно портит это исправление конкурентного доступа — я объяснял его уже три раза».

«Повышай уровень рассуждений. Это ошибка, требующая серьёзного анализа, а с настройкой по умолчанию он обдумывает подход недостаточно долго».

Минимальная единица, которую модель читает и записывает. По размеру она примерно соответствует слову, но не всегда: распространённые слова состоят из одного токена, а редкие или длинные могут делиться на несколько. Размер контекстного окна, стоимость и задержка измеряются в токенах.

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

Для приблизительной оценки считайте, что на один токен приходится около трёх четвертей английского слова: тысяча токенов — это примерно 750 слов. С кодом всё менее предсказуемо: распространённые ключевые слова и идиомы токенизируются компактно, а автоматически созданные идентификаторы, хеши, строки base64 и минифицированный вывод могут разбиваться на множество токенов на одно «слово». Принцип такой: часто встречавшийся в исходных материалах токенизатора текст получает короткие эффективные кодировки, а незнакомый ему текст дробится на множество небольших частей. Хеш вроде `a3f9c2e1` нигде ранее не встречался, поэтому он распадается на много токенов, тогда как `function` — один. Вот почему небольшой на вид файл с множеством необычных строк может занять неожиданно большую часть контекстного окна.

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

Избегайте: слова «слово» — границы токенов не совпадают с границами слов, а важны именно токены в секунду и токены за доллар.

Пример использования:

«Насколько большим получится этот промпт?»

«Пропустите его через токенизатор: схема компактна, но ключи JSON необычные, поэтому они распадутся на большее число токенов, чем вы думаете.»

То, что на самом деле делает модель. Получив контекст, она выбирает следующий токен, добавляет его и повторяет процесс. Любой результат — предложение, вызов инструмента или файл на тысячу строк — строится по одному токену за раз. Другого способа работы у модели нет.

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

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

Пример использования:

«Как агент „решает“ вызвать инструмент?»

«Никак — в основе всего лежит предсказание следующего токена. Вызов инструмента — это просто структурированная строка, которую каркас извлекает из потока результата.»

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

Так устроено порождение текста моделями и обработка запросов поставщиками моделей. Во время вывода модель строит распределение вероятностей для возможных следующих токенов, а затем из него выбирается один — обычно намеренно с некоторой случайностью, поскольку постоянный выбор наиболее вероятного токена даёт повторяющийся текст худшего качества. Один токен, иначе выбранный в начале ответа, меняет каждый последующий; так одно другое слово превращается в совершенно иной подход. Обработка на стороне поставщика добавляет ещё больше вариативности: запросы объединяются в пакеты на общем оборудовании, а крошечные различия чисел с плавающей точкой между пакетами могут склонить близкий выбор в пользу одного из двух токенов. Нет такой настройки, которую можно переключить и полностью устранить эту вариативность.

Ожидайте разброса результатов агента, даже если задача одна и та же. Большинство ответов укладывается в приемлемую колоколообразную кривую качества — иначе недетерминированность была бы совершенно невыносима, — однако крайние случаи реальны: в один день модель работает чётко, в другой будто теряет нить. Та же задача, другой бросок костей. Отсюда следуют два практических вывода. Повторная попытка — разумная стратегия: неудачная попытка является одним случайным результатом, а новый запуск той же задачи может оказаться лучше. Проверка важнее, чем при работе с детерминированными инструментами: поведение агента нельзя проверить один раз и рассчитывать, что оно повторится, поэтому автоматические проверки должны отлавливать неудачные результаты.

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

Пример использования:

«Сегодня Claude ужасен. Они выпустили ухудшенную версию?»

«Скорее всего, нет — результаты модели недетерминированы. На одной и той же задаче будут удачные и неудачные дни. Попробуйте завтра, прежде чем искать причину.»

Всё, что предоставляет модель для вывода. Обычно это удалённый сервис (Anthropic, OpenAI или Google), но поставщик может быть локальным — например, Ollama, LM Studio или llama.cpp на вашем компьютере. Сам каркас не запускает модель, а обращается к поставщику.

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

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

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

Пример использования:

«Можно запускать это без подключения к сети для клиента с изолированной системой?»

«Переключите поставщика модели на локальный, например Ollama или llama.cpp на его машине. Каркасу всё равно — он просто обращается к другой конечной точке.»

Всё вокруг модели, что превращает её в агента: инструменты, системная подсказка, управление контекстным окном, разрешения, хуки. Claude.ai и Claude Code работают на одной модели, но ведут себя по-разному из-за различий их harness.

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

Это важно для диагностики. Когда поведение отличается между двумя продуктами или между вчера и сегодня, переменной часто оказывается не модель, а harness. Другая системная подсказка, другой набор инструментов, изменённое разрешение по умолчанию или новая стратегия управления контекстом меняют поведение без каких-либо изменений модели. Это также значит, что большая часть настроек находится в harness: файлы AGENTS.md, разрешения и хуки — инструкции для harness, а не для модели.

Примеры: Claude Code, Cursor, Codex CLI и Claude.ai, который является чатовым, а не программирующим harness.

Пример использования:

«Модель та же — почему Claude Code редактирует файлы, а Claude.ai только отвечает на вопросы?»

«Harness разные: Claude Code располагает инструментами файловой системы, другой системной подсказкой и уровнем разрешений. Дело не в модели».

Один обмен данными между каркасом и поставщиком модели. Каркас отправляет текущий контекст, а поставщик возвращает один ответ (вызов инструмента или итоговый ответ). Одно сообщение пользователя может породить множество запросов к поставщику модели, если агент вызывает инструменты: каждый результат инструмента запускает следующий запрос.

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

Запрос — также единица тарификации. Входные токены, выходные токены и скидки за кэш учитываются для каждого запроса. Поэтому невинно выглядящий вопрос может неожиданно дорого обойтись: стоимость пропорциональна не вашему сообщению, а числу запросов, умноженному на объём контекста в каждом из них.

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

Шесть запросов за один ход — и каждый заново отправляет весь контекст. Если вы думаете, куда делись токены, считайте запросы, а не ходы.

Пример использования:

«Один вопрос потратил сорок тысяч токенов?»

«Посмотрите на вызовы инструментов: двенадцать grep, восемь чтений, четыре изменения. Каждый результат инструмента порождает новый запрос к поставщику модели, который каждый раз повторно отправляет весь префикс сессии.»

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

При программировании с ИИ большая часть счёта приходится на входные токены. Модель не хранит состояние, поэтому каждый ход повторно отправляет всю сессию: первое сообщение, каждый ответ и все результаты инструментов с начала разговора. Входные данные пятидесятого хода включают предыдущие сорок девять ходов. Один запрос к поставщику модели может создать несколько сотен выходных токенов, повторно отправив при этом сто тысяч входных токенов накопленной истории.

Кэш префикса снижает стоимость: история, точно совпавшая с предыдущим запросом, тарифицируется как дешёвые токены кэша, а не как обычные входные токены. Если входные данные всё ещё обходятся дорого, уменьшите объём повторно отправляемого текста — очистите контекст или сожмите его между задачами.

Пример использования:

«Счёт высокий, хотя агент почти ничего не пишет».

«Это входные токены: каждый ход повторно отправляет всю сессию. Без кэша префикса история снова оплачивалась бы при каждом запросе.»

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

Считается всё, что пишет модель: читаемый вами текст, код, вызовы инструментов и расширенное обдумывание перед ответом. Последнее удивляет пользователей: токены рассуждений тарифицируются как выходные, даже если каркас часто не показывает их, а увеличение усилия расходует больше таких токенов.

Выходные токены также определяют темп сессии. Модель быстро читает ввод, но генерирует ответ по одному токену, поэтому если ход кажется медленным, почти всегда медленно создаётся результат, а не читается ввод. Долгое ожидание обычно означает, что ответ будет длинным.

Пример использования:

«Сессия рефакторинга расходует кредит, хотя входные данные небольшие».

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

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

Кэш полезен потому, что сессии растут только за счёт добавления новых данных. Каждый запрос повторно отправляет всю историю как входные токены (причина описана в соответствующей статье), а в обычной сессии история меняется только в конце: каждый новый запрос содержит предыдущий плюс несколько новых сообщений. Поставщик один раз обрабатывает длинное общее начало, сохраняет результат и продолжает с того места, где заканчивается префикс. Без кэша в сессии из 50 ходов пришлось бы заново обработать первый ход пятьдесят раз.

Срок действия кэша ограничен. Время хранения записи зависит от поставщика модели — обычно это минуты, а не часы. Если оставить сессию бездействовать дольше этого окна, следующий запрос заново соберёт префикс по полной цене; затем кэширование возобновится. Это важно главным образом для разработчиков каркасов; пользователь замечает лишь, что запросы после долгого перерыва стоят дороже предыдущих.

Пример использования:

«Почему в середине сессии счёт резко вырос?»

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

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

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

Пример показывает, что кэшируется, а что нет. Каждая буква обозначает блок переписки; каждый запрос отправляет накопленный разговор:

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

Пример использования:

«Долгие сессии обходятся ужасно дорого — восемь долларов за рефакторинг».

«Проверьте токены кэша. Если каркас переставляет системный промпт или файлы между ходами, префикс перестаёт совпадать, и каждый запрос снова оплачивает входные токены по полной ставке.»

Не переносит информацию вперёд. Модель не сохраняет состояние между запросами к поставщику модели: в каждом запросе отправляется всё контекстное окно, потому что у модели нет другого способа что-либо увидеть. По умолчанию агент не сохраняет состояние между сессиями: новая сессия начинается пустой, без следов предыдущих. Противоположность состоянию.

Модель сама по себе всегда остаётся без состояния: её параметры фиксируются после обучения, и ничто из того, что вы делаете во время инференса, их не меняет. Модель не учится на ваших исправлениях, не помнит, что ей вчера сказали то же самое, и не узнаёт вас — как бы убедительно ни казалось обратное в разговоре. Непрерывность внутри сессии создаёт harness: он хранит стенограмму и отправляет её заново при каждом запросе. Модель не помнит разговор — она перечитывает его.

Практическое следствие: если нужно, чтобы информация пережила несколько сессий, запишите её туда, откуда агент сможет прочесть её позже. Для этого и существуют файлы AGENTS.md, системы памяти и артефакты передачи работы: они загружаются в контекст будущих сессий и заменяют отсутствующую у модели память. Если агент снова и снова совершает ошибку, которую вы уже исправляли, вопрос не в том, почему он не научился, — он не может учиться таким образом. Вопрос в том, куда записать исправление, чтобы его прочла каждая будущая сессия.

Пример использования:

«Почему он каждый раз забывает соглашение, когда я очищаю контекст?»

«Модель не сохраняет состояние — новая сессия начинается пустой. Если нужно перенести это дальше, запиши соглашение в AGENTS.md или файл памяти, который harness загружает при запуске».

Информация, которая сейчас доступна агенту и относится к задаче. Это абстрактное понятие, а не необработанный ввод, который видит модель (это контекстное окно), и не текущая история переписки (это сессия), а именно то, что агенту известно и имеет отношение к задаче. «Загрузить что-то в контекст» означает включить это в такой набор; «инженерия контекста» — практика его отбора.

Три термина чётко различаются:

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

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

Пример использования:

«Он продолжает придумывать поля, которых нет в типе.»

«Файла с типами нет в контексте — он читает места вызова и гадает. Сначала прочитай определение.»

Всё, что модель видит в каждом запросе к поставщику модели. Объём конечен и зависит от модели; это единственная поверхность, через которую модель что-либо воспринимает.

Это одна последовательность токенов: системная подсказка, весь разговор до этого момента, каждый результат инструмента, возвращённый harness. Если что-то попало в эту последовательность, модель может это использовать; если нет, она не знает о существовании этого — ни о вашей кодовой базе, ни о файле, который вы редактировали вчера, ни об инструкции, данной три сессии назад. Чтобы повлиять на работу, всё за пределами окна нужно туда передать — обычно через вызов инструмента.

Окно конечно, поэтому оно заполняется. С каждым ходом в него добавляется больше данных: ваши сообщения, ответы модели, результаты инструментов. Долгая сессия в конце концов достигнет предела, после чего потребуется уплотнение или очистка. Кроме того, элементы окна конкурируют между собой: каждый добавленный токен уменьшает место, доступное остальным, а ненужное содержимое всё равно занимает внимание модели. Лучше относиться к окну как к бюджету: загружать то, что нужно задаче, а остальное оставлять за его пределами.

Избегайте: слова «память»: контекстное окно — рабочее состояние, которое не переносится между сессиями. Память — отдельная концепция, добавляемая поверх него.

Пример использования:

«Можно просто вставить в запрос весь монорепозиторий?»

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

Передаёт информацию дальше. Сессия сохраняет состояние между ходами: контекст накапливается по мере работы, поэтому долгие сессии постепенно попадают в зону отупения. Агент может сохранять состояние между сессиями, если добавить систему памяти, которая записывает информацию в среду и загружает её в начале будущих сессий. Модель никогда не сохраняет состояние; видимость непрерывности создаёт harness, повторно передавая контекст. Противоположность отсутствию состояния.

Где хранится состояние на каждом уровне:

Состояние каждого уровня создаётся повторным чтением данных, сохранённых уровнем ниже: сессия кажется непрерывной, потому что harness повторно отправляет историю сообщений модели без состояния; агент помнит между сессиями, потому что harness снова загружает файлы из среды. Сама модель никогда не хранит состояние.

Сохранять состояние нужно не всегда. Всё перенесённое вперёд влияет на то, что произойдёт дальше, поэтому вместе с ним переносится и неверное предположение, сделанное в начале сессии. Очистка — намеренное удаление состояния сессии и новый старт на основе записанного.

Пример использования:

«Он запомнил мои предпочтения со вчерашнего дня — значит ли это, что модель обучилась на них?»

«Нет, состояние сохраняет агент: harness записал предпочтения в файл памяти и загрузил его в начале сессии. Сама модель ничего не знала о вчерашнем дне».

Модель, подключённая к harness с инструментами, системной подсказкой и контекстным окном, которая ведёт с пользователем диалоговые ходы. Claude Code — агент. Cursor — агент. Claude.ai — агент. Агент — это тот, с кем вы на самом деле разговариваете: модель в действии, настроенная для определённой цели.

В отличие от большинства терминов этого словаря, «агент» не обозначает механическую часть. Модель — это файл с параметрами, а harness — программное обеспечение, которое можно указать. Агент — ни то ни другое: это единица, с которой вы общаетесь. Люди постоянно очеловечивают ИИ, и агент — это очеловеченная единица: тот, кому вы делегируете задачу, кто читает ваше сообщение и отвечает, то самое «оно» в фразе «оно опять сломало сборку». Когда вы говорите, что агент что-то сделал, вы имеете в виду модель вместе с harness, но обращаетесь к этому сочетанию как к единому действующему лицу.

Идея старше нынешней волны ИИ. Программные агенты — программы, которым делегируют цель и которые действуют от вашего имени, — существуют столько же, сколько существует ИИ.

Избегайте: «ИИ», «бот» — слишком расплывчато; такие слова скрывают, имеете ли вы в виду параметры модели или подключённую к harness систему.

Пример использования:

«Какого агента ты используешь для миграции?»

«Claude Code локально, Cursor для работы над интерфейсом — под ними одна и та же модель, но разные harness».

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

Системный промпт пишет поставщик каркаса, а не вы, и в программных каркасах он велик — нередко содержит десятки тысяч токенов с правилами поведения, описаниями инструментов и обработкой крайних случаев; всё это оплачивается как входные токены в каждом ходе. Ваши постоянные инструкции добавляются к нему: файлы вроде AGENTS.md загружаются в начале сессии рядом с системным промптом, поэтому модель читает задание поставщика и ваше задание вместе ещё до того, как увидит ваше сообщение.

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

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

Пример использования:

«Два каркаса, одна модель, но с одним и тем же промптом поведение совершенно разное.»

«Разные системные промпты. Один настроен на краткие правки кода, другой — на объяснения. Различие задаётся ещё до того, как приходит ваше сообщение.»

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

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

Эта память заканчивается вместе с сессией. Новая сессия начинается с нуля: агент, который к концу вчерашней сессии хорошо знал вашу кодовую базу, сегодня утром уже ничего о ней не знает. Сохраняется файловая система: файлы, записанные в одной сессии, можно прочитать в следующей; на этом основаны передачи работы, системы памяти и AGENTS.md.

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

Пример использования:

«Как долго может длиться одна сессия, прежде чем всё начнёт разваливаться?»

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

Одно сообщение пользователя и всё, что агент делает в ответ, пока не вернёт управление пользователю. Содержит один или несколько запросов к поставщику модели — много, если агент вызывает инструменты. Уточняющий вопрос завершает ход; ваш ответ начинает следующий. Иерархия: сессия > Ход > Запрос к поставщику модели.

Ход заслуживает отдельного названия потому, что его длительность определяет агент, а не вы. Вы передаёте одно сообщение; агент решает, сколько вызовов инструментов объединить в цепочку, прежде чем вернуть управление. Ход может занять одно предложение или двадцать минут чтения, редактирования и запуска тестов. Это одно свойство, рассмотренное с двух сторон: длинные ходы позволяют работать в ваше отсутствие, но во время них также может незаметно что-то пойти не так — к моменту ответа агент способен далеко отойти от того, что вы имели в виду.

Ход также естественно подходит для управления работой. Всё внутри хода происходит без вашего участия; между ходами вы можете направлять агента. Большинство каркасов смягчает это ограничение: можно прервать агента посреди хода, чтобы остановить его и перенаправить, или написать сообщение, пока он работает; агент прочитает его, когда закончит ход. Если вас снова и снова не устраивают результаты, обычно стоит попросить о более коротких ходах — сначала план, затем один шаг за раз, — обменяв часть автономности на более частые возможности направлять работу.

Пример использования:

«Один ход занял две минуты?»

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

Мир, на который действует агент: всё за пределами каркаса, что агент воспринимает через результаты инструментов и изменяет посредством вызовов инструментов. Каркас запускает агента; среда — то, в чём он работает. Файл вроде `AGENTS.md` находится в среде; именно каркас загружает его в контекстное окно. Файловая система — самый распространённый, но не единственный тип среды: ею также могут быть база данных, удалённый API или сессия браузера.

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

Среда также является уровнем, который сохраняется, — единственным, всегда обладающим состоянием. Контекст сессии исчезает по её завершении, но файлы, записанные в среду, остаются для следующей сессии. На этом основаны системы памяти, артефакты передачи работы и `AGENTS.md`. Всё, что агенту нужно знать завтра, должно оказаться в среде.

Вы определяете размер среды. Песочница сужает её, ограничивая доступ агента; добавление инструмента расширяет её, предоставляя доступ к базе данных или API. Агент может воспринимать и изменять то, что находится внутри границы; всё за её пределами для него не существует. Насколько хорошо среда подготовлена для работы агента, определяет AX кодовой базы.

Избегайте: использовать слово «среда» для обозначения среды выполнения или самого каркаса — каркас является оболочкой, среда является рабочим пространством.

Пример использования:

«Агент не видит схему базы данных staging.»

«Подключите её к среде — предоставьте инструмент `psql` с доступом только для чтения к staging. С каркасом всё в порядке, ему просто нечем пользоваться.»

Дерево файлов и каталогов, из которого агент читает данные, в который записывает их и внутри которого выполняет команды; это стандартный тип среды для программирующего агента. В файловой системе находятся AGENTS.md, навыки, исходный код, скрипты сборки и конфигурации инструментов. Когда harness «запускается в вашем проекте», это значит, что он указывает агенту на файловую систему.

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

Эта файловая система общая и для вас. Файлы, которые редактирует агент, — те же файлы, что вы открываете в редакторе и сравниваете в git. Файловая система — общее рабочее пространство, в котором вы просматриваете работу агента.

Пример использования:

«Почему он не подхватывает мой AGENTS.md?»

«Он работает в другой файловой системе: песочница подключила родительский каталог, а не корень проекта. Перенастрой harness».

Функция, которую harness предоставляет агенту для вызова: Read, Write, Bash, Search. Через инструменты агент воспринимает среду и действует в ней: он может видеть её только через результаты инструментов, а изменять — только через вызовы инструментов. Каждый вызов инструмента требует дополнительного запроса к поставщику модели, поскольку результат должен вернуться модели, прежде чем она решит, что делать дальше.

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

Инструмент определяется тремя вещами: названием, описанием назначения и схемой параметров. Harness отправляет эти определения модели с каждым запросом, а модель выбирает инструмент так же, как генерирует всё остальное, — записывая токены, в данном случае структурированный вызов с аргументами. Сама модель ничего не запускает: harness получает вызов, выполняет функцию и отправляет результат обратно.

Список инструментов определяет возможности агента. Мощная модель с узким набором инструментов — это узкий агент: он будет направлять всё через доступные средства, поэтому агенты так часто полагаются на Bash — один инструмент даёт доступ почти ко всей системе. Чтобы добавить агенту возможность, явно предоставьте ему нужный инструмент; MCP — стандарт подключения инструментов извне harness.

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

Пример использования:

«Может ли агент напрямую запрашивать данные на staging?»

«Добавь в harness инструмент `psql` с доступом только для чтения к staging. Без такого инструмента агент ничего не видит за пределами файловой системы».

Результат работы модели, в котором указаны инструмент и его аргументы, — просто структурированный текст. Сам по себе он ничего не делает: каркас должен прочитать его и выполнить. Модель создаёт такой результат в одном запросе к поставщику модели.

Жизненный цикл вызова инструмента:

Один ход работы агента обычно состоит из множества таких обменов, объединённых в цепочку.

Поскольку вызов, как и любой другой ответ модели, создаётся посредством предсказания следующего токена, он может содержать ошибку: несуществующий путь, неподдерживаемый командой флаг или правдоподобные, но неверные аргументы. Каркас выполняет написанное, а не задуманное — при опечатке в пути он не просто выдаст ошибку, а изменит не тот файл.

Пример использования:

«Он сказал, что запустил тесты, но временные отметки файлов не изменились».

«Посмотрите стенограмму: он действительно создал вызов инструмента или только описал запуск тестов? Модель создаёт вызов, но если каркас его не выполнил, ничего не произошло.»

То, что каркас возвращает после выполнения вызова инструмента: содержимое файла, вывод команды или сообщение об ошибке. Это единственное, что агент видит о среде. Результат передаётся обратно модели в следующем запросе к поставщику модели, после чего модель решает, что делать дальше. Вызов инструмента и его результат — две стороны одного обмена, которые происходят в рамках одного хода.

Жизненный цикл результата инструмента:

Результат остаётся в контексте до конца сессии. Результаты инструментов обычно составляют большую часть контекста сессии программирования: каждый прочитанный файл, каждый запуск тестов и каждый поиск попадает туда целиком и продолжает занимать токены, даже когда уже перестал быть полезным. Несколько больших результатов — подробный журнал тестов или целиком прочитанный сгенерированный файл — могут приблизить сессию к пределу контекстного окна быстрее, чем сама переписка.

Поскольку результат — это всё, что видит модель, она не может проверить среду напрямую. Если вывод обрезан, команда незаметно завершилась с ошибкой или каркас вернул ошибку вместо содержимого, модель рассуждает на основании того, что ей передали. Если представление агента о системе кажется неверным, проверьте результаты инструментов: где-то в переписке есть результат, который противоречит известным вам фактам.

Пример использования:

«Он рассуждает о файле, как будто тот пустой».

«Вместо содержимого результат инструмента сообщил об отказе в доступе. Модель видела только текст ошибки — другого способа увидеть файл у неё нет.»

Model Context Protocol. Протокол для подключения внешних серверов инструментов к harness — именно так agent получает tools, помимо тех, что входят в комплект harness. Агент никогда не «вызывает MCP»: он вызывает инструмент, а harness просто получил этот инструмент с MCP-сервера. Протокол также предоставляет ресурсы (данные только для чтения) и подсказки (повторно используемые шаблоны), но его основное назначение — предоставление инструментов.

Протокол решает проблему интеграции. Без стандарта каждому harness пришлось бы отдельно создавать и поддерживать собственные интеграции с Linear, Slack и базами данных. С MCP интеграция один раз реализуется в виде сервера, и её может использовать любой совместимый с MCP harness. Harness подключается к серверу, сервер объявляет доступные инструменты, и они становятся доступны агенту наряду со встроенными.

Цена за это — context. Каждый инструмент, объявленный сервером, поступает как определение: название, описание и схема параметров. model может вызывать только те инструменты, о которых знает. Наивный подход загружает все определения в context window заранее: установите несколько щедро оснащённых серверов, и session начнётся с тысяч tokens схем инструментов ещё до того, как вы что-либо напечатаете. Так расходуется attention budget на инструменты, которые задаче никогда не понадобятся.

Многие harness теперь смягчают эту проблему поиском инструментов: вместо полных определений в контексте хранится context pointer к доступным инструментам — агент ищет инструмент по названию или назначению и загружает его определение только при необходимости. Если ваш harness этого не делает, начальные затраты сохраняются, поэтому стоит включать только те серверы, которые действительно нужны проекту.

Пример использования:

«Агенту нужно читать задачи из Linear».

«Настрой harness на использование сервера Linear MCP — он предоставляет API Linear в виде инструментов, которые может вызывать агент. Так не придётся писать собственные обёртки для инструментов»._

То, что каркас показывает пользователю перед выполнением вызова инструмента, который не был заранее разрешён. Модель создаёт вызов инструмента, но вместо немедленного выполнения каркас приостанавливается и запрашивает подтверждение. Если вы разрешите действие, оно выполнится; если отклоните — каркас передаст отказ модели как результат инструмента. Так каркас включает человека в контур для рискованных или чувствительных действий.

Жизненный цикл запроса на разрешение:

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

Цена такого подхода — каждый запрос заставляет вас ждать ответа. Агент не может продолжить, пока вы не ответите. Это удобно, пока вы наблюдаете за его работой, но мешает, когда вас нет: агент, который постоянно запрашивает разрешения, не может работать без присмотра. Режим разрешений регулирует, какие вызовы выполняются свободно, а какие требуют подтверждения; песочница помогает безопасно расширить список разрешённых действий.

Пример использования:

«Он уже десять минут ждёт разрешения — я был на встрече».

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

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

Каркасы предлагают несколько уровней таких режимов:

Выбор уровня — компромисс между безопасностью и перебоями, причём ощущаются оба вида сбоев. Если режим слишком строгий, вы становитесь узким местом: агент каждые несколько секунд останавливается ради безвредного чтения, вы машинально нажимаете «Разрешить», и подтверждения перестают что-либо значить. Штамповать одобрения — худшее из обоих миров: сплошные перебои без защиты. Если режим слишком свободный, агент редактирует файлы и выполняет команды, которые вы хотели бы сначала увидеть.

Свободный режим легче всего оправдать внутри песочницы, где последствия неудачного вызова инструмента ограничены. Без неё большинство людей настраивают автоматическое разрешение чтения, а для всего необратимого оставляют человека в цикле.

Пример использования:

«Он останавливался на каждом grep — запуск без присмотра был полностью сорван.»

«Ослабьте режим разрешений для инструментов только для чтения, а запросы при записи и запуске shell оставьте. Большинство запросов разрешений во время исследовательской сессии — просто шум.»

Предустановка, которая задаёт поведение агента во время работы: она объединяет режим разрешений с поведенческими инструкциями, добавляемыми в системную подсказку. Примеры: режим по умолчанию запрашивает подтверждение для рискованных вызовов; режим планирования блокирует правки и направляет агента к исследованию; режим accept-edits автоматически одобряет правки; режим bypass permissions (в просторечии режим YOLO) одобряет всё автоматически. Режим можно изменить посреди сессии.

От простой настройки разрешений режим отличается объединением этих двух частей. Режим разрешений — это лишь заслон: он решает, какие вызовы инструментов проходят. Сам по себе заслон оставляет агента, который хочет редактировать, но не может: он предлагает запись, получает отказ и пробует другой способ. Добавленные инструкции устраняют само желание: режим планирования не просто блокирует правки, а объясняет агенту, что сейчас идёт этап планирования, поэтому тот читает, задаёт вопросы и предлагает решения вместо попыток пробиться через заслон. Заслон и направление работают в унисон.

На практике режим меняют вместе с уровнем доверия к агенту по мере выполнения задачи. Одна задача может проходить через несколько режимов: планирование, пока вы уточняете подход; режим с подтверждениями для первых деликатных правок; accept-edits после того, как агент показал, что понял изменение; bypass для автономного запуска внутри песочницы. Смена режима ничего не стоит: диалог продолжается с того же места, но меняются разрешения и инструкции. Если вы одобряете каждый запрос, не читая его, режим настроен строже, чем соответствует вашему уровню доверия; если постоянно отклоняете правки — мягче.

Термины поставщиков: в Claude Code это называется «режимами разрешений», а в Codex — «режимами одобрения»; оба термина появились раньше, чем поведенческие инструкции стали частью режима.

Пример использования:

«Он постоянно редактирует файлы, хотя мне нужен только план».

«Переключись в режим планирования — он заблокирует запись и оставит агента на этапе исследования».

«А что выбрать для более позднего автономного запуска?»

«Режим bypass, но только внутри песочницы».

Изолированная среда, внутри которой работает агент: контейнер, виртуальная машина, временная файловая система или оболочка с ограниченными разрешениями. Она ограничивает радиус последствий действий агента: даже если он выполнит разрушительную команду или загрузит что-то вредоносное, ущерб останется внутри. Это основа безопасности, делающая автономную работу практичной.

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

Уровни изоляции:

Что не может изолировать ни одна песочница: действия, которые легитимно выходят за её границы. Агент с вашими учётными данными git может отправить изменения; агент с сетевым доступом может вызывать производственные API. Прежде чем решать, насколько толстой должна быть граница, определите, что может её пересекать.

Пример использования:

«Я хочу разрешить ему работать ночью в режиме bypass-permissions, но пока не готов к этому».

«Помести его в песочницу: новый контейнер, без подключённых учётных данных и без выхода в сеть. В худшем случае он уничтожит собственную файловую систему, а контейнер можно будет удалить».

Уверенно согласный ответ модели. Возникает из-за обучения: модель настроили предпочитать ответы, которые нравились людям, а люди чаще любят согласие, чем возражения. Так модель усвоила, что за согласие вознаграждают, даже когда оно неверно.

Проявляется так:

• Уступает под давлением — меняет верный ответ на противоположный, когда вы спрашиваете: «Вы уверены?».
• Хвалит плохой ввод — называет ваш неработающий план блестящим, прежде чем его проанализировать.
• Предвзятая оценка — обзор становится положительным, если вы говорите, что написали текст, и отрицательным, если приписываете его кому-то другому. Тот же артефакт — другой вердикт.
• Подражание — повторяет ваши ошибки как подтверждение.

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

Исправление: не раскрывайте свои предпочтения. Формулируйте запрос нейтрально: «проверь этот код», а не «хороший ли это код?».

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

Пример использования:

«Он сказал, что мой план рефакторинга выглядит отлично, а потом я спросил: „Вы уверены?“ — и он от всего отказался».

«Классическая угодливость: сначала он согласился, потому что вы звучали уверенно, потом отступил, потому что вы выразили сомнение. Качество плана не изменилось — изменился ваш тон. Очистите контекст и спросите заново, не подсказывая ответ».

Уверенный, но неверный ответ модели. Есть два варианта с разными причинами и способами исправления:

Предсказание следующего токена создаёт беглый ответ вне зависимости от того, существует ли сам факт. У модели нет внутреннего сигнала о том, что она чего-то не знает, поэтому выдуманный метод звучит так же уверенно, как правильный. Галлюцинированный код правдоподобен по определению: он выглядит именно так, как выглядел бы API, если бы существовал. Поэтому он проходит поверхностную проверку и проваливается только при запуске.

Важно понять, какой вариант перед вами, потому что исправление одного усугубляет другой. Фактическая неточность означает нехватку знаний; решение — добавить контекст: документацию, определения типов или файл. При нарушении верности знания уже присутствуют, но проигрывают борьбу за внимание; решение — убрать лишний контекст. Если принять потерю верности за нехватку фактов и вставить ещё документацию, контекст вырастет, и ответ будет отклоняться ещё сильнее. Когда агент ошибается, сначала проверьте, был ли правильный ответ уже в контексте, и лишь затем решайте, с какой проблемой вы столкнулись.

Избегайте: использовать слово «галлюцинация» как общий синоним слова «ошибка». Без уточнения вида неточности этот термин не помогает поставить диагноз.

Пример использования:

«Он выдумал метод `parseAsync` у схемы».

«Это нехватка фактов или потеря верности контексту?»

«Метод есть в документации, которую я вставил, — он просто перестал её читать после сорокового хода».

«Значит, потеря верности. Уплотни контекст и загрузи документацию заново, не добавляй ещё больше документов».

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

Параметрические знания не хранятся как факты. Во время обучения модели не дают базу данных для поиска; её параметры настраивают так, чтобы она хорошо предсказывала текст. Модель, которая хорошо предсказывает текст о какой-либо теме, ведёт себя так, будто знает эту тему. Надёжность знаний зависит от того, насколько часто сведения встречались в обучающих данных: миллионы примеров помогают точно воспроизводить тему, а по нескольким примерам модель лишь догадывается, опираясь на похожие темы. Для модели воспроизведение и догадка — один и тот же процесс, и она не умеет различать их. Выдуманный ответ звучит так же бегло, как правильный. Галлюцинация — это ошибочная догадка модели.

Параметрические знания также устаревают. Параметры перестают меняться после даты отсечения знаний, поэтому выпущенная или переименованная позже библиотека в них отсутствует, а изменившийся API запомнен в старом виде.

Для обеих проблем — редких и новых сведений — решение одинаково: их нельзя добавить в параметры, поэтому их нужно передать как контекстные знания.

Пример использования:

«Он безупречно пишет на React, но выдумывает методы для нашей внутренней SDK».

«В параметрических знаниях много React: миллионы обучающих примеров. Вашей SDK там нет, поэтому модель достраивает правдоподобные конструкции. Загрузите документацию SDK в контекст.»

Дата, после которой у модели отсутствуют параметрические знания. Библиотеки, API и события, появившиеся позже этой даты, становятся ловушками для выдумок, если их документация не загружена как контекстные знания. У каждого выпуска модели своя дата отсечения.

Дата отсечения связана с тем, как создаются модели: в ходе обучения снимок текстовых данных записывается в параметры модели, после чего они замораживаются. Модель не знает, что её знания ограничены датой: если спросить о более позднем событии, она не откажется отвечать, а экстраполирует из ближайших сведений, которые ей известны. Ловушка незаметна: код для старой версии библиотеки выглядит правдоподобно, часто компилируется, но падает именно там, где библиотека изменилась.

Решение всегда одно: добавить свежую информацию в контекст. Загрузите журнал изменений, укажите на определения типов установленной версии или попросите агента прочитать документацию в интернете. Всё, что содержится в контексте, важнее отсутствующих в параметрах сведений.

Пример использования:

«Он постоянно пишет синтаксис SDK v3, а у нас уже v5».

«v5 выпустили после даты отсечения знаний. Загрузите журнал изменений v5 как контекстные знания, иначе агент продолжит выдумывать детали, опираясь на старую параметрическую версию.»

Факты, которые агент может прочитать непосредственно из контекста прямо сейчас: задача пользователя, прочитанные файлы, результаты инструментов, содержимое AGENTS.md, загруженное в начале сессии. Противоположность параметрическим знаниям: параметры модели позволяют вспомнить параметрическое знание, а контекстное знание прочитывается из окна. Галлюцинации намного реже, когда агент работает с контекстными знаниями: ответ находится прямо перед ним, а не извлекается из размытого воспоминания.

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

Если контекстные и параметрические знания противоречат друг другу, обычно побеждают контекстные. Вставьте актуальную документацию API — модель последует ей, а не устаревшему воспоминанию о старом API, хотя прежняя версия всё ещё может просачиваться, особенно в глубокой фазе долгой сессии. Если агент продолжает возвращаться к устаревшему подходу, несмотря на загруженную документацию, параметрическое знание просачивается сквозь контекстное; поможет повторить исправление или перенести его ближе к текущей работе.

В отличие от параметрических, контекстные знания требуют затрат. Всё, что загружено в окно, использует токены и конкурирует за бюджет внимания, поэтому загрузить больше — не всегда лучше. Цель — иметь в окне нужные факты, а не все факты.

Используйте этот термин только при противопоставлении параметрическим знаниям; в остальных случаях говорите просто контекст.

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

Пример использования:

«Почему с документацией перед глазами он точно работает с API, а без неё начинает всё выдумывать?»

«С документацией он использует контекстные знания — читает страницу. Без неё опирается на параметрические, и редкие конечные точки размываются».

При предсказании каждого токена модель учитывает все остальные токены в контексте: одни сильно, другие едва заметно. Связь между парой токенов называется отношением внимания; значимые пары (например, местоимение «её» и имя «Сара» или вызов `getUser()` и его определение `function getUser`) влияют друг на друга сильнее несвязанных. Для контекста из N токенов существует порядка N² таких отношений.

Именно в этих связях и проявляется кажущееся понимание модели. Правильно разрешая местоимение, модель опирается на сильную связь между «её» и «Сарой». Вызывая функцию с нужными аргументами, она использует связь между местом вызова и ранее прочитанным определением. Ничего из этого не ищется в справочнике: связи вычисляются заново для каждой пары при каждом запросе к поставщику модели.

На оценке N² стоит остановиться: число растёт быстрее, чем подсказывает интуиция:

Каждая связь вычисляется более одного раза. У моделей есть несколько голов внимания; точное число у передовых моделей не опубликовано, но разумная оценка — от пятидесяти до ста. Каждая голова вычисляет собственную версию каждой связи. Поэтому каждое число из таблицы нужно умножить на количество голов. Связей получается очень много.

Для конкретной задачи важны лишь некоторые из них. Связь между вашей инструкцией и кодом, которого она касается, — одна из немногих значимых; почти всё остальное — шум. При этом число важных связей остаётся примерно постоянным, а общий пул растёт квадратично вместе с размером контекста. При 1 000 токенов нужная вам связь — одна на миллион, при 100 000 — одна на десять миллиардов. Так устроен бюджет внимания; ухудшение внимания ощущается, когда значимые связи получают слишком малую долю общего числа.

Пример использования:

«Он постоянно путает два символа `user` в diff — похоже, мы попали в умную зону».

«Связь внимания между каждым местом вызова и его объявлением конкурирует с другой: форма токена одна, а привязки разные. Переименуйте один из них — связи станут яснее.»

У каждого токена есть конечное влияние, которое распределяется между остальными элементами контекста. Сильное влияние на одну взаимосвязь оставляет меньше для других. Бюджет каждого токена не увеличивается вместе с контекстом, поэтому в длинных сессиях влияние размывается.

Представьте сигнал и шум. Ваша инструкция — сигнал фиксированной громкости; каждый другой токен в контекстном окне — конкурирующий звук. Инструкция не становится тише — она всё ещё есть, символ за символом, — но по мере роста контекста вокруг неё становится шумнее, и отношение сигнала к шуму падает. Инструкция, звучавшая громче всего при контексте в 10k токенов, тонет в общем шуме при 150k. Так работает ухудшение внимания: модель не забывает — сигнал теряется в шуме.

Это похоже на непослушание: агент сначала согласился соблюдать ограничение, а потом от него отступает; повторная вставка ограничения помогает лишь ненадолго. Причина не в инструкции, а во всём остальном содержимом окна, конкурирующем с ней.

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

Пример использования:

«Почему он продолжает игнорировать схему, которую я вставил в самом начале?»

«Мы уже глубоко в зоне отупения: бюджет внимания каждого токена фиксирован, а контекст всё рос. Сигнал схемы теперь конкурирует с тысячами более новых токенов».

По мере роста сессии бюджет внимания каждого токена распределяется между всё большим числом конкурирующих элементов. Сигнал любой отдельной значимой взаимосвязи ослабевает; в контекст проникает шум от не относящейся к делу информации. Та же модель, те же параметры — просто за ту же тарелку еды конкурирует больше ртов. Это причина эффекта рабочей зоны и зоны отупения.

Это проявляется так, будто модель ухудшается посреди сессии: ограничения, которым она следовала целый час, начинают нарушаться; она повторно спрашивает о том, что ей уже сказали; пишет код, игнорируя файл, прочитанный раньше. С моделью ничего не изменилось — переменная только одна: объём контекста, на который теперь приходится обращать внимание.

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

Восстановить работу можно, убрав контекст, а не добавив его. Повторная вставка проигнорированной инструкции добавляет ещё одного конкурента в то же переполненное окно и помогает ненадолго. Что действительно работает: очистить контекст и загрузить только нужное задаче, уплотнить его или передать работу новой сессии. Снижение точности следования инструкциям — сигнал о длине контекста, а не о модели.

Пример использования:

«Она глубоко в зоне отупения — выдумывает обобщённые типы, которых нет в файле типов».

«Ухудшение внимания. Определения типов всё ещё в контексте, но их сигнал погребён под всем, что мы добавили после. Очисти его и загрузи нужное заново».

В начале сессии агент находится в «рабочей зоне»: он сообразителен, сосредоточен и хорошо вспоминает нужное. По мере роста сессии он попадает в «зону отупения»: работает небрежнее, забывает больше, чаще ошибается и создаёт больше галлюцинаций, отклоняющихся от контекста. Та же модель, тот же harness — просто больше контекста. Так ощущается ухудшение внимания. У передовых моделей зона отупения часто начинается примерно при 125K-150K токенов, хотя этот диапазон обсуждается. Очистите или уплотните сессию, когда она разрастается, — не пытайтесь просто продвинуться дальше.

Ухудшение постепенное, поэтому его легко не заметить. Нет сообщения об ошибке или видимой границы: сначала агент лишь немного хуже справляется, затем заметно хуже. Частые признаки: он забывает инструкцию, данную двадцать ходов назад, повторяет уже исправленную ошибку или уверенно утверждает то, чему противоречит контекст. Поскольку спад плавный, обычно пытаются продолжать и объяснять ещё раз — это добавляет контекст и усугубляет проблему.

Эти зоны не связаны с пределом контекстного окна. Сессия может глубоко зайти в зону отупения, пока большая часть окна ещё свободна: предел определяет момент, когда harness откажется продолжать, но качество падает намного раньше. Планируйте работу с учётом рабочей зоны, а не размера окна: практический бюджет задачи — объём токенов, в котором агент работает хорошо, а не объём, который он технически способен удерживать.

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

Пример использования:

«Первые три компонента он сделал блестяще, а четвёртый просто испортил».

«Ты уже вышел из рабочей зоны: та же модель, но теперь она глубоко в зоне отупения. Уплотни контекст и загрузи план заново — следующий компонент будет удачнее».

Завершение текущей сессии и запуск новой. Следующее сообщение начинается в пустой сессии с пустым контекстным окном. Обычно это делает пользователь.

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

Очистка не стирает разговор. Большинство harness сохраняет историю сессии на вашем компьютере, поэтому стенограмму всё ещё можно прочитать или продолжить. Исчезает рабочее состояние агента: модель не сохраняет состояние, поэтому новая сессия ничего не знает о предыдущей. Если в сессии есть решения или прогресс, нужные следующей, сначала попросите агента создать артефакт передачи работы, а затем начните новую сессию, указав на него.

Сравните с уплотнением, которое суммирует сессию в новом контексте, а не начинает с пустого окна. Очистка — более грубый инструмент: ничего не переносится, в том числе и мусор.

Пример использования:

«Он зациклился на неудачном тесте».

«Просто очисти контекст — начни новую сессию с планом и файлом теста. Незачем бороться с прежним контекстом».

Перенос контекста агента из одной сессии в другую. Способ переноса может быть разным: письменный артефакт передачи работы, краткое изложение в памяти (сжатие контекста) и другие варианты. Перенос отличается от очистки, при которой ничего не переносится. Причины бывают разные: смена ролей (планировщик → исполнитель), запуск работы без присмотра, распределение задач между параллельными сессиями или освобождение места в контекстном окне.

Новая сессия начинается с нулевым контекстом: модель не хранит состояние, и новая сессия ничего не видит из старой. Всё необходимое для следующей сессии нужно перенести явно; всё остальное исчезнет. Ограничение «обратного пути нет» определяет способ переноса: новая сессия не может спросить старую, что она имела в виду, поэтому передаваемые материалы должны быть понятны сами по себе.

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

Пример использования:

«Сессия планирования уже перегружена — продолжать?»

«Передайте работу. Запишите решения в документ, очистите контекст и начните реализацию в новой сессии, прочитав этот документ.»

Первоначальный источник достоверной информации: исходный код, стенограмма разговора, необработанный журнал, фактический ответ API. Не описание чего-то, а само это. Противоположность вторичному источнику.

Если нужно понять, что делает кодовая база, первичный источник — это код. Документы, архитектурная схема и README лишь описывают его; эти описания были точны на момент написания и с тех пор обновляются по собственному графику. Если агент уверенно утверждает что-то неверное о вашем проекте, спросите, на какой источник он опирался: агент, прочитавший документ, унаследовал его устаревшие сведения; агент, прочитавший код, видит актуальную истину.

Стоимость мешает сделать первичные источники вариантом по умолчанию. Загрузка такого источника в контекстное окно обходится дорого: весь файл, вся стенограмма, каждый токен оплачивается как входной токен и конкурирует за бюджет внимания. Взамен вы получаете полноту: никто заранее не отфильтровал содержимое по своему мнению о том, что важно. В сводке, написанной в прошлом месяце, не может быть подробности, которая стала важна сегодня; первичный источник всё ещё её содержит.

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

Пример использования:

«Агент говорит, что логика повторных попыток постепенно увеличивает задержку, но я вижу, как она без остановки атакует конечную точку».

«Он прочитал это в документе о проектировании. Укажи ему на реальный модуль повторных попыток: когда важно поведение, работай с первичным источником».

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

Значительная часть работы с контекстом состоит в создании вторичных источников. Уплотнение превращает историю сессии в сводку, которая становится начальным контекстом следующей сессии. Субагент тратит собственный контекст на шумный поиск и возвращает короткий отчёт. Артефакт передачи работы сводит решения сессии к документу, который прочтёт следующая сессия. Системы памяти превращают полученные сессией знания в заметки. Каждый такой способ обменивает точность на свободное место.

У вторичных источников есть два типа недостатков. Во-первых, они теряют данные: при уплотнении может пропасть решение по схеме, а в отчёте — упоминание пограничного случая. Во-вторых, они устаревают: первичный источник меняется, а описание за ним не поспевает, и документы рассказывают об архитектуре прошлого квартала с уверенностью, уместной лишь для текущего. Если агент действует на основании вторичного источника, который потерял детали или устарел, он уверенно опирается на неверную информацию; исправление — вернуть его к первичному источнику.

Ни один из этих недостатков не делает вторичные источники ошибкой. Контекстное окно ограничено, а первичные источники дороги; без сводок, отчётов и документов передачи никакая крупная задача не поместится. Важно понимать, какие детали можно потерять, а какие нет, — и обращаться к первичному источнику, если потеря недопустима. Хороший вторичный источник содержит указатель на контекст, ведущий к оригиналу: сводка называет исходную стенограмму, документ — описываемый файл. Если описания недостаточно, читатель сможет перейти по указателю, а не работать с потерянными данными.

Пример использования:

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

«Документ — вторичный источник: предыдущая сессия записала свои представления, а не то, что действительно верно. Попроси новую сессию выполнить тесты авторизации и доверять первичному источнику».

Документ, используемый как способ переноса передачи работы: одна сессия записывает его в среду, чтобы другая могла его прочитать. Спецификации, задачи и планы — всё это артефакты передачи работы.

Его стоит написать потому, что модель не сохраняет состояние, поэтому после очистки сессии в ней ничего не остаётся. Решения, ограничения, незавершённые планы — всё исчезает вместе с содержавшим их контекстом. Среда сохраняется. Записав важное состояние в файл, вы переносите его туда, откуда следующая сессия сможет его получить.

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

Хороший артефакт составлен так, чтобы его можно было передать сессии, у которой нет никакого контекста. Указывайте точные пути к файлам, а не «файл, который мы обсуждали». Фиксируйте, что и почему решили, чтобы следующая сессия не пересматривала те же вопросы; отмечайте сделанное и оставшееся. Полезно сразу сказать сессии, которая его пишет, кому предназначен документ: «подготовь документ передачи для новой сессии, которая ничего не знает об этой работе».

Другой способ перенести контекст — уплотнение, которое суммирует данные в памяти. У артефакта есть два преимущества: он хранится на диске, где его можно прочитать и исправить до того, как на него кто-то положится, и его можно использовать повторно — одна и та же спецификация может ввести в курс дела пять параллельных сессий.

Пример использования:

«Как разделить эту работу между планирующим агентом и тем, кто реализует?»

«Попроси планировщика подготовить артефакт передачи: пути к файлам, решения, ограничения. Сессия исполнителя начнётся с указателя на этот документ и будет использовать его как задание».

Артефакт передачи работы, описывающий задачу на несколько сессий: что создаётся, а не то, как каждая сессия выполняет свою часть. Меняется по мере продвижения работы. Состоит из задач.

Спецификация нужна потому, что сессии можно отбросить, а большая работа никуда не исчезает. Всё, что требует больше усилий, чем помещается в одно контекстное окно, должно иметь место за пределами контекста — где-нибудь в среде агента, что переживёт очистку: например, в файле репозитория, задаче GitHub или доступном агенту трекере задач. Таким местом и становится спецификация: в ней указаны цель, ограничения, принятые решения и список задач с их статусами. Любая новая сессия сможет прочитать её и понять состояние работы, не наследуя накопившийся шум предыдущей.

Спецификации бывают в узнаваемых форматах, в основном унаследованных от привычных способов документирования командной работы. Документ с требованиями к продукту (PRD) сосредоточен на том, что увидит пользователь и зачем: функциях, поведении и критериях приёмки. Документ о проектировании или RFC делает упор на техническую сторону: выбранный подход, отвергнутые альтернативы и компромиссы. Для небольшой задачи ту же роль может сыграть простой `plan.md` со списком задач и флажками для отметки выполнения. Важен не стиль, а назначение: для агента всё это одно и то же — долговечное описание намерений, которое он читает в начале каждой сессии.

Пример использования:

«Может, всё это сделать за одну сессию?»

«Нет, оформи это как спецификацию: разбей на задачи и выполняй каждую в отдельной сессии. Если пытаться уместить всё в одно контекстное окно, ты попадёшь в зону отупения, ещё не дойдя до середины».

Артефакт передачи работы, задающий рамки одной рабочей сессии. Может существовать отдельно или быть дочерним элементом спецификации. Задачи могут блокировать друг друга или зависеть друг от друга, поэтому порядок выполнения следует из графа зависимостей, а не из линейного плана.

Главное ограничение — размер: одна сессия. Задачу нужно успеть завершить, пока сессия не вышла из рабочей зоны, и это ограничение можно проверить. Если сессии по вашим задачам регулярно теряют ясность до завершения работы, задачи слишком велики — разделите их. Если каждая сессия тратит большую часть контекста на подготовку ради пяти минут работы, задачи слишком мелкие — объедините их.

Хорошая задача написана для читателя, у которого нет никакого другого контекста. В ней есть цель, критерии приёмки и указатели на контекст, ведущие к нужным файлам и решениям, — всего достаточно, чтобы сессия начала работу, не пытаясь заново вывести то, что знала предыдущая.

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

Пример использования:

«С чего начать работу над спецификацией миграции?»

«Посмотри на граф задач: изменение схемы блокирует перенос данных, а перенос данных блокирует переключение API. Выбери лист графа и запусти для него сессию».

Передача работы, происходящая в памяти: история предыдущей сессии суммируется, и эта сводка становится начальным контекстом новой сессии. Потери неизбежны: стенограмма — первичный источник, а сводка — вторичный источник; подробности обмениваются на свободное место. Запускается вручную пользователем или автоматически через автоматическое уплотнение.

Механизм таков: контекстное окно имеет конечный размер, и долгая сессия его заполняет — в истории остаются каждый результат инструмента, каждый прочитанный файл и каждый неверный шаг. Когда история становится слишком объёмной, harness просит модель обобщить сессию, отбрасывает исходную историю и запускает новую сессию со сводкой. Всё, что не попало в сводку, исчезает из контекста. Некоторые harness смягчают потерю: они сохраняют прежнюю стенограмму на диске и оставляют в сводке указатель на контекст. Так вторичный источник ссылается на первичный, и утраченную подробность можно восстановить, перечитав оригинал.

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

Сравните с очисткой, которая удаляет всё и начинает с нуля: уплотнение старается перенести главное в новую сессию, а очистка рассчитывает, что главное уже записано где-то надёжнее.

Пример использования:

«Контекст разрастается, а мне ещё нужно провести тестирование».

«Уплотни его до начала тестирования: укажи в подсказке к сводке, что нужно сохранить, чтобы новая сессия удержала решения по схеме и отбросила исследовательскую часть».

Сжатие контекста, которое каркас запускает автоматически, когда контекстное окно почти заполнено.

Каркас отслеживает заполненность контекстного окна. Когда она достигает порога — часто около 80%, — он приостанавливает работу, просит модель кратко изложить текущую сессию и начинает новую сессию с этим резюме. Работа продолжается так, будто ничего не произошло.

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

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

Пример использования:

«Кажется, он забыл наше прежнее решение о схеме».

«Автоматическое сжатие произошло между ходами: ранние решения вошли в резюме, и, похоже, что-то потерялось. Загрузите план или в следующий раз сожмите контекст вручную, чтобы самим выбрать, что сохранить.»

Система, которая пытается сохранять состояние агента между сессиями. Во время сессии она записывает информацию в среду, а в начале будущих сессий загружает её обратно в контекстное окно, чтобы агент сохранял непрерывность после того, как пользователь очистил сессию.

У системы памяти две части. Запись: во время сессии агент сохраняет то, что узнал, — например, ваше предпочтение или факт о проекте, — в файлы среды. Чтение: в начале сессии harness загружает эти файлы или их индекс обратно в контекстное окно. Многие harness поставляются со своей системой памяти — например, команда `/memory` в Claude Code, — но её можно создать и самостоятельно: каталог заметок плюс инструкция в AGENTS.md, предписывающая обращаться к нему.

Действуют те же компромиссы, что и для любого содержимого, всегда загружаемого в контекст. Память накапливается, поэтому большинство систем загружает однострочный индекс, а сами записи оставляет за указателями на контекст, вместо того чтобы включать их целиком. Кроме того, память — это вторичный источник, поэтому сведения устаревают: факт, записанный в марте, с той же уверенностью загружается в июне, хотя проект уже изменился. Систему памяти нужно очищать от лишнего, как и AGENTS.md.

Пример использования:

«Мне всё время приходится напоминать ему, что у меня Postgres, а не MySQL».

«Подключи систему памяти: пусть агент записывает то, что узнаёт, в файловую систему при первом ходе, а при запуске сессии загружает это обратно. Сама модель не сохраняет состояние; непрерывность имитирует слой памяти».

Файл в среде, который harness загружает в контекстное окно в начале сессии: постоянная инструкция проекта для агента. Это общепринятое соглашение для разных harness, хотя у некоторых есть собственный вариант (например, CLAUDE.md в Claude Code).

Поскольку файл загружается автоматически, он помогает не повторять одни и те же инструкции в каждой сессии. Модель не сохраняет состояние: исправление, которое вы дали в одной сессии, в следующей забывается, и приходится каждый раз говорить новому агенту, что проект использует pnpm, что тесты запускаются с определённым флагом, а сгенерированный каталог нельзя трогать. Если вам пришлось дважды исправлять агента по одному и тому же поводу, это исправление можно добавить в AGENTS.md.

Подходящее содержимое — то, что агент не может вывести из кода: команды сборки и тестирования, неочевидные соглашения кодовой базы, жёсткие ограничения («никогда не редактируй сгенерированный клиент»). Кратко и декларативно: это инструкция, а не документация.

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

Избегайте: использовать AGENTS.md для содержимого, которое следует показывать постепенно: оно расходует токены при каждом ходе каждой сессии, даже если этой сессии оно не нужно. Руководство по стилю можно поместить в навык или указатель на контекст; в AGENTS.md оставляйте только правила, действующие повсюду.

Пример использования:

«Почему в каждой сессии уже сожжено 4k токенов?»

«Проверь AGENTS.md — кто-то вставил туда целое руководство по стилю вместо того, чтобы поместить его в навык».

Загрузка только того контекста, который нужен агенту сейчас, с указателями на контекст, ведущими к остальным материалам. Термин пришёл из дизайна интерфейсов: пользователю показывают только элементы управления, относящиеся к текущей задаче, а остальные скрывают за дополнительным действием.

Этот подход появился потому, что контекст обходится дорого сразу в двух смыслах. Каждый заранее загруженный токен оплачивается как входные токены в каждом ходе, а каждый токен расходует бюджет внимания, нужен он агенту или нет. Файл AGENTS.md, в который поместили целиком руководство по стилю, инструкцию по развёртыванию и правила работы с базой данных, мешает агенту следовать каждому из этих документов: важные для текущей задачи указания тонут среди неактуальных. Признак проблемы — агент игнорирует правила, которые, как вы знаете, входят в его контекст: они там есть, но затерялись.

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

Пример использования:

«Нужно ли целиком поместить руководство по стилю в AGENTS.md?»

«Нет — используйте постепенное раскрытие. Укажите руководство по стилю как навык, который агент загрузит, когда ему действительно понадобится написать компонент. AGENTS.md заставляет платить за токены в каждом ходе.»

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

Указатели нужны вместо включения всего содержимого в документ из-за стоимости. Указатель занимает одну строку в контекстном окне. Документ за ним может содержать тысячи токенов, но эти токены ничего не стоят, пока агент действительно не перейдёт по указателю. Включите в AGENTS.md инструкцию на 2,000 токенов — и за неё платит каждая сессия; замените её фразой «процесс выпуска: см. `internal/deploy.md`» — и документ загрузят только сессии, которым нужно выполнить развёртывание. Когда задача подходит, агент следует указателю с помощью вызова инструмента.

Чтобы указатель работал, нужны две вещи: стабильный путь и достаточное описание, по которому агент поймёт, когда стоит перейти по нему. Один только путь — указатель, за которым агенту незачем следовать; сессию, которой нужен документ, не заинтересует и фраза «см. `internal/deploy.md`» без описания содержимого. Сформулируйте строку так, чтобы она соответствовала формулировкам задач: «выпуск, развёртывание или откат — сначала прочитай `internal/deploy.md`».

Если присмотреться, указатели встречаются повсюду: в строках AGENTS.md, описаниях навыков (harness загружает описание, а текст навыка остаётся за ним), именах файлов в списках каталогов и ссылках между документами.

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

Избегайте: слова «ссылка» — оно слишком сухое и не передаёт, что переход по указателю добавляет контекст. «Портал» — слишком вычурно.

Пример использования:

«AGENTS.md становится огромным».

«Большая часть должна быть указателями на контекст, а не самим содержимым. Оставь постоянно действующие правила в файле, а инструкцию по развёртыванию и руководство по стилю преврати в навыки и оставь указатели на контекст».

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

Навыки — открытый стандарт, определённый на agentskills.io. Изначально стандарт разработала Anthropic; с тех пор его приняли многие ведущие harness, поэтому однажды написанный навык работает в разных системах. Формат представляет собой папку, содержащую:

• файл `SKILL.md` — метаданные (как минимум название и описание) и сами инструкции;
• при необходимости — скрипты, которые может запускать агент;
• при необходимости — шаблоны и справочные материалы, на которые ссылаются инструкции.

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

Этим навыки отличаются от AGENTS.md, который загружается в каждую сессию независимо от задачи. Навык читается, когда возникает определённый вид работы — выпуск релиза, создание каркаса нового сервиса, написание миграции, — и игнорируется в остальное время.

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

Пример использования:

«Куда поместить инструкцию по развёртыванию?»

«В навык: агент загрузит его, только если задача связана с развёртыванием. Если поместить инструкцию в AGENTS.md, она будет расходовать токены при каждом ходе, хотя мы используем её раз в неделю».

Агент, запущенный другим агентом через вызов инструмента. Работает в собственной сессии со своим контекстным окном и возвращает один результат инструмента. Отличается от передачи работы: родитель ожидает результат от субагента, а у передачи нет обратного пути. Не может запускать другие субагенты — дерево имеет только один уровень. Субагенты нужны, чтобы изолировать контекст, а не строить иерархии.

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

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

Пример использования:

«Результаты grep переполняют мой контекст».

«Поручи поиск субагенту: он потратит на этот шум собственное контекстное окно и сообщит только два нужных тебе пути к файлам».

Рабочая схема, при которой один или несколько людей взаимодействуют с агентом во время сессии: проверяют его работу, меняют направление или сотрудничают в реальном времени. Человек присутствует и вовлечён, а не только одобряет отдельные действия.

Ей противопоставляется работа без участия человека, когда агент работает без присмотра, а результат оценивают позже. Взаимодействие с человеком позволяет обнаружить проблемы, пока их ещё дёшево исправить: вы видите, как агент обращается не к тому файлу, неверно понимает требование или заходит в тупик, и одной фразой направляете его в другую сторону. Иначе вы можете обнаружить ошибку лишь после двадцати минут уверенной работы на неверном основании. Агенты не умеют надёжно распознавать, когда сбились с пути; оставшись без присмотра, они обычно продолжают, а не останавливаются и не задают вопрос.

Выбор схемы зависит от работы. Чётко заданные задачи с низким риском и легко проверяемым результатом подходят для автономного режима. Неоднозначные, необратимые задачи или задачи, результат которых трудно оценить, — миграция схемы, сложное проектное решение, любое действие в производственной среде — лучше выполнять с человеком в контуре. По сути, нужно оценить, насколько дорого обойдётся неверный шаг и насколько поздно вы его обнаружите.

Некоторая работа по своей природе требует участия человека, потому что его реакция и есть исходные данные. Метод сократического опроса работает, только когда вы отвечаете на вопросы; прототипирование — когда вы можете отреагировать на артефакт.

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

Пример использования:

«Запустить это автономно на ночь?»

«Нет, это миграция схемы — оставь человека в контуре. Я хочу видеть каждый шаг и направлять работу, если агент выберет не ту колонку для переноса данных».

Отсутствие у клавиатуры. Рабочая схема, при которой пользователь запускает сессию и оставляет агента работать без присмотра. Именно так AI-разработка повышает пропускную способность: множество автономных сессий может работать параллельно, пока вы спите, едите или занимаетесь чем-то ещё. Для безопасности обычно требуется разрешительный режим разрешений и изоляция в песочнице.

Когда вас нет рядом, агент иначе справляется с неоднозначностью. Пока вы наблюдаете, неясное решение проявляется в виде вопроса, и вы отвечаете; когда вы ушли, агент выбирает вариант по умолчанию и продолжает, а каждое последующее решение опирается на эту догадку. Типичная неудача — вернуться через несколько часов к завершённой, уверенно выполненной работе, построенной на неверном решении, принятом в первые десять минут. Работа не небрежная — она последовательна, но придерживается неверного направления.

Поскольку во время выполнения вы не можете давать указания, дайте их до начала и после завершения. До запуска устраните неоднозначность — проведите опрос, напишите спецификацию, — чтобы агенту пришлось самостоятельно заполнять меньше пробелов. Во время работы за то внимание, которого вы не уделяете, отвечают автоматические проверки и автоматический обзор: они быстро обнаруживают то, что можно проверить механически. По окончании должен появиться результат, который можно просмотреть, — PR, а не уже объединённые изменения. Автономный режим не отменяет проверку человеком; он откладывает её до конца, поэтому итог должен стоить проверки. Поэтому опыт агента (AX) важнее всего именно в автономных запусках: без наблюдателя среда — единственная поддержка агента.

Избегайте: «фоновый агент» — это выражение подчёркивает машину («работает в фоне»), а не схему участия человека («пользователь отошёл»). AFK называет важное обстоятельство: пользователь не наблюдает.

Пример использования:

«Оставляю это автономно на ночь: три агента в песочнице работают над рефакторингом, утром я проверю PR».

«В режиме bypass permissions?»

«Да, файловая система только для чтения и без доступа к сети».

Детерминированная проверка, выполняемая в среде: тесты, проверка типов, линтеры, сборка, pre-commit hooks. Только «пройдено» или «не пройдено», без оценок. Это сигнал, по которому агент может самостоятельно исправиться, никого не привлекая. Нестабильный тест — сломанная проверка, а не отсутствие проверки; автоматические проверки по замыслу детерминированы.

Самоисправление работает как цикл. Агент вносит изменение, запускает проверку как вызов инструмента, и результат с ошибкой попадает в его контекстное окно: ошибка типов с указанием файла и строки, неудавшееся утверждение с ожидаемым и фактическим значениями. Этого достаточно, чтобы агент исправил проблему и снова запустил проверку — снова и снова, пока она не пройдёт, без участия человека. Именно детерминированность делает цикл надёжным: один и тот же код всегда даёт один и тот же вердикт, поэтому успешная проверка что-то значит. Нестабильная проверка отравляет этот процесс: агент «исправляет» код, который был в порядке, или повторяет попытки, пока не проскочит настоящую ошибку.

Поэтому хорошие проверки составляют значительную часть опыта агента (AX) при работе с кодовой базой. Агент в репозитории со строгой типизацией, быстрым набором тестов и линтером поймает большинство собственных ошибок до того, как вы их увидите; агент в репозитории без всего этого отправит на выход всё, что произвёл. Особенно важна эта разница при автономных запусках, где проверки — единственная верификация во время работы. Но проверка находит только то, на что настроена: зелёный статус означает, что утверждаемые свойства соблюдены, а не что код верен. Пробелы, требующие оценки, предназначены для автоматического обзора и проверки человеком.

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

Пример использования:

«Агент постоянно отправляет сломанный код в автономных запусках».

«Какие автоматические проверки подключены в песочнице?»

«Только модульные тесты».

«Добавь проверку типов и линтер — он будет исправляться по их результатам ещё до появления PR».

Агент, проверяющий работу другого агента, часто с другой моделью или системной подсказкой. Результат недетерминирован: агент формирует суждение. Такой обзор можно запускать где угодно: перед слиянием PR, задним числом по истории коммитов или в середине сессии как субагента. LLM в роли судьи в CI — это автоматический обзор, а не автоматическая проверка; категорию определяет то, что именно утверждается, а не место выполнения.

Эффективность обеспечивается отделением проверяющего от работающего агента. Просьба проверить свою работу почти ничего не даёт: сессия, в которой появился дефект, содержит и рассуждения, приведшие к нему, а агент принимает собственные выводы за подтверждение. У проверяющего со свежим контекстным окном нет этой привязанности: он видит различия как посторонний наблюдатель, а это и нужно для ревью. Другая модель или системная подсказка, предназначенная именно для проверки, повышают точность ещё сильнее: у них другие слепые зоны, а подсказка сосредоточена на важных для вас вещах — безопасности, контрактах API, производительности, — а не на расплывчатом «найди проблемы».

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

Избегайте: «проверка AI» и «проверка агента» — эти выражения слишком расплывчаты и не отличают проверяющего от работающего агента.

Пример использования:

«Из автономных запусков приходит слишком много плохих PR».

«Добавь автоматический обзор перед слиянием: отдельная модель, отдельная системная подсказка, проверка только безопасности и изменений контрактов».

Пользователь читает код, созданный агентом, и формирует о нём собственное суждение. Достаточно прочитать diff или изменённые файлы; прочитать только описание работы от агента — недостаточно: рассказ не является артефактом. Описание — вторичный источник, написанный тем, чью работу проверяют; diff — первичный источник, и проверка означает чтение diff.

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

Проверять раньше также дешевле. Прочитать план до начала работы или небольшой diff в ходе работы можно за несколько минут; разбираться с завершённой веткой после запуска без присмотра дольше. Выбор момента контрольной проверки — решение о том, оставаться ли человеку в цикле, а не второстепенная мысль.

Избегайте: выражения «проверка кода» без уточнения — оно может означать как человеческую, так и автоматическую ревизию.

Пример использования:

«Я проверил результат работы агента без присмотра.»

«Ты прочитал diff или только сводку?»

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

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

Термин ввёл Andrej Karpathy, который придумал его в начале 2025 года: вы «полностью поддаётесь вайбу» и «забываете, что код вообще существует» — описываете, чего хотите, принимаете результат и оцениваете его, запуская.

Вайб-кодинг обменивает проверку на скорость. Чтение различий обычно самый медленный этап работы с агентом, поэтому отказ от него устраняет главное узкое место. Для кода, где ошибки дёшевы, — прототипов, одноразовых скриптов, внутренних инструментов, — такой обмен разумен. Риск зависит от срока службы кода и цены ошибки.

Цена проявляется позже. Изменения, сделанные вайб-кодингом, накапливаются в кодовой базе, которую никто не читал; при этом проверялось только поведение. Поэтому всё, что не проявляется при проверке поведения, — например, секрет, записанный в журнал, пропущенный пограничный случай или незаметно неверная обработка данных, — может попасть в выпуск, не будучи замеченным. Первый сеанс отладки системы становится первым случаем, когда кто-то читает код. Без проверки человеком единственными рубежами для кода остаются запущенные автоматические проверки: тесты, типы и автоматический обзор. Если ту же позицию применить ко всей кодовой базе или её части, где изменения создаёт программная фабрика, получится тёмная фабрика.

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

Пример использования:

«Ты читал, что он изменил в потоке авторизации?»

«Сделал вайб-кодингом — вход по-прежнему работает, это всё, что я проверил».

«Прочитай различия перед отправкой. Вайб-кодинг авторизации — так секреты и попадают в журналы».

Общее понимание того, что создаётся, разделяемое пользователем и агентом, но отдельное от любых артефактов. Это термин Брукса из книги The Design of Design: разговор, артефакты передачи работы и код — всё это артефакты, пытающиеся зафиксировать замысел дизайна или приблизиться к нему, но ни один из них не является самим замыслом. Качество замысла дизайна ощущается по качеству разговора, в котором он сформировался.

Термин называет причину знакомого раздражения: агент пишет в точности то, о чём вы попросили, и всё равно ошибается. Обычно причина в том, что вы сами ещё не до конца поняли, чего хотите. В вашей голове замысел дизайна ещё не сложился — промпт описал продуманные вами части и промолчал о тех, которые вы ещё не продумали. Агент заполнил эти пробелы собственными предположениями, потому что ему не с чем было сверяться. Ничего не сломалось. Общего замысла дизайна не было, потому что ещё не существовало целого замысла, которым можно было бы поделиться.

Понять, что замысел дизайна стал общим, можно так же, как и в разговоре с коллегой: собеседник начинает отвечать на ещё не заданные вами вопросы так, как ответили бы вы. До этого работа представляет собой разговор — выспрашивание является его намеренным вариантом, — а слишком раннее написание спецификации лишь закрепляет расхождение во взглядах в более долговечном артефакте. По мере обучения замысел дизайна тоже меняется; артефакты отстают от него, поэтому спецификация, верно отражавшая понимание прошлой недели, всё ещё может ввести в заблуждение сессию этой недели.

Пример использования:

«Он пишет в точности то, о чём я попросил, и всё равно ошибается.»

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

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

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

Это метод работы с участием человека: входные данные — ваши ответы. Если на вопрос нельзя ответить в разговоре — нужно увидеть сам объект, — переходите к прототипированию.

Пример использования:

«Он сразу принялся писать спецификацию и неправильно описал логику отмены».

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

Создание агентом быстрой, черновой версии чего-либо — на случай, когда разговору не хватает точности и нужен настоящий артефакт, на который можно опираться в обсуждении.

Сократический опрос помогает принимать решения о дизайне в разговоре. Обсуждение обходится дёшево, но его точность ограничена: на некоторые вопросы нельзя ответить словами — например, как ощущается взаимодействие, насколько удобно использовать форму API в реальном коде или работает ли макет с реальными объёмами данных. В ходе беседы вы доходите до вопроса и честно отвечаете: «Не знаю, нужно увидеть». Дальше обсуждение ходит по кругу. Вместо этого попросите агента создать нужную вещь, посмотрите на неё и вернитесь к разговору с ответом.

Агенты снижают стоимость создания, поэтому такой подход стал практичным. Черновой вариант, на который раньше ушёл бы день, теперь создаётся за минуты, так что его стоит делать регулярно. Это метод работы с участием человека: прототип создаётся, чтобы вы могли на него отреагировать.

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

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

Пример использования:

«Мы уже полчаса спорим, должен ли мастер быть одной страницей или состоять из трёх шагов».

«Одними словами это не решить — попроси агента сделать оба прототипа. Мы пройдём их и узнаем за пять минут».

Опыт разработчика — то, насколько кодовая база и её инструментарий помогают людям качественно работать. Хороший DX — это быстрая обратная связь, понятные сообщения об ошибках, документация, которая отвечает именно на ваш вопрос, и настройка, срабатывающая с первой попытки. Термин возник задолго до разработки с AI; в этот словарь его включили главным образом как противопоставление AX.

DX — это только взаимодействие человека с кодовой базой. Главное различие между двумя аудиториями в том, что люди сохраняют состояние, а агенты — нет. Человек изучает кодовую базу один раз и несёт эти знания с собой каждый день, поэтому с плохим DX можно жить: медленный CI обходят, группируя отправки изменений; отсутствующую документацию — однажды спросив в Slack; запутанную структуру — запомнив, где что находится. Обходные решения накапливаются, и команда в итоге продуктивно работает с кодовой базой, которая ей мешает.

Агенты сталкиваются с той же кодовой базой, но без накопленных знаний. Не сохраняя состояние между сессиями, агент каждый раз заново изучает кодовую базу. Ему помогают быстрые тесты и понятные сообщения об ошибках, но всё, что он узнал вчера, исчезает, если это не записано в среде, которую агент воспринимает только через результаты инструментов. Именно это и описывает AX: часть DX, сохраняющуюся, когда разработчик — агент, а также потребности, которых нет у людей, например необходимость оставить свободным контекстное окно.

Общие черты означают, что вложения в DX часто бесплатно улучшают AX: строгая типизация, быстрые тесты и предсказуемая структура помогают обеим аудиториям. Но различия тоже есть: прекрасная инструкция для новых сотрудников поможет человеку в течение недели, а агенту — ничем, если к ней нельзя перейти из AGENTS.md.

Пример использования:

«С нашим DX всё в порядке — новые сотрудники становятся продуктивными за неделю».

«Они продуктивны, потому что кто-то проводит с ними эту неделю. Агенту такой недели не дают; отдельно проверь AX».

Опыт агента — насколько хорошо настроена среда, чтобы агент мог качественно работать с кодовой базой. Это ориентированный на агента аналог DX. Если один и тот же агент хорошо работает в одном репозитории и плохо в другом — с той же моделью и тем же harness, — обычно дело в AX. Возникает соблазн обвинить модель или переписать подсказку, но чаще исправлять нужно репозиторий.

У хорошего AX три главных измерения:

AX и DX пересекаются: хорошие проверки и чистая архитектура помогают обеим аудиториям, — но они различаются. Люди терпимо относятся к неявным знаниям команды, медленному CI и совету «спроси Сару про модуль выставления счетов», а агентам это недоступно. Агентам не помогают подсказки IDE и красивые панели мониторинга; им нужны сообщения об ошибках в виде результатов инструментов. У кодовой базы может быть хороший DX и плохой AX.

Избегайте: считать AX синонимом DX — этим аудиториям нужны разные улучшения.

Пример использования:

«Агент пишет отличный код в репозитории API и ужасный во фронтенде».

«В репозитории API строгие типы и быстрый набор тестов, во фронтенде нет ни того, ни другого, зато есть сорок навыков, загружаемых постоянно. Это пробел в AX, а не проблема модели».

Система организации работы, в которой сессии агентов запускаются по триггерам — созданию задачи, расписанию, сбою CI или завершению другой сессии, — а не человеком. Поэтому больше работы выполняется в автономном режиме, а внимание людей направлено на оставшиеся решения с участием человека.

Без фабрики каждую сессию запускает человек. Даже полностью автономная работа ждёт, пока кто-то откроет сессию, укажет ей задачу и запустит её. Команды хотят выпускать больше, чем позволяет такой подход. Фабрика убирает человека из запуска сессий, но не обязательно из остальных этапов.

Типичные триггеры и запускаемые ими сессии:

Фабрике необязательно охватывать весь процесс разработки. Одной задачи cron, которая запускает один вид сессии и открывает один PR для проверки, уже достаточно. Начинать с малого полезно: узкий цикл выдаёт небольшие похожие PR, а их проверка показывает, насколько циклу можно доверять, прежде чем расширять его.

Люди могут участвовать на любом этапе фабрики: создавать и помечать задачи, запускающие сессии; утверждать план до начала реализации; проводить проверку человеком перед слиянием. Главный вопрос при проектировании — какие решения оставить людям. Кодовая база или её часть, где никто не проверяет результат работы фабрики, — это тёмная фабрика.

Пример использования:

«Кто исправил все нарушения `no-floating-promises`?»

«Фабрика. Задача cron каждую ночь выбирает одно правило lint и открывает PR. Я только просматриваю его утром».

Кодовая база или её часть, где программная фабрика пишет код, а люди его не читают. Проверки человеком нет. Люди всё ещё могут создавать задачи, с которых начинается работа, но никто не читает получившийся код. Название происходит от фабрик с «выключенным светом», где производство идёт без людей в цеху.

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

Проблема обнаруживается, когда что-то ломается. Вы не знаете, что изменилось, потому что никто не читал изменения. Приходится отлаживать код, который никто в команде не видел. Причина может скрываться в любом из множества изменений, и каждое из них прошло проверки.

Единственные контрольные рубежи — автоматические проверки и автоматический обзор. Если они не находят проблему, проблема попадает в код.

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

Пример использования:

«Кто изменил логику повторных попыток в сервисе выставления счетов? Никто в команде этого не помнит».

«Сервис выставления счетов — тёмная фабрика. Агенты объединяют все изменения, прошедшие CI. Это изменение никто не читал».