Я открыл код портала, созданного для клиентских приложений на Vibe Coding: История, архитектура и выводы

Введение

Лето 2026 года. Мир разработки разделился на два лагеря: тех, кто пишет код руками, и тех, кто «вибрирует» его через нейросети. Vibe coding — термин, введённый Андреем Карпатым в начале 2025 года, — превратился из эксперимента в полноценную методологию. Суть проста: вы описываете желаемую функциональность на естественном языке, а AI-агент (например, Claude 3.7 Sonnet или GPT-5 с режимом Codex) генерирует код в реальном времени. Вы лишь направляете процесс, исправляете ошибки и принимаете решения.

Однако у этой медали есть обратная сторона. Когда я начал работать с клиентом, который хотел запустить экосистему из пяти vibe-coded приложений (от дашборда аналитики до внутреннего чата поддержки), мы быстро столкнулись с классической проблемой: как управлять этим зоопарком микросервисов? Каждое приложение было написано на разных фреймворках (React, Svelte, даже один на HTMX), имело свою базу данных и собственную систему аутентификации. Клиент хотел единую точку входа — портал, где пользователи могли бы переключаться между приложениями, а администраторы — управлять доступом.

Я построил такой портал. А спустя месяц я принял неожиданное решение: я открыл его исходный код. В этой статье я расскажу, почему я это сделал, как устроена архитектура портала, какие грабли мы собрали на vibe coding и какие уроки я вынес для сообщества.

Проблема: Vibe coding без оркестрации

Когда говорят о vibe coding, обычно показывают демо: «Смотрите, я за минуту написал Todo-приложение!». Но реальность enterprise-разработки сложнее. В нашем проекте было пять приложений, каждое из которых имело:
- Свою базу данных (PostgreSQL, SQLite, Supabase)
- Свой API (REST, GraphQL, WebSocket)
- Свою систему логина (Auth0, Firebase Auth, самописная на JWT)
- Разные версии зависимостей

Клиент хотел, чтобы пользователь входил один раз и получал доступ ко всем приложениям. Это классический Single Sign-On (SSO), но с twist: приложения не были спроектированы для интеграции. Мы не могли переписать их — это убило бы всю магию vibe coding. Нужен был надстройка — портал-агрегатор.

Архитектура портала: от замысла до open source

Портал я написал на Next.js 15 с App Router, используя серверные компоненты для рендеринга iframe-вставок каждого приложения. Ключевые решения:

1. Централизованная аутентификация

Вместо того чтобы заставлять каждое приложение поддерживать OAuth, я использовал прокси-сервер на базе Node.js (Express), который перехватывал все запросы к приложениям и подставлял JWT-токен от портала. Приложения «думали», что пользователь авторизован локально. Это не идеально с точки зрения безопасности (мы обсуждали это ниже), но сработало для MVP.

2. Динамическое обнаружение сервисов

Приложения регистрировались в портале через простой JSON-манифест:

{
  "app": "analytics-dashboard",
  "url": "http://analytics.internal:3001",
  "icon": "/icons/chart.svg",
  "requiredRole": "viewer"
}

Портал подхватывал изменения на лету — никаких перезапусков. Это было критично, так как клиент постоянно добавлял новые приложения.

3. Унифицированное логирование

Каждое приложение отправляло логи через портал в центральный Elasticsearch. Это позволило нам отлаживать инциденты, не имея доступа к каждому приложению отдельно.

Почему я открыл код?

Решение далось нелегко. Клиент заплатил за разработку, но я включил в контракт пункт о том, что код может быть открыт через 6 месяцев после запуска — при условии, что клиент получит полную документацию и поддержку. Сработало.

Основные причины:
- Сообщество: vibe coding порождает тысячи однотипных решений. Открыв портал, я дал другим разработчикам шанс не изобретать велосипед.
- Обучение: я хотел показать, как можно «обмануть» SSO без переписывания legacy-кода. Это полезный паттерн.
- Обратная связь: я знал, что архитектура сырая. Open source привлёк внимание инженеров, которые указали на дыры в безопасности (например, возможность XSS через iframe — пришлось добавить Content Security Policy).

