Почему ИИ вечно что-то забывает?

Знакомая боль

Я попросил ИИ создать сайт для бренда. В ответ получил шапку с двумя ссылками, ни одной страницы «О нас» и административную панель, к которой на сайте не было ни одной кнопки. Бэкенд на 90%, фронтенд — на 10%.

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

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

Чего не хватает? Базовой комплектности

Я начал копать, почему эти инструменты (включая мои собственные) «оставляют несколько блоков», и обнаружил, что все они проверяют одно и то же:

«Всё ли, что вы заявили, внутренне непротиворечиво?»

и никогда:

«Есть ли у этого типа объекта то, что должно быть?»

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

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

Я не одинок в этом ощущении. В статье Thomson Reuters о Claude Forge автор обронил фразу: «Прохождение тестов необходимо, но недостаточно». Он почувствовал следующий слой — но не построил его. Все сталкивались с этой болью; никто не создал базовую комплектность.

Что я сделал: ось комплектности для каждого типа результата

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

• Сайт бренда → какие разделы должны быть, доступна ли каждая поверхность, реальны ли страницы доверия.
• Чистый API → документация, коды ошибок, версионирование, лимиты запросов.
• Автоматизация → запускается ли, наблюдаема ли, оповещает ли об ошибках.

И комплектность состоит из трёх слоёв, а не просто «да/нет»: существует → доступно → наполнено. Последний чаще всего упускают: страница «О нас», где нужна фотография, не готова, пока на странице нет места для изображения и пути в бэкенде, чтобы туда его поместить, — а не просто стена текста. Веб-комплектность — лишь одна ячейка на оси — поэтому «нельзя сделать „веб-приложение“ единственным стандартом» выполняется по замыслу, а не как исключение.

Это и есть базовая комплектность.

А потом тот же закон стал проявляться снова

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

(1) Привязка к возможности, а не к идентичности.
Инструмент не спрашивает «Я — Claude?» Он спрашивает «Есть ли эта возможность?» — если есть, используем богатое взаимодействие; если нет, корректно снижаем до простого текста. Почему это важно: один и тот же код работает в Claude Code, Cursor или с обычной LLM без поломок. Определяй возможность, а не идентичность.

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

(3) Предлагать, а не продвигать автоматически.
В конце каждого этапа система проактивно предлагает следующий шаг — но решение принимает человек. Автоматизирован поток, а не суждение. Я даже отказался делать «автоисправление найденного аудитом» полностью автоматическим: сначала триаж (действительно исправить сейчас / сознательно отложено / уже верно), человек выбирает, что исправить, а для опасных операций (касающихся безопасности на уровне строк, прав доступа) система останавливается и показывает SQL перед применением.

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

Честно: насколько это ново?

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

• Уже заезжено до смерти (не моё преимущество): «инструменты слабо связаны через файлы» (десятилетия философии Unix; BMAD-METHOD и Claude Forge так и делают) и «спрашивай человека на каждом шагу» (Spec Kit, AWS Kiro, Forge; Thoughtworks уже назвал это консенсусной практикой 2025 года). Я не буду на этом акцентироваться.
• Чёткого аналога я не нашёл: три пункта выше — привязка к возможности, публичный движок/приватные настройки, базовая комплектность. Ближайший сосед, BMAD-METHOD, охватывает слабую связь и разделение ролей, но в нём нет шлюза возможностей, нет публичного/приватного внедрения, нет базовой комплектности.

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

Небольшое свидетельство: достаточно ли дешёвой модели?

Помимо дизайна, остаётся стоимость. Я провёл один контролируемый эксперимент (N=1, честно помеченный): одинаковые спецификации, одинаковые правила декомпозиции, одинаковый промпт — изменилась только модель. Sonnet против Opus, по одной декомпозиции.

• Объективно: Sonnet — 75k токенов, Opus — 86k (на 14% больше). ~80% совпадение, оба варианта валидны, оба честны.
• Качественное различие — сигнал: на механических частях Sonnet был не хуже или даже лучше (он полнее выписал таблицы примеров приёмки и явнее заметил конфликт двойной рассылки) — и дешевле. Opus оправдал свою дополнительную стоимость ровно в одном месте: он заметил скрытую предпосылку — «при переподключении, без системы учётных записей и с изменяющимся ID соединения, как сервер узнаёт, какой это игрок?» — и отказался выдумывать ложное исправление, пометив это как реальный пробел для передачи человеку. Sonnet замял это решением, которое на самом деле не решает проблему. Opus также заметил внутреннее противоречие в спецификации, которое пропустил Sonnet.

Это именно те ошибки, которые распространяются дальше и приводят к сбоям интеграции. Так что этот N=1 (я доведу до N≥3, прежде чем считать это твёрдым доказательством) говорит: дешёвая модель берёт на себя механическую массу — 80% готовности и дешевле; дорогая модель оправдывает свою стоимость только на суждениях «отказаться выдумывать, заметить противоречие», которые предотвращают распространение. Именно поэтому мой конвейер назначает модель под каждую цель и держит независимый аудит как страховочную сеть.

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

Так что это не «магический генератор приложений»

Если бы я позиционировал это как «AI-конвейер от идеи до поставки», его бы сравнивали с Devin, v0, bolt — а я не в их квадранте. Они продают магию, один клик, без рук. Я построил противоположное:

• Безопасный для замены (слабая связь — каждый инструмент полезен сам по себе, заменим при поломке)
• Сохраняющий приватность (публичный движок, приватные настройки — открытый исходный код без утечки вашего преимущества)
• Действительно полный (базовая комплектность — не «оставляет несколько блоков»)
• Человек сохраняет суждение (предлагать, а не продвигать автоматически)

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

Вместо заключения: седьмой раз — не повторение, а закон

Самое практичное, что я узнал: вы не перестаёте «оставлять несколько блоков» с помощью более сильной модели или большей магии. Вы это прекращаете, (1) дав системе базовую комплектность, которая знает, как должен выглядеть результат определённого типа, (2) встроив свои соглашения в переиспользуемые части и (3) автоматизировав поток, но никогда — суждение.

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