ИИ пишет код, а инженер — архитектуру: как собрать AI PoC в 2026
PrimeCoder · 2026 · формат: actualka
Как решить проблему прямо сейчас: рабочие способы и риски.
Вайб-кодинг ускоряет написание кода, но PoC с авторизацией, платежами и LLM упирается в архитектуру, деплой и оплату зарубежных API — это меняет оценку сроков и требования к инженерам в штате.
Связанные услуги: каталог, AI Boost Team, стать клиентом.
Код готов к вечеру, а PoC — нет
Знакомая картина. Вы садитесь за Claude Code, ставите задачу, к утру у вас есть фронтенд, бэкенд и экран логина. Через три дня вы обнаруживаете себя не в редакторе, а в панели Google Cloud Console, в личном кабинете налоговой и в переписке с платёжным провайдером. Строчки кода за это время не написано ни одной.
Пет-проект MirrorVote — AI-помощник выбора образа: загружает фотографии, приводит их к единому виду, оценивает наряды под конкретный повод, даёт ссылку для голосования друзей. Разбор выложен на Хабре автором AlexeySushkov, 9 минут чтения, охват 10K, публикация свежая — 16 часов на момент сигнала. Проект делался как выпускная работа курса сообщества ODS (Open Data Science), то есть перед нами не продакшн-кейс корпорации, а ровно то, что может собрать небольшая команда или один инженер.
В статье разберём типовую архитектуру современного AI PoC на примере моего пет-проекта и ответим на вопрос: если AI умеет писать код, зачем все еще нужен инженер?
С помощью AI сегодня каждый может навайбкодить приложение за считанные часы. Но чтобы превратить его в рабочий PoC, нужно решить ряд архитектурных, инженерных и организационных задач. Именно они занимают гораздо больше времени и требуют уже других навыков.
Про наряды можно забыть. Ценность разбора в другом: он показывает, из чего в 2026-м состоит типовой AI PoC и где именно начинается работа, которую модель за вас не сделает.
SDLC никуда не делся, просто на каждом этапе разрешено срезать угол
Классический цикл разработки остался. Изменилась планка: для PoC не нужен промышленный уровень, нужен минимально работающий. Автор раскладывает цикл так:
- Анализ требований. Берём один пользовательский сценарий или голый MVP. Остальное в бэклог, который, скорее всего, никогда не откроют.
- Проектирование. Минимальная схема базы, только критичные интеграции — авторизация, LLM, платежи. Каждая лишняя сущность в схеме потом стоит часы на миграции.
- Реализация. Вайб-кодинг в Claude Code, код в GitHub. Модель действительно пишет быстро.
- Тестирование. Ручные проверки основных сценариев. Для PoC хватает, для первых платящих пользователей — уже нет.
- Развёртывание. Локально или на облачном VPS, вручную или через GitHub Actions.
- Эксплуатация. Базовая наблюдаемость: смотрим ошибки в логах, следим за доступностью приложения и стоимостью внешних сервисов.
Срезать угол можно. Выкинуть этап нельзя. Именно на последних двух пунктах вайб-кодинг заканчивается и начинается инженерия, потому что развёртывание и эксплуатация не про генерацию кода, а про решения.
Сценарий MirrorVote: что происходит между кликом и результатом
Пользователь нажимает кнопку «проанализировать». Дальше система должна отработать шесть шагов, и каждый — точка отказа:
- Авторизация через Google OAuth, получение JWT для последующих запросов.
- Загрузка фотографий.
- Проверка пользователя и его доступного лимита в PostgreSQL.
- Вызов LLM: обработка фото, анализ образов, текстовая рекомендация.
- Сохранение обработанных изображений в Storage, результатов и оценок в базу, списание лимита.
- Возврат пользователю картинок и разбора.
Плюс отдельная ветка — публичная ссылка для голосования. Здесь спрятана неочевидная ловушка из разбора: если поля ссылки сериализуются неаккуратно, наружу утекает лишнее. Никакая модель вам об этом не напомнит, потому что код формально работает.
Слои системы: кто за что отвечает
Вход и сетевая обвязка
MirrorVote собран как PWA: одна кодовая база обслуживает и браузерную версию, и установленное на смартфон приложение. Браузер не ходит во внешние API напрямую. Единая точка входа — Nginx на VPS у Selectel, он же веб-сервер, он же reverse proxy, он же маршрутизатор запросов к нужным сервисам. Схема нужна ещё и для того, чтобы закрыть проблемы с доступностью Supabase для российских пользователей. Это то самое решение, которое нельзя написать промптом: его можно только принять.
Бэкенд
Взят managed Supabase — меньше инфраструктуры под собственным присмотром. Внутри три части: Edge Functions на Deno, где живёт серверная логика и хранятся секретные ключи внешних API; PostgreSQL с пользователями, сессиями, результатами анализа, лимитами и платёжными событиями; Storage под исходные и сгенерированные изображения с ограничением доступа по пользователям.
Интеграции
Авторизация через Supabase Auth с провайдером Google — требует настройки callback URL и учётных данных. Платежи через ЮKassa: серверная функция создаёт платёж и принимает webhook о результате. LLM через OpenRouter: функция собирает системный промпт, передаёт изображение и получает разбор. В проекте две модели — google/gemini-2.5-flash-image (Nano Banana) для приведения фотографий к единому виду и google/gemini-2.5-flash для анализа.
Для анализа выбран Gemini 2.5 Flash, так как для этой задачи не нужна тяжелая reasoning‑модель: необходимо быстро обработать изображение и контекст, выставить оценки и вернуть небольшой структурированный ответ.
Выбор модели — решение про деньги и латентность, а не про вкус. Reasoning-модель здесь жгла бы бюджет и время ответа без выигрыша в качестве.
Организационный блок, который AI не закроет никогда
Самая недооценённая часть PoC. Половина пунктов — не программирование, а бюрократия и логистика:
- ЮKassa. Для физлица простой путь — зарегистрироваться как самозанятый, подготовить лендинг с описанием услуги, актуальными ценами, контактами и реквизитами, пройти проверку сервиса, получить данные для интеграции.
- OpenRouter. Нужен аккаунт, API key и пополненный баланс. Оплата зарубежного сервиса из России — отдельный квест, и это не преувеличение.
- Supabase. Проект и параметры подключения; бесплатного тарифа для PoC достаточно.
- Google Cloud Console. Учётные данные и настройка OAuth-провайдера.
- VPS. Автор выбрал Selectel и честно пишет: не самый дешёвый вариант, зато надёжность и поддержка на уровне. Это нормальная формулировка для решения, где экономия на хостинге оплачивается ночами в логах.
- Домен и DNS-зона — там же.
Что подключить по этому материалу
Три опоры: продуктовый контур AI Boost Team, смежные инженерные услуги и живой разбор под вашу операционку.
Продукт
AI Boost Team
Внешний контур: интеграции, недельная отчётность, расширение после подтверждённых цифр — без «магии нейросетки».
- CRM, поддержка, контент-процессы
- Baseline до старта и контрольные точки
- Human-in-the-loop там, где нельзя автоматизировать в ноль
Автоматизация
Чат-бот для бизнеса
Бот для лидогенерации, поддержки или записи — с передачей контекста в CRM и эскалацией к менеджеру.
- Сценарии под ваш процесс
- Интеграция с CRM
- Аналитика диалогов
Созвон
Сопоставить статью с вашим процессом
Стек, нагрузка, SLA: переводим текст материала в реальные вводные без общих слов.
- Короткий созвон с теми, кто будет в работе
- Без обязаловки по договору
- Можно сразу с командой имплементации
Сценарий внедрения: дорожная карта на первые недели
Сначала отделить факт от хайпа, затем выбрать один практический шаг для бизнеса.
- Нулевая неделя: baseline-метрики, карта ролей и ответственности, технические ограничения и SLA.
- Неделя 1-2: запуск узкого пилота, контрольные точки, лог ошибок типовых сценариев.
- Неделя 3-4: первое улучшение по KPI или честное признание, что нужно поменять сценарий/данные.
- Неделя 5+: масштабирование на смежные процессы и фиксация регламентов, чтобы качество держалось без геройства команды.
Формат “один главный результат на одну неделю” сохраняет темп и экономит управленческое внимание.
Этапы процесса
Упрощённая схема этапов: подписи можно сопоставить с вашими реальными шагами в CRM, поддержке или разработке.
Рисунок: логический поток без привязки к конкретному вендору. Риски и как их снять заранее
- Запуск без baseline и недельной аналитики — самый дорогой вариант, потому что непонятно, что лечить.
- Смешивание многих задач одновременно — обычно увеличивает календарные сроки и бюджет сверх суммы задач по отдельности.
- Слабая интеграция с точками истины данных (CRM, биллинг, тикет-системы) даёт красивый интерфейс и плохой бизнес-эффект.
Отдельно для разработки: фиксируйте производительность, безопасность и индексируемость страниц как часть DoD деплоя, а не постфактум.
Термины, чтобы говорить с подрядчиком на одном языке
- Baseline — текущее измерение конверсии, скорости и стоимости до изменений.
- Критический путь — этапы без которых сайт или продукт нельзя стабильно эксплуатировать.
- Acceptance checklist — формализованные критерии приемки, чтобы исключить “сдал как получилось”.
Что сделать дальше
Короткая диагностика под ваш процесс: обычно 3 дня для малого бизнеса и до 5 дней для проектов со сложной воронкой и несколькими стейджами.
Быстрый расчет эффекта: (количество заявок × текущая стоимость обработки заявки) − (то же после внедрения целевой модели) + (дополнительные продажи × средняя маржа). Число получится грубым и полезным: оно задаёт экономику решения даже без идеальных данных.
По запросу высылаем чеклист диагностики и шаблон weekly-отчёта по экспериментам: там видно, когда пора усиливать сценарий, а когда — остановиться.
- Обсудить применение под вашу задачу: Открыть форму контактов PrimeCoder
- Получить план внедрения на 30 дней: Подключить AI Boost Team как внешний AI-офис с KPI
Практическое действие после чтения
Проверьте скорость, мобильность и базовые SEO-ошибки до разговора с подрядчиком.
FAQ по теме статьи
Как применить материал «ИИ пишет код, а инженер — архитектуру: как собрать AI PoC в 2026» к своему сайту без редизайна с нуля?
Начните с одного узкого сценария: форма, первый экран, скорость, мобильная версия или путь до заявки. Большой редизайн нужен не всегда.
Что спросить у подрядчика перед доработками?
Попросите назвать метрику, которую доработка должна изменить, способ проверки и критерий остановки. Без этого задача легко превращается в бесконечные правки.
Когда техническая доработка не даст роста?
Когда проблема в оффере, цене, трафике или доверии. Техника усиливает рабочую воронку, но не заменяет продуктовый смысл страницы.
Дальше по теме платформы: смежные материалы (Разработка и запуск продукта)
Статью лучше читать в связке — так быстрее собирается картина, как ответ складывается в работающую воронку, а не в изолированный совет.