В прошлой публикации я кратко описал своё представление о наиболее важных ограничениях Моделей (LLM):

работа только с текстом: вход и выход - текстовые файлы;
ограниченность контекстного окна;
все входные данные и все результаты одного диалога размещаются в рамках одного контекстного окна;
расширяющийся контекст (вход меньше выхода) - признак "творческой" работы Модели, сужающийся - признак "инженерной" работы (повторяемой);
противоречивые (или просто лишние) данные приводят к размыванию контекста и снижению повторяемости;

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

Снимаем маску

Сейчас код для приложений могут писать Агенты (Cursor, Cline, Copilot, Claude, Codex), но у каждого Агента "под капотом" расположена та или иная Модель. По сути дела, Агент - это инфраструктура, позволяющая Модели работать с кодом приложения вместо Человека. Набор артефактов и правил для чтения файлов проекта, их изменения и тестирования. Зачастую, при запуске Агента можно выбрать желаемую Модель из нескольких доступных.

Вайб-кодинг - это запуск Модели в режиме "творчества". Когда при минимальном входном контексте Модель создаёт код, руководствуясь "собственным чувством прекрасного" (статистическими вероятностями возможных направлений и генератором случайных чисел - ГСЧ).

Декомпозиция

Ограниченность контекстного окна (любой) Модели приводит к тому, что за один раз можно проанализировать и изменить довольно маленький проект - не больше выходного контекста соответствующей Модели. Без сомнений, можно создать за один запрос приложение типа "Hello, world!" или "To-Do List" но предполагать, что подобная стратегия будет масштабироваться на приложения размера хотя бы мессенджера - выдающаяся наивность.

Понятно, что если совокупный размер кода превышает размер выходного контекста (а это 2К - 4К - 8К - 64К - 128К токенов, в зависимости от модели), то за одну итерацию невозможно сгенерировать (или изменить) код такого проекта. То есть, весь код проекта нужно разбивать на отдельные файлы, где максимальный размер одного файла не превышает размеров выходного контекста.

Размер выходного контекста

Месяца 3-4 назад я проводил эксперимент, какой размер выходного контекста у Модели может считаться достоверным. Понятно, что каждый разработчик Модели громко заявляет о максимально возможных размерах, но какой размер является максимальным с практической точки зрения?

Для выяснения этого размера я взял начало романа "Анна Каренина" и попросил Модель заменить имя героя романа Степана Аркадьевича на другое (например - Павла Петровича). Особенность моделей в том, что размеры их контекстного окна позволяют разместить входные данные, по размеру гораздо бОльшие, чем получающийся результат. По результату с правильными заменами можно примерно оценить практический потолок для выходного контекста. На текущий момент я бы не делал файлы размером больше, чем 4К токенов (10-15К символов), а по возможности придерживался бы половины от этого значения.

Скрытый текст

Если взять фрагмент размером 67К токенов (это примерно 29 глав романа "Анна Каренина") и попросить любую модель произвести замену "Степан Аркадьевич" на "Павел Петрович" с учётом падежей, то результирующий текст с правильными заменами и будет представлять собой практический предел возможностей данной модели.

На момент написания статьи GPT-5 через веб-интерфейс даёт максимальный выходной результат примерно в 4К токенов (12.5К кириллических символов), а веб-интерфейс для Gemini 2.5 Pro - 12К токенов (37К кириллических символов). При этом модели ведут себя по-разному: GPT-5 просто дополняет результат необработанным текстом после 4К (без замены Степана на Павла), а Gemini перестаёт выдавать результат в браузер и рапортует о потере подключения к интернету, стирая при этом уже полученный результат.

Производители этих моделей заявляют о теоретических пределах в 128К токенов для GPT-5 и 64К токенов для Gemini 2.5 Pro, но через веб-интерфейс такие пределы на практике недостижимы.

Итеративность

Если исходный код проекта разбивать на отдельные файлы (размером около 10 кбайт), то, теоретически, Модель может сгенерировать любой файл этого проекта, а значит, также теоретически, Модель может шаг за шагом сгенерировать и весь проект.

Для этого нужно, чтобы для каждого результирующего файла с исходным кодом был сформирован входной контекст, позволяющий (повторяемо!) получать исходный код файла на разных Моделях. В своей прошлой публикации я назвал это "сужением контекста" - когда входной контекст в разы больше результата, но при этом убирает из процесса генерации текста "творческую составляющую" Модели (ГСЧ).

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

Иерархия

Каким образом можно обеспечить сходимость (сужение) контекста - повторяемость результата генерации отдельного исходного файла? Ответ уже есть в практике создания ПО обычным способом - документация и соглашения. Любому проекту сопутствует огромное количество информации, составляющей когнитивный контекст для участников разработки. Любой сеньор отличается от любого джуна объёмом такой информации уже освоенной им в некоторой предметной области. Это называется опыт.

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

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

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

Заключение

В данной публикации я хотел осветить два момента, которые я считаю базовыми в контексте ADSM (Agent Driven Software Management):

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

У меня вот такой вот опыт и такие выводы в области взаимодействия Человека и Модели с целью создания программ. Если кому-то они покажутся сомнительными - с интересом ознакомлюсь с рациональной критикой.

ADSM: итеративность и иерархия