Ошибки предшественника: 6 багов за одну сессию и как фабрика учится

AI-агент не глупый. Он прочитал 60 строк из 207, решил, что понял суть, и приступил к работе. Через 4 часа — 6 продакшен-деплоев без бэкапов, удалённые Docker-образы и $50, потраченных на исправление ошибок, которых не должно было быть.

Это не история про плохую модель. Это история про отсутствие процесса. И про то, как одна провальная сессия создала 6 правил, которые теперь защищают каждую следующую.

Анатомия провала: 3 апреля 2026

Задача была простая: развернуть новую версию Knowledge Graph v2 — 4-слойный темпоральный граф знаний с 415 нодами и 230 связями. Предшественник (предыдущая AI-сессия) оставил подробную документацию: research.md на 207 строк, правила деплоя, план масштабирования из 6 стадий.

CEO-агент запустил процедуру S1 (стартовый чек-лист: загрузка контекста, чтение правил, проверка состояния проекта). Вернее, он думал, что запустил.

Ошибка 1: Частичное чтение документов

Агент прочитал research.md с параметром limit: 60 — первые 60 строк из 207. Сэкономил контекст. Пропустил секцию 4 “Risk Assessment”, где чёрным по белому стояло: Groq rate limits на массовую экстракцию — вероятность HIGH. Пропустил секцию 5 “Scale Roadmap” с 6 стадиями (S0-S5).

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

Правило, которое родилось: “Read ALL documents COMPLETELY before any action. Never set limit: 30. If file exceeds 10K tokens, read in 2-3 chunks covering the ENTIRE file. ‘I’ll read the rest later’ = you won’t.”

Ошибка 2: Пропущенный S1 чек-лист

S1 — это 9 шагов загрузки контекста при старте сессии. DNA проекта, правила, knowledge base, session digest предшественника. Агент формально запустил S1, но не дочитал правила деплоя. Не проверил, что staging-сервер должен тестироваться первым. Не загрузил контекст предыдущих инцидентов.

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

Правило: Каждый пункт S1 чек-листа должен быть выполнен полностью. Частичное выполнение = невыполнение.

Ошибка 3: Деплой без бэкапов

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

Шесть деплоев. Ни одного бэкапа. Каждый следующий деплой затирал предыдущий образ. Откатываться стало некуда.

Правило: “After deploy failure: investigate root cause, fix script, redeploy.” Но сначала — бэкап. Всегда.

Ошибка 4: Потерянный volume mount

При одном из “быстрых фиксов” агент пересоздал Docker-контейнер без volume mount для базы данных. SQLite хранилась внутри контейнера. Пересоздание контейнера = потеря данных.

Агент не знал про volume mount, потому что не прочитал конфигурацию docker-compose полностью. Всё та же корневая причина: частичное чтение.

Правило: “Working infra exists — copy params, change only what’s needed.” Не переписывай docker-compose с нуля. Скопируй рабочий, измени только то, что нужно.

Ошибка 5: Удалённые Docker-образы

Когда образов в реестре стало слишком много (6 деплоев создали 6 образов), агент решил “навести порядок” — удалил все образы, не проанализировав, какие из них рабочие. Включая единственный стабильный образ предыдущей версии.

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

Правило: “Before ANY cleanup — inventory what exists and what is safe to remove. Never batch-delete without analysis.”

Ошибка 6: Каскадные фиксы

Каждая ошибка порождала “быстрый фикс”. Каждый фикс вносил новую проблему. Вместо 2-3 чистых коммитов получилось 9 коммитов, из которых 6 — исправления предыдущих исправлений.

Коммит 1: деплой. Коммит 2: фикс volume mount. Коммит 3: фикс миграции, сломанной коммитом 2. Коммит 4: фикс конфига, забытого в коммите 3. И так далее. Снежный ком.

Правило: “Diagnose root cause BEFORE planning any fix. Never plan a rebuild until you’ve verified the existing artifacts are actually broken.”

Цена экономии контекста: $50

147 непрочитанных строк одного документа привели к:

• 6 продакшен-деплоев без staging-тестирования
• Удалённым бэкап-образам
• Потерянному volume mount
• 9 коммитам вместо 3
• ~$50 на Opus-токены для каскадных исправлений
• 4+ часа потерянного времени

Контекстное окно — не дефицит. 207 строк = ~300 токенов. Это 0.03% от миллионного контекста. Агент “сэкономил” 0.03% и потратил 25x больше на исправления.

Как фабрика учится

В Factory OS нет fine-tuning. Нет обучения модели на ошибках. Вместо этого — явные правила в файлах, которые каждый агент обязан прочитать при старте.

Механика простая:

1. Инцидент происходит. Агент допускает ошибку.
2. Post-mortem. Анализ корневой причины: не “что сломалось”, а “почему агент принял это решение”.
3. Правило формализуется. Файл feedback_*.md с тремя секциями: что случилось, почему, как применять.
4. Правило загружается. Каждый новый агент при старте читает все feedback-файлы. Правило становится частью его инструкций.

Это не machine learning. Это institutional learning. Организация запоминает ошибки, даже когда конкретный агент (сессия) прекращает существование.

После сессии 6 апреля родились не просто 6 правил. Родился паттерн: AI-сессии требуют структурированной передачи дел. Как вахтовый метод на заводе: сменщик не просто приходит — он читает журнал предыдущей смены, проверяет состояние оборудования, принимает смену по чек-листу.

Паттерн “Предшественник”

Каждая AI-сессия теперь оставляет session digest: что сделано, что не доделано, какие решения приняты, какие грабли обнаружены. Следующая сессия начинает с чтения этого дайджеста — полностью, без limit: 60.

До паттерна	После паттерна
Агент начинает с нуля	Агент читает дайджест предшественника
Ошибки повторяются	Ошибки формализованы в правила
Деплой напрямую	Staging → бэкап → деплой
”Быстрый фикс”	Диагностика → план → фикс
9 коммитов	2-3 чистых коммита

Число feedback-правил в моей Factory OS сейчас перевалило за 40. Каждое — это конкретный инцидент, конкретная цена ошибки, конкретный механизм предотвращения.

Вывод

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

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

Фабрика не прощает, но запоминает. И это ровно то, что делает AI-разработку управляемой.

---

Хотите узнать больше о Factory OS — nevr@aicpo.com или nevrai.com