Технические детали: что внутри репозитория

Репозиторий доступен на GitHub под лицензией MIT. Вот ключевые компоненты:

Архитектура не идеальна. Например, прокси-сервер — единая точка отказа. В production мы бы использовали API Gateway (Kong или Envoy), но для MVP и для демонстрации концепции это сработало.

Грабли, на которые мы наступили

Vibe coding — это мощно, но опасно. Вот что мы вынесли:

1. AI генерирует код, который работает, но не документируется

Когда мы попросили AI написать модуль аутентификации для одного приложения, он выдал рабочий код, но без комментариев. Через месяц мы не могли вспомнить, почему он использует localStorage, а не sessionStorage. Пришлось добавлять JSDoc вручную — это заняло больше времени, чем написать модуль с нуля.

2. Версионный хаос

Каждое приложение тянуло свои зависимости. Одно использовало React 18, другое — React 19. Портал, написанный на Next.js 15, не мог рендерить iframe с React 18 без конфликтов. Решение: мы изолировали каждое приложение в отдельный iframe (разные origin), что решило проблему, но добавило сложности с передачей данных между приложениями.

3. Безопасность — слабое место AI-кода

AI не думает о безопасности. Он пишет код, который проходит тесты, но не устойчив к атакам. Например, в одном приложении AI сгенерировал эндпоинт, который принимал JSON и сохранял его в базу без валидации — классическая SQL-инъекция. Мы потратили неделю на аудит всех AI-сгенерированных модулей.

4. Отсутствие тестов

AI редко генерирует unit-тесты. Мы ввели правило: каждый AI-сгенерированный модуль должен иметь хотя бы один тест, написанный человеком. Это замедлило разработку, но спасло от регрессий.

Практический пример: как это работает

Представьте, что у вас есть три vibe-coded приложения:
1. Дашборд продаж — на React + Chart.js
2. Чат поддержки — на Svelte + WebSocket
3. Система управления задачами — на HTMX + Go

Вы запускаете портал. Пользователь входит через Google OAuth. Портал проверяет роль (admin, viewer, editor) и показывает только те приложения, к которым у пользователя есть доступ. При клике на «Дашборд продаж» портал открывает iframe, а прокси-сервер подставляет JWT в заголовок запроса. Дашборд «думает», что пользователь авторизован, и отображает данные.

Все логи стекаются в Elasticsearch. Администратор видит единую панель мониторинга: какие приложения работают, какие упали, какие требуют обновления.

Будущее vibe coding и порталов

Vibe coding не исчезнет. К 2026 году он стал стандартом для прототипирования и внутренних инструментов. Но он требует инфраструктуры. Порталы-агрегаторы — один из элементов этой инфраструктуры. Я вижу несколько трендов:
- AI-нативные платформы: стартапы уже предлагают сервисы, которые автоматически обнаруживают и интегрируют vibe-coded приложения.
- Стандартизация манифестов: сообщество работает над спецификацией VibeManifest — единого формата описания приложений, чтобы порталы могли подхватывать их без ручной настройки.
- Безопасность по умолчанию: AI-модели начинают учитывать best practices безопасности при генерации кода (например, GPT-5 уже встраивает CSP-заголовки).

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

Заключение

Я открыл код портала, потому что верю: в эпоху vibe coding прозрачность и коллаборация — единственный способ справиться с хаосом. Архитектура, которую я описал, не претендует на звание production-grade — это MVP, который решил конкретную бизнес-задачу. Но он показал, что даже самые «вибрирующие» приложения можно объединить в единую экосистему.

Если вы тоже строите портал для vibe-coded приложений — не бойтесь открывать код. Это не только помогает сообществу, но и заставляет вас писать чище. И помните: AI пишет код, но только человек отвечает за архитектуру.

Статья подготовлена для блога asibiont.com/blog. Если вы хотите глубже разобраться в интеграции AI-сгенерированных приложений и создании единой точки входа, обратите внимание на материалы по автоматизации бизнес-процессов. ASI Biont поддерживает подключение к Telegram через API — подробнее на asibiont.com/courses.