Я не верю в универсальный стек для AI-разработки. В 2026 году инструменты меняются слишком быстро, а задачи клиентов слишком разные: одному нужен ассистент в WhatsApp, другому внутренний аналитик для собственника, третьему RAG по технической документации. Поэтому мой стек — это не список модных названий, а набор решений, которые я могу быстро собрать, проверить на данных клиента и спокойно поддерживать после запуска.
Главный принцип простой: модель не должна жить отдельно от бизнес-процесса. AI-проект становится полезным только тогда, когда он подключен к CRM, базе знаний, заявкам, платежам, статусам заказов и метрикам. Иначе это демо, которое красиво отвечает в чате, но не меняет экономику бизнеса.
LLM: GPT-4o как рабочая модель по умолчанию
Для большинства коммерческих задач я начинаю с GPT-4o. Мне важны три вещи: качество понимания русского языка, стабильность в многошаговом диалоге и нормальная работа с инструментами. В проектах поддержки и продаж модель должна не просто красиво писать, а правильно определить намерение, вытащить сущности, не потерять контекст и вызвать нужное действие.
При этом я не привязываю архитектуру к одной модели. В хорошей системе LLM — заменяемый слой. Сегодня это GPT-4o, завтра часть задач может уйти на более дешевую модель, отдельный классификатор или локальный inference. Поэтому я почти всегда закладываю адаптер: единый формат запроса, единый формат ответа, логирование токенов, стоимости и ошибок.
Отдельно тестирую режимы отказа. Если модель не уверена, она должна задавать вопрос, а не фантазировать. Если клиент просит то, чего нет в базе знаний, агент должен честно сказать, что уточнит у менеджера. Это скучно, но именно скучные ограничения делают AI-проект пригодным для бизнеса.
Оркестрация: n8n, LangChain и CrewAI
n8n — мой основной инструмент для быстрой бизнес-оркестрации. Через него удобно связывать Telegram, WhatsApp, CRM, таблицы, почту, вебхуки, базы данных и внешние API. Для клиента это часто самый понятный вариант: сценарии можно увидеть, изменить и поддерживать без полноценной разработки каждого шага с нуля.
LangChain я использую там, где нужны цепочки с RAG, инструментами, памятью и более явным контролем над промптами. Он полезен не как магическая библиотека, а как набор строительных блоков: retriever, parser, tool calling, evaluators. Но если задача простая, я не тащу LangChain только ради названия. Иногда один аккуратный backend endpoint надежнее десяти абстракций.
CrewAI подходит для задач, где есть несколько ролей: исследователь, аналитик, редактор, проверяющий. Например, контент-пайплайн или подготовка отчета по рынку. Но я осторожно отношусь к «командам агентов» в продакшене. Чем больше автономности, тем больше нужно логирования, ограничений и тестов. Для клиента важен результат, а не театр из пяти виртуальных сотрудников.
Базы данных: Supabase, Qdrant и PostgreSQL
Supabase стал для меня быстрым способом запустить продуктовую часть: auth, PostgreSQL, storage, edge functions, роли доступа. Для дашбордов, личных кабинетов и внутренних AI-инструментов это хороший баланс скорости и контроля. Можно быстро показать первую версию, а потом постепенно укреплять архитектуру.
PostgreSQL остается базой, к которой я возвращаюсь почти всегда. Сделки, пользователи, события, статусы, настройки, аудит действий — все это должно лежать в нормальной реляционной структуре. AI не отменяет дисциплину данных. Наоборот, чем больше автоматизации, тем важнее понимать, что именно произошло и почему.
Qdrant использую для векторного поиска, когда агенту нужно работать с документами, FAQ, регламентами, инструкциями или каталогами. Мне нравится, что его можно поднять отдельно, контролировать коллекции, метаданные и фильтры. В RAG-проектах качество retrieval часто важнее, чем выбор самой LLM. Если модель получила не тот контекст, она ответит уверенно, но бесполезно.
Фронтенд: Next.js, Tailwind и интерфейсы для решений
Для клиентских интерфейсов я чаще всего выбираю Next.js. Он хорошо подходит и для маркетинговых страниц, и для внутренних панелей, и для дашбордов. В AI-проектах фронтенд важнее, чем кажется: пользователю нужно видеть не только ответ модели, но и статус задачи, источник данных, историю действий, возможность поправить результат и передать кейс человеку.
Tailwind использую из-за скорости и предсказуемости. Я могу быстро собрать аккуратный интерфейс без тяжелой дизайн-системы, а потом привести его к нужному уровню. Для графиков беру Recharts, когда нужен понятный управленческий дашборд без лишней сложности. Если проект вырастает до серьезной аналитики, тогда уже обсуждаю BI-слой отдельно.
В AI-интерфейсах я стараюсь избегать «магии без объяснений». Хороший экран показывает, что агент сделал, на каких данных основывался, что требует подтверждения и где есть риск ошибки. Это снижает тревогу у команды и помогает внедрению пройти без саботажа.
Деплой: простота, наблюдаемость и возможность отката
Для статических и фронтенд-проектов подходит Vercel, но серверную часть я часто выношу туда, где проще контролировать окружение: VPS, Docker, отдельные воркеры, managed PostgreSQL. Важнее не бренд хостинга, а понятная схема: где крутится приложение, где лежат секреты, кто отвечает за бэкапы, как обновляться и как откатываться.
Минимальный продакшен-набор для меня — это логирование входов и выходов, мониторинг ошибок, лимиты на стоимость, алерты по падениям интеграций и отдельный журнал действий агента. Если AI-агент создал сделку, отправил письмо или изменил статус заказа, это должно быть видно. Без журнала невозможно разбирать спорные ситуации.
CI/CD стараюсь держать простым. GitHub Actions, Docker, переменные окружения, тестовый контур и ручное подтверждение для опасных операций. В AI-проектах автоматический деплой без проверки промптов и интеграций может сломать бизнес-процесс за одну минуту.
Что я не добавляю без необходимости
Я не добавляю в стек векторную базу, если достаточно обычного поиска. Не ставлю мультиагентную систему, если задачу решает один надежный сценарий. Не делаю сложный LangChain-пайплайн, если n8n и один backend endpoint закрывают процесс. Техническая сложность должна окупаться снижением ручной работы, ростом конверсии или качеством контроля.
Мой стек AI-разработки в 2026 году — это GPT-4o для языковой логики, n8n для бизнес-оркестрации, Supabase и PostgreSQL для данных, Qdrant для RAG, Next.js для интерфейса и аккуратный деплой с логами. Но главное не инструменты. Главное — собрать систему, которая выдержит реальных клиентов, реальные ошибки и реальные деньги.
Как я выбираю стек под конкретный проект
Перед стартом я задаю не технический, а операционный вопрос: что должно измениться в работе компании после внедрения? Если задача — быстрее отвечать клиентам, стек строится вокруг мессенджеров, CRM и базы знаний. Если задача — контроль бизнеса, важнее источники данных, качество метрик и интерфейс дашборда. Если задача — внутренний помощник для команды, на первый план выходят права доступа, история действий и удобный поиск по документам.
Я стараюсь не начинать с «давайте поставим агента». Сначала описываю процесс как цепочку: входящее событие, классификация, данные, решение, действие, лог, уведомление, проверка. После этого становится понятно, где нужна LLM, где достаточно обычного правила, где нужен webhook, а где лучше оставить ручное подтверждение. Такой подход снижает стоимость разработки и делает систему предсказуемой.
Например, в ассистенте для продаж модель нужна для понимания свободного текста и подготовки ответа, но создание сделки лучше делать строго через валидированную функцию. В дашборде модель может объяснять отклонения и писать выводы, но сами цифры должны считаться детерминированно. В RAG-системе модель формулирует ответ, но источник истины — документы, версии и фильтры доступа.
Что обязательно документирую
Для каждого AI-проекта я фиксирую карту интеграций, список инструментов агента, ограничения модели, структуру базы знаний, правила эскалации и список критичных сценариев. Это нужно не для бюрократии. Через месяц клиент обязательно попросит изменить логику, добавить новый канал или подключить еще одну CRM. Если архитектура не описана, любое изменение превращается в расследование.
Отдельно документирую стоимость работы модели: средний расход на диалог, лимиты, дорогие сценарии и способы оптимизации. В 2026 году AI уже нельзя внедрять как игрушку без экономики. Клиент должен понимать, сколько стоит один обработанный лид, один отчет или один поиск по базе знаний. Тогда решение можно сравнить с работой менеджера, аналитика или подрядчика.
В итоге мой стек — это не попытка угнаться за всеми новинками. Это рабочий набор, который позволяет быстро собрать первую версию, проверить ее на реальных данных, измерить эффект и затем усилить систему там, где она действительно зарабатывает деньги или экономит время.