Что делать, если ИИ тупит, раздувает код и всё забывает — а промпты уже не помогают

Есть момент, через который я сам прошёл на больших проектах с ИИ.

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

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

Первая реакция — написать промпт подробнее. Потом ещё подробнее. А потом у тебя уже не промпт, а Конституция Российской Федерации для робота — и он всё равно иногда делает не то.

Вот здесь я понял неприятную вещь: часто проблема уже не в промпте.

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

Большой контекст — это ещё не память

Размер контекстного окна легко принять за объём памяти. Но «текст поместился» и «модель надёжно использовала каждую важную деталь» — не одно и то же.

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

Поэтому я перестал давать ИИ весь проект «на всякий случай». Для конкретной задачи ему нужен минимально достаточный контекст.

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

Ещё больше правил тоже может сделать хуже

Второй рефлекс — дописывать инструкции: не переписывай код; сначала изучи архитектуру; всегда прочитай восемь документов; не делай лишнего; перед каждым изменением проведи аудит всего проекта.

Через несколько месяцев получается огромный файл инструкций или файл инструкций Claude.

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

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

Правило, которое у меня реально сработало

Вместо очередного мегапромпта я ввёл простую последовательность:

ИСТОЧНИК → ФАКТ → РАЗНИЦА → ДЕЙСТВИЕ → ПРОВЕРКА → СТОП.

1. Сначала открой реальный код, конфиг, лог или документ.
2. Установи, что происходит сейчас.
3. Найди конкретную разницу между «должно быть» и «есть».
4. Исправь минимально.
5. Проверь результат.
6. Если работает — остановись.

Последний пункт оказался неожиданно важным.

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

Один дефект — один фикс

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

Мой порядок сейчас такой:

переиспользовать → исправить → небольшое изменение → новая сущность.

Новая сущность — последний вариант.

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

«Проверь сам себя» — слабая проверка

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

Проблема в том, что она уже находится внутри собственной логики решения.

Мне гораздо полезнее другой принцип:

автор делает → проверка доказывает → независимый проверяющий смотрит конкретный изменение.

В SWE-bench решение ИИ-агента оценивают не по красоте объяснения: сгенерированный патч применяют к реальному репозиторию и запускают тесты.

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

Проверяемое доказательство выше мнения ИИ.

Не храните проект в переписке

Ещё одна причина, почему ИИ «забывает»: мы пытаемся хранить состояние проекта в чате.

Почему выбрали эту архитектуру? Какая версия сейчас актуальна? Что уже проверили? Где результат? Почему прошлый вариант отклонили?

Если ответы существуют только в старой переписке, проект фактически не имеет нормального состояния.

Чат должен быть интерфейсом. А состояние должно жить отдельно: задачи, статусы, файлы, результаты тестов, решения, история ошибок.

Именно из этой проблемы у меня в итоге выросла ИИ-Станция.

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

Тогда уже нужны мини-ТЗ, этапы, статусы, файлы, память проекта, повтор и история результата. В текущей архитектуре ИИ-Станции рабочее окно принимает задачу, Hatchet ведёт выполнение, PostgreSQL хранит состояние, Qdrant — смысловую память, MinIO — файлы, Directus показывает задачи, статусы и артефакты. Это уже инфраструктура вокруг модели, а не ещё один промпт.

И не надо сразу строить армию агентов

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

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

Моё правило:

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

Иначе вместо «ИИ забыл контекст» получаем «пять ИИ помнят пять разных версий проекта».

Три разных вида памяти

Я долго называл всё словом «память», и это тоже путало.

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

Состояние проекта — что уже произошло: этапы, версии, файлы, тесты, ошибки.

Долгая память — почему приняли решение, какие ошибки уже повторялись, какие ограничения нельзя снова нарушать.

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

Мой чек-лист, когда кажется, что ИИ опять «отупел»

Я больше не начинаю с переписывания промпта. Сначала отвечаю на семь вопросов.

1. Задача определена? Не «улучши систему», а какой конкретный наблюдаемый результат должен измениться?

2. ИИ вообще видел источник? Код, логи, данные, текущий документ — или рассуждает по пересказу?

3. Контекста не слишком много? Нет ли старых инструкций, лишних документов и конфликтующих правил?

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

5. Есть источник истины? Где хранится текущее состояние проекта, кроме переписки?

6. Есть доказательство результата? Тест, сборка, лог, повторное чтение, снимок экрана, метрика — что именно означает ГОТОВО?

7. Есть стоп-условие? Когда ИИ обязан прекратить «улучшать» уже рабочее решение?

Если здесь есть дыра, сначала чиню её. И только потом промпт.

Минимальный протокол на неделю

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

Для каждой задачи фиксируйте пять вещей:

Задача. Один измеримый результат.

Источник. Что ИИ должен проверить перед изменением.

Граница. Что нельзя трогать.

Проверка. Чем доказать, что результат работает.

ГОТОВО. После какого результата работа прекращается.

Например:

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

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

Вывод

Когда ИИ начинает тупить, первое желание — найти модель умнее или написать промпт длиннее. Иногда это действительно помогает.

Но если проблема повторяется из задачи в задачу, я смотрю уровнем выше.

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

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

Если хотите посмотреть именно эту механику на своей задаче, демо занимает 20–25 минут. До звонка и демонстрации — 0 ₽.

@stasnesupurgu