AI Native без шаманства: как строить ИИ-системы, которые реально работают — видео

Недавно мы с Григорием Добряковым провели стрим, где полтора часа разбирали подход, который я называю AI Native. Григорий — технический менеджер, CTO и архитектор с серьёзным enterprise-бэкграундом: высоконагруженные и распределённые системы, SDLC, управление разработкой и командами. У него есть рабочие AI-контуры для маркетинга, анализа людей и компаний, текстовых пайплайнов, постановки и приёмки задач — то есть не теория, а работающие системы в продакшене.

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

Также доступно на VK Video.

Хватит шаманить — ИИ это инженерия

Самая частая ошибка, которую я вижу: люди пробуют бесплатную модель, получают слабый результат и делают вывод — «ИИ не работает». Это примерно как оценивать автомобильную индустрию по опыту вождения «Оки».

Сильные модели стоят денег. И дают принципиально другое качество. Разница между GPT-5.5 и бесплатной версией Deepseek — как между калькулятором и Excel. Формально оба считают, но масштаб задач несопоставим.

ИИ работает, когда вы относитесь к нему как к инженерному инструменту: задаёте цели, готовите данные, выстраиваете процессы. Без этого любая модель остаётся дорогим генератором текста.

Агенты — это сотрудники. Управляйте ими так же

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

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

Один из самых мощных паттернов, о котором мы говорили — «генератор–ревьюер». Первый агент создаёт, второй проверяет по заданным политикам. Обратная связь возвращается в цикл. Это снижает ошибки и утечки на порядок.

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

Ядро системы — база знаний

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

База должна быть машиночитаемой, актуальной и с процессами обновления. Notion, Obsidian, граф знаний с двунаправленными ссылками — конкретный инструмент вторичен. Первичен принцип: у агентов должен быть единый источник правды о вашем бизнесе, процессах и продуктах.

Отдельный приём, который даёт мощный эффект: «подсунуть книгу ИИ». Берёте авторитетный источник — Таненбаума, Фаулера, Котлера — нарезаете на главы, индексируете, подключаете к агенту. Модель начинает рассуждать в логике автора книги. Галлюцинации падают в сто раз, потому что вместо догадок появляются факты.

Как это выглядит на практике: агент извлекает понятия из каждой главы, создаёт 100–150 статей с двунаправленными ссылками, собирает индекс. После этого вы можете искать «по автору», а модель отвечает так, будто сама написала эту книгу.

Агент проектирует — пайплайн исполняет

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

Решение: гибридная архитектура. Агент проектирует пайплайн, документирует его и передаёт оркестратору — n8n, Temporal, любой детерминированный движок. Дальше оркестратор исполняет: каждый узел, каждый контракт, каждый результат можно наблюдать и контролировать.

Эффект — экономия токенов в 10–100 раз. Агент думает один раз, а результат его работы переиспользуется тысячи раз без повторных вызовов модели. На практике один пайплайн комфортно работает с десятками узлов — этого хватает для большинства рабочих сценариев.

Цели вместо инструкций

Микроменеджмент убивает и людей, и агентов. Когда вы описываете каждый шаг, вы ограничиваете систему своим пониманием задачи. Когда формулируете результат и метрики — агент сам находит оптимальный путь.

Конкретный пример: для своего сайта я задал две цели — «контент из Notion» и «максимальная скорость загрузки». Агент сам выбрал Astro как фреймворк. Я не навязывал стек — описал, чего хочу.

Структурированные схемы — JSON, TOML, YAML — помогают не потому, что «модели нравится JSON». Они дисциплинируют вас на этапе постановки задачи. Чем точнее сформулирован вход, тем качественнее выход.

Безопасность: RBAC для агентов

Если агенты работают с данными компании, им нужна ровно такая же модель доступов, как людям. Классический RBAC — разделение ролей, аудит прав, менеджер секретов. По сути ничего нового, просто новый класс «сотрудников».

Для чувствительных данных и 152-ФЗ есть два пути: полностью локальная инфраструктура (дорого и сложно) или маскировка данных перед отправкой в облако (с риском потери контекста). Серебряной пули пока нет, но осознанный выбор лучше иллюзии безопасности.

Так с чего начать

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

А дальше — управляйте агентами как командой, стройте гибридные пайплайны и описывайте цели вместо инструкций.

Полная запись стрима — в видео в начале статьи. Там полтора часа с деталями, примерами и живыми вопросами из зала.

По теме

• Статья: Карпатый объяснил, почему вайб-кодинг и агентный инжиниринг — два разных мира
• Блог: Парень из Китая собрал семь агентов на Claude Code и в одиночку обслуживает 47 малых бизнесов
• База знаний: n8n — визуальная автоматизация с нативной поддержкой ИИ-агентов

Если вы строите ИИ-систему для бизнеса и хотите разобраться, какой подход подойдёт вашей команде, — пишите в Telegram @pimenov