AI-native разработка: не 'используй ChatGPT', а архитектура

“Мы используем AI в разработке” — говорит каждая вторая компания в 2026 году. Обычно это значит: разработчик копирует код из ChatGPT и дописывает руками. Copilot подсказывает автокомплит. Иногда — генерация тестов.

Это “AI-assisted”. Полезно, но не трансформационно.

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

Два подхода: сравнение

	AI-assisted	AI-native
Кто пишет код	Человек с подсказками AI	AI-агент автономно
Кто проверяет	Тот же человек	Отдельный AI-агент (Quality)
Контекст	В голове разработчика	В файлах (DNA, rules, memory)
Масштаб	1 задача за раз	Pipeline: task → build → test → review → deploy
Обучение	Человек учится	Система учится (rules из ошибок)
Bottleneck	Скорость человека	Скорость утверждения результата

В AI-assisted bottleneck — разработчик. Он пишет, AI подсказывает, но скорость ограничена скоростью набора текста и осмысления.

В AI-native bottleneck — утверждение. AI написал, протестировал, прошёл ревью. Человек смотрит diff, утверждает коммит. 2 минуты вместо 2 часов.

Анатомия AI-native сессии

Реальный пример: добавление Knowledge Graph в AICPO. Задача: новые таблицы в БД, сервис экстракции, API, интеграция с чатом, визуализация.

В AI-assisted подходе это 2-3 спринта работы. В AI-native:

Фаза 1: Проектирование (CEO-агент, 5 мин)

Декомпозиция на 7 подзадач
Определение файлов, моделей, миграций
Task table с acceptance criteria

Фаза 2: Миграции и модели (Builder, 15 мин)

7 таблиц, модели, валидации, индексы
Тесты проходят

Фаза 3: Сервис экстракции (Builder, 20 мин)

LLM-промпт для извлечения узлов из фактов
Дедупликация, confidence scoring
Интеграционные тесты

Фаза 4: API (Builder, 10 мин)

8 эндпоинтов: graph, nodes, subgraph, evidence, summary, gaps, export, health
Авторизация, пагинация

Фаза 5: Интеграция с pipeline (Builder, 10 мин)

ScoreCalculatorJob → KgBuilderJob после каждого факта
ActionCable broadcast

Фаза 6: Quality review (Quality-агент, 15 мин)

Независимая проверка всего кода
Нашёл 2 issue → Builder пофиксил

Фаза 7: Deploy (DevOps, 5 мин)

Миграции, рестарт, health check
Post-deploy verification

Итого: 1.5 часа. 8500 строк. 0 ручного кода.

Для сравнения: подобный scope в корпоративной команде — 2-3 недели с учётом планирования, код-ревью, стендапов и ожидания деплоя.

Почему это не “сгенерируй и молись”

Критики скажут: “8500 строк от AI — это 8500 строк потенциальных багов”. Верно, если нет системы контроля. Неверно, если есть.

Factory OS контролирует качество на 5 уровнях:

Rules — агент читает правила перед каждой задачей. “Не используй SQLite-specific SQL” — потому что в проде PostgreSQL, и мы уже 5 раз ловили 500-ки из-за этого.
Smoke tests — обязательный запуск перед каждым коммитом. Не проходят — не коммитишь.
Quality gate — независимый агент проверяет код, не зная что Builder написал в self-review.
Post-deploy verification — 33 автоматических проверки после каждого деплоя.
Incident → Rule loop — каждый баг, дошедший до продакшена, превращается в правило. Баг → урок → правило → валидатор → баг больше не повторяется.

Что это значит для организаций

AI-native разработка — не про замену разработчиков. Про изменение того, что делают разработчики.

Сейчас: разработчик пишет код 60% времени, 40% — митинги, ревью, документация.

AI-native: разработчик проектирует архитектуру, определяет правила, утверждает результат. AI пишет, тестирует, деплоит. Разработчик делает то, что AI не может — принимает решения о продукте.

Это не автоматизация отдельных задач. Это переход от “команда пишет код” к “команда управляет AI, который пишет код”.

Переход требует:

Архитектуры агентов — кто что делает, какие ограничения
Системы правил — жёсткие, версионируемые, из реальных инцидентов
Quality gates — независимая проверка, не self-review
Memory — как агенты помнят контекст между сессиями

Это методология. И я готов помочь внедрить её в вашей команде.