Factory OS: не фреймворк, а архитектура AI-native разработки
Каждый, кто пробовал писать код с ChatGPT, знает: AI генерирует работающий код примерно в 70% случаев. Оставшиеся 30% — баги, галлюцинации, потерянный контекст. Масштабировать это невозможно.
Factory OS — это набор правил, ролей и процессов, который превращает AI-агентов в надёжную инженерную команду. Не фреймворк (нечего устанавливать), а методология, которая работает поверх Claude Code.
Почему одного AI-агента недостаточно
Один агент = один контекст = одна точка отказа. Он пишет код, он же его проверяет, он же решает что деплоить. Это как если бы один человек был и разработчиком, и тестировщиком, и техлидом.
Результат предсказуем: агент объявляет “Done”, а на продакшене 500-я ошибка. Он сам не видит свои ошибки — как и человек, который проверяет свой же код.
15 ролей: разделение ответственности
Factory OS решает это через специализацию. Каждая роль — это промпт-файл с чётким описанием:
- Что роль может делать
- Что не может (жёсткий запрет)
- Чек-лист качества
- Какая модель используется
| Роль | Может | Не может |
|---|---|---|
| CEO | Читать код, делегировать, принимать решения | Писать/редактировать код |
| Builder | Писать код, запускать тесты | Деплоить, менять архитектуру |
| Quality | Ревьюить код, находить баги | Фиксить баги (только репортить) |
| DevOps | Деплоить, настраивать инфру | Менять бизнес-логику |
CEO-агент — оркестратор. Он получает задачу, декомпозирует, порождает нужного агента, проверяет результат. Он никогда не пишет код сам. Это ключевое правило, нарушение которого приводило к хаосу в первых версиях системы.
40+ правил: почему жёсткость важнее интеллекта
AI-агенты умные. Слишком умные. Они “оптимизируют” процессы: пропускают тесты (“и так работает”), деплоят без ревью (“мелкое изменение”), удаляют “ненужный” код.
Каждое правило в Factory OS — это урок из конкретного инцидента:
P1: CEO никогда не пишет код. Появилось после того, как CEO-агент “быстренько поправил” HTML и сломал весь фронтенд. Три раза.
Q1: Тесты перед каждым коммитом. Появилось после деплоя, который прошёл code review, но ронял сервер при старте — тесты не запускались.
S1: Полная перезагрузка контекста при старте сессии. Появилось после того, как агент “забыл” архитектурное решение из прошлой сессии и переписал модуль с нуля.
Правила хранятся в файлах и читаются каждым агентом при запуске. Система учится на ошибках — не через fine-tuning, а через явные правила. Каждый баг = новое правило = баг больше не повторяется.
Quality Gate: независимая проверка
Самый критичный элемент. Quality-агент запускается отдельно от Builder-агента. Он не видит, что Builder написал в self-review. Он проверяет с нуля.
Почему это важно: Builder-агент склонен оправдывать свои решения. “Я проверил — всё работает”. Quality-агент не знает, что Builder “проверил” — он проверяет сам.
Если Quality находит проблему — Builder получает вердикт и фиксит. Максимум 3 попытки. Если после 3 попыток баг остаётся — эскалация: архитектура неправильная, нужно менять подход, а не код.
Память: как агенты помнят между сессиями
Контекстное окно Claude — 200K токенов. Звучит много, но один Rails-проект — миллионы строк. Через 2 часа работы агент начинает терять начало разговора.
Factory OS решает это через файловую память:
- DNA проекта — архитектура, зависимости, горячие точки
- Rules — жёсткие правила поведения
- Knowledge — уроки из прошлых проектов
- Session digest — сжатое резюме каждой сессии
При старте каждый агент читает всё. Это ~2000 строк — 0.3% от контекстного окна. Зато агент знает: какие решения были приняты, какие ошибки были допущены, какие файлы трогать нельзя.
Результаты в цифрах
За месяц работы с Factory OS:
| Метрика | Значение |
|---|---|
| Продуктов в продакшене | 39 |
| Коммитов | 500+ |
| Средний build time (фича) | 2-8 часов |
| Время от задачи до деплоя | 15 минут (типичная) |
| Critical bugs в продакшене | 0 |
| Правил в системе | 40+ |
| Ролей | 15 |
Это не потому что AI безошибочен. Это потому что ошибки ловятся до коммита — правилами, тестами и независимым ревью.
Применимость за пределами solo-разработки
Factory OS создавался для одного человека. Но принципы масштабируются:
Для корпоративных команд: разделение ролей между AI-агентами дополняет человеческую команду. Builder-агент делает рутину, Quality проверяет, человек принимает архитектурные решения.
Для AI-продуктов: методология “правила важнее интеллекта” применима к любому LLM-продукту. Хотите надёжный AI? Не делайте модель умнее — сделайте правила жёстче.
Для трансформации: переход от “используем ChatGPT” к “проектируем для AI” — это архитектурный сдвиг, который требует методологии. Factory OS — один из возможных ответов.
Для обсуждения — nevr@aicpo.com | Telegram @nevrdigital