Почему AI-генерация UI — это тупик, и как мы делаем Fluw вокруг философии Born-to-Code

Большинство AI-инструментов сегодня обещают магию: «Опиши идею - получи сайт через 30 секунд». Это круто для прототипа на один вечер, но превращается в кошмар, как только вам нужно превратить это в настоящий продукт.

Вы нажимаете кнопку «Экспорт» и получаете либо статичный HTML с Tailwind, который невозможно поддерживать, либо понимаете, что намертво заперты внутри закрытого no-code конструктора. Попытка отдать этот результат разработчику обычно заканчивается фразой: «Проще переписать с нуля, чем разгребать этот AI-код».

Мы в Fluw решили пойти принципиально другим путем. Мы считаем, что генерация красивой картинки - это самая простая и наименее ценная часть процесса. Настоящая работа начинается после.

Поэтому мы создаем платформу, где проект с первой секунды своего существования рождается как полноценное веб-приложение на привычном фронтенд-стеке, с собственным Git-репозиторием и живым окружением. Мы называем это философией Born-to-Code.

Иллюзия готового продукта

AI-конструкторы хорошо работают на первом шаге: они помогают быстро увидеть идею, собрать экран или получить основу интерфейса. Это удобно, когда нужно проверить гипотезу или показать направление команде. Но между таким результатом и реальным веб-приложением остаётся огромный провал. Чтобы продуктом можно было пользоваться, его всё равно нужно доводить, связывать с логикой проекта и адаптировать под реальные сценарии работы.

Инструменты вроде Codex, Claude Code или Cursor отлично помогают разработчикам, но они остаются частью инженерного процесса. Они усиливают команду, которая уже понимает, как устроено приложение, но не снимают с бизнеса необходимость в технической экспертизе. Для малого и среднего бизнеса это означает, что быстрый старт не всегда превращается в быстрый запуск.

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

Философия Fluw: Born-to-Code

Мы верим, что следующая ступень AI-разработки - это не «генератор интерфейсов», а полноценная рабочая среда. Поэтому в основе Fluw лежит один принцип:

Проект должен рождаться как код, а не как макет или картинка.

Мы не хотим, чтобы пользователь в конце работы спрашивал: «А что мне теперь делать с этим результатом?». Вместо «экспортировать код в конце» мы сразу строим проект внутри инфраструктуры.

Git-first. Для проекта создается ваш приватный репозиторий в Gitea. Код не живет только внутри платформы. Его можно открыть, передать разработчику, продолжить локально, подключить к привычному Git-процессу.

Live runtime. Пользователь работает не со скриншотом и не со статичным preview. Fluw запускает приложение в полноценном окружении и показывает живой результат в браузере. Это полноценный запущенный pnpm run dev в рабочем окружении

Visual editing как слой над кодом. Визуальный редактор нужен, чтобы быстро менять текст, поддерживаемые стили и отдельные блоки интерфейса. Но результат таких правок должен попадать обратно в код, а не оставаться внутри закрытой модели конструктора.

AI как участник workspace, а не отдельный чат-бот. AI во Fluw работает внутри проекта: с файлами, выбранными элементами, историей диалога, tool calls и базой знаний проекта. Он не просто отвечает текстом, а может выполнять действия через контролируемые инструменты.

Проект создается как полноценное веб-приложение на веб стекe: Next.js, React, Tailwind CSS и shadcn/ui. Мы сразу закладываем в него правильную структуру файлов, компонентов, крепкий линтер и конфиги. Так разработчики получают качественно настроенный проект без рутины сборки boilerplate, а малый бизнес и дизайнеры - приложение, которое можно поддерживать

Основная идея: вы можете свободно пушить и пуллить в репозиторий вашего проекта. Fluw всегда тянет актуальный код с репозитория. Мы развязываем руки и бизнесу, и разработчикам

На словах это звучит вкусно, а как это сделать ?

С небес на землю

С самого начала у нас возникло много вопросов:

• Как запустить проект без локального окружения?
• Как показать preview в браузере?
• Как дать AI доступ к файлам, не превращая его в неконтролируемый агент?
• Как связать клик на кнопке в iframe с конкретным JSX в репозитории?
• Как визуально отредактировать элемент и не загрязнить исходники служебными атрибутами?

Это комплексная задача, начнем по порядку:

Где живет проект

Чтобы проект был не картинкой, а приложением, ему нужно где-то жить.

У него должна быть файловая система, репозиторий, runtime, жизненный цикл запуска и остановки, возможность поставить зависимости, запустить dev-сервер, сохранить изменения, работать с ветками и дать AI контролируемый доступ к файлам.

На раннем этапе мы рассматривали вариант с браузерными окружениями вроде WebContainer. Это интересная технология, и для некоторых сценариев она действительно может сильно упростить архитектуру. Но для нашей задачи ограничения оказались существенными. Next старше 14 версии просто не запускался

WebContainers на текущий момент не поддерживают часть экспериментальных и низкоуровневых Node.js API, на которых завязан рантайм Server Components и механизмы оптимизации Next.js (в частности, AsyncLocalStorage / work unit storage). При попытке выполнить pnpm run dev в WASM-Node среда падала с ошибкой: Error [InvariantError]: Invariant: Expected workUnitAsyncStorage to have a store. This is a bug in Next.js.

Поняв, что браузерный Node.js не вытянет production-стек, мы перенесли среду выполнения на серверную сторону и разработали собственную изолированную инфраструктуру.

Архитектура изолированных воркеров

Вместо монолитного бэкенда система Fluw разделена на строго разграниченные контексты:

[ Client Browser (Canvas / Iframe) ]
                 │
                 ▼
         [ Gateway Service ]  (Auth, Rate Limiting, Ingress Orchestration)
                 │
                 ▼
       [ Orchestrator ] ──(Управление воркерами)
                 │
        ┌────────┴────────┐
        ▼                 ▼
  [ Worker Pod 1 ]  [ Worker Pod 2 ]  (Изолированные Docker-контейнеры Node 24)
  ┌────────────────────────────────┐
  │  pnpm run dev (Next.js)        │
  │  Workspace / Git Sync          │
  └────────────────────────────────┘

• Gateway Service: Принимает трафик, отвечает за авторизацию, сессии, проверку прав доступа и маршрутизацию запросов к preview.
• Orchestrator: Отвечает за жизненный цикл сред выполнения (Runtime Lifecycle). Когда пользователь открывает проект, Оркестратор динамически разворачивает в кластере изолированный Worker Pod (на базе Node 24).
• Worker Kernel: Внутри пода разворачивается рабочее пространство со своей файловой системой. Он делает чистый git clone из Gitea, подтягивает зависимости через pnpm и запускает dev-сервер Next.js.

Воркеры делают автоматический коммит после завершенного agent loop, визуальной правки или перед завершением работы пода (в случае конфликта создается новая ветка). Так что никакие изменения не будут утеряны.

Рантайм доступен по защищенному адресу *.live.fluw.ru и подгружается в интерфейс редактора через iframe. При этом Gateway тщательно валидирует каждую сессию, предотвращая несанкционированный доступ к чужим окружениям или preview. При этом hot reload проекта при изменении файлов обеспечивает штатный механизм Next.js по сокету, так что хотя бы здесь нам не пришлось усложнять

Важно, что worker не становится владельцем бизнес-логики платформы. Он отвечает за за среду выполнения: файловую систему, запуск приложения, инструменты рядом с кодом. А решения уровня доступа, биллинга и AI остаются в core-сервисах.

Canvas: визуальный слой над живым приложением

Поверх рантайма Next.js у нас работает canvas-редактор. Вы видите iframe с preview и можете работать с ним визуально: менять масштаб, переключать viewport, выбирать режимы инструментов. Это напоминает опыт из Figma или Webflow - но есть принципиальная разница: объект работы не макет, а запущенное приложение.

Главный страх любого фронтендера при упоминании визуальных редакторов - это служебный мусор, который no-code системы встраивают в код страницы: бесконечные data-id, кастомные обёртки и прочие артефакты, которые потом невозможно убрать. Мы подошли к этой проблеме иначе.

Визуальный редактор: без мусора в исходниках

Модель Canonical + Shadow Workspace

Мы разделили чистую кодовую базу и инструментированную runtime-копию проекта.

       [ Shadow Workspace ]                   [ Canonical Workspace ]
(Рантайм с инструментацией)              (Чистая кодовая база под Git)
┌─────────────────────────────────┐      ┌─────────────────────────────────┐
│ <button                         │      │ <button                         │
│   fluwKey="btn-123"             │      │   className="bg-blue-500..."    │
│   instanceFingerprint="xyz"     │ ───> │ >                               │
│   className="bg-blue-500..."    │      │   Отправить                     │
│ >Отправить</button>             │      │ </button>                       │
└─────────────────────────────────┘      └─────────────────────────────────┘
                │
                ▼
      [ Браузер пользователя ]
(Видит только opaque-идентификаторы)

Canonical workspace - это чистая кодовая база проекта. Именно она является источником правды, именно она уходит в Git, именно с ней работает разработчик. В canonical-коде не должны появляться служебные runtime-атрибуты Fluw.

Shadow workspace - это рабочая копия для runtime и instrumentation. В ней можно запускать Next.js с дополнительной инструментализацией, которая нужна визуальному редактору. Но эта инструментализация не загрязняет исходный репозиторий.

Так мы получаем сопоставление между элементом на странице и JSX в исходном коде. Фронт, получая клик в iframe, отправляет на сервер идентификатор, по которому воркер находит в дереве проекта нужный компонент в исходниках репозитория.

Это решает двойную задачу: Fluw не добавляет служебные data-* атрибуты в пользовательский код навсегда, но при этом редактор всегда знает, с каким именно JSX-узлом он работает.

В результате дизайнер или основатель бизнеса может править тексты, цвета и отступы кликами на Canvas, а разработчик, открыв репозиторий, увидит девственно чистый код без малейших следов no-code инструментов.

Важно отметить, что редактор текста и стилей пока находится в активной доработке. Сейчас мы уверенно обрабатываем простые случаи вроде TEXT, но не все сценарии визуального редактирования еще покрыты.

Остался последний неприрученный зверь

Как укротить AI-агента

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

Мы с этим согласны. Поэтому Fluw не строится вокруг идеи «AI сам напишет весь продукт». Мы не продаём иллюзию, что один промпт заменит команду разработки, архитектуру и здравый смысл.

AI в Fluw нужен для другого: быстро менять конкретные части интерфейса, объяснять код, искать по проекту, помогать неразработчикам работать с приложением, снижать стоимость мелких правок. Работать с выбранным элементом, а не с абстрактным промптом. Действовать через инструменты, а не только отвечать текстом.

Ограничение контекста. Вам не нужно отправлять в чат огромные куски кода и писать: «Найди там блок на этой странице». AI знает, на какую страницу вы смотрите в данный момент. Fluw вырезает точечный кусок DOM/JSX-контекста и передаёт его модели. Модель чётко видит, с каким фрагментом она работает и что видит пользователь - это существенно снижает вероятность галлюцинаций.

Tool-based AI Execution. AI во Fluw - это не генератор текста, а агент с набором инструментов. Он может читать файлы, искать по структуре проекта, и не только вызывать write_file, но и делать скриншоты элементов или страницы целиком и принимать решения на их основе.

Линтинг и проверка сборки. После каждого изменения AI обязательно прогоняет код через линтеры и проверяет, собирается ли проект. Это не опциональная проверка - это часть agent loop.

Project Knowledge Base - память проекта. Чем больше вы работаете с проектом, тем точнее работает AI. Мы векторизируем историю всех чатов (через эмбеддинги) и собираем базу знаний проекта. AI может сам сохранять важные подсказки через knowledge_hint и искать по ним через knowledge_search. В следующий раз он не забудет, как именно вы просили именовать типы или что в этом проекте не стоит превращать каждый блок интерфейса в карточку.

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

Помимо этого мы научили AI работать с конкретным элементом на странице:

AI для визуального редактора: зачем выбирать элемент перед промптом

Обычно, чтобы попросить AI изменить часть интерфейса, приходится объяснять словами: «В третьей секции, где карточки преимуществ, во второй карточке справа поменяй текст». Это неудобно, и AI всё равно может понять не то.

Во Fluw вы просто выбираете элемент на canvas и пишете: «Сделай CTA сильнее» или «Сократи текст». Fluw передаёт в AI контекст выбранного DOM элемента (компонент или кусок кода). Это не только удобнее, но и точнее: AI получает не человеческое описание, а ссылку на конкретный элемент живого приложения.

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

В начале было слово, и слово было - качественный шаблон

Одна из частых ошибок AI-генерации - каждый раз начинать приложение с абсолютного нуля. Для демо это выглядит эффектно: пустой экран, один промпт, через минуту появляется интерфейс. Но в реальной разработке полная свобода редко помогает. Чем меньше рамок у модели, тем выше шанс получить случайную структуру, непоследовательные компоненты, разные стили на соседних страницах и код, который сложно развивать.

Поэтому новый проект во Fluw начинается не с пустой директории, а с выбора шаблона.

Для нас шаблон - это не набор красивых экранов и не “тема оформления”. Это стартовая кодовая база: структура проекта, базовые компоненты, типовые страницы, настроенные стили, линтер и конфиги, на которые дальше может опираться и человек, и AI-агент.

Такой подход даёт модели меньше пространства для хаоса. Вместо того чтобы заново придумывать архитектуру, нейминг, структуру компонентов и базовые UI-паттерны, AI работает внутри уже заданной системы координат. Это повышает предсказуемость изменений и делает результат ближе к проекту, который можно поддерживать.

Шаблоны мы собираем вручную: проверяем структуру, зависимости, безопасность исполнения кода и то, как проект поведёт себя после первых AI-правок. Нам важно, чтобы шаблон был не только красивым на старте, но и устойчивым к дальнейшему развитию.

При создании проекта пользователь указывает название и краткий бриф: цель продукта, аудиторию, ключевые страницы, нужные функции и ограничения. Это не декоративное поле. Бриф становится частью стартового контекста проекта, который дальше используют визуальный редактор и AI-агент.

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

Что получает бизнес, дизайнер и разработчик

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

Фаундер или маркетолог может начать с шаблона, описать задачу, визуально поправить страницу, попросить AI изменить конкретные блоки и получить живой проект, а не статичный макет.

Для дизайнера это возможность проверять интерфейсные гипотезы не только в Figma, но и сразу в работающем приложении. Можно менять тексты, акценты, секции, смотреть адаптивность и быстрее доходить до состояния, которое уже похоже на продукт.

Для разработчика важно другое: результат не заперт внутри конструктора. Есть репозиторий, файлы, история, структура проекта. Если AI сделал что-то не так, это не черный ящик. Можно открыть код, посмотреть diff, поправить руками, продолжить локально.

Мы не пытаемся убрать разработчиков из процесса. Скорее наоборот: мы хотим убрать из процесса бессмысленную рутину.

Идеальный сценарий для нас выглядит так:

1. бизнес быстро стартует проект из шаблона; 2. дизайнер или фаундер доводит интерфейс через canvas и AI; 3. AI помогает с мелкими правками и объяснением кода; 4. сложную бизнес-логику при необходимости забирает разработчик; 5. разработчик работает с нормальной кодовой базой, а не с экспортированным мусором.

Честный роадмап: что дальше

Мы не хотим обещать невозможного.

Сегодня Fluw - это мощная, предсказуемая среда для создания и визуально-агентского развития Next.js-приложений прямо в браузере, без жёсткой привязки к закрытому конструктору: у проекта есть Git-репозиторий, и код можно забрать в обычный процесс разработки.

Наш следующий логичный шаг - превратить Fluw из среды разработки в платформу полного цикла: от идеи и runtime-редактирования до production deploy и бизнес-интеграций.

Мы планируем копать в эти направления:

Production Deploy в один клик. Возможность нажать «Publish» и развернуть оптимизированный production-билд на нашей инфраструктуре или экспортировать готовые манифесты в ваш кластер. Архитектурно мы уже движемся в эту сторону - проект живёт как кодовая база с runtime lifecycle, следующий шаг логичен.

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

Экосистема бизнес-интеграций. Нативная поддержка headless e-commerce (на базе Medusa.js), систем аналитики и популярных CRM (amoCRM, Битрикс24) из коробки на уровне шаблонов - чтобы проект не заканчивался на красивом интерфейсе, а превращался в рабочий продукт. Мы понимаем проблему безопасности в контексте AI, поэтому думаем над SDK ядром для проектов, к которому AI не будет доступа

Кастомные MCP-инструменты. Возможность подключать к AI-агенту собственные инструменты, mcp, скилы и сторонние библиотеки компонентов.

Вместо вывода

Мы не верим, что будущее разработки - это кнопка «сделать сайт» и магический результат через 30 секунд.

Через 30 секунд обычно начинается настоящая работа.

Нужно менять тексты, уточнять структуру, проверять адаптивность, подключать данные, сохранять контекст, передавать проект разработчикам, следить за стоимостью AI-операций и не терять контроль над кодом.

Поэтому главный месседж Fluw не в том, что AI может быстро нарисовать интерфейс. Это уже умеют многие.

Главный месседж в другом:

Fluw сокращает расстояние между идеей и развиваемым веб-приложением.

• Быстрый старт остается, но не ценой ограничений платформ.
• Визуальное редактирование остается, но результат живет в коде.
• AI остается, но работает не как генератор текста, а как участник workspace с контекстом проекта.
• Код остается доступным, потому что проект с самого начала рождается как код.

Нам кажется, что именно в этом направлении будет развиваться следующий слой AI-инструментов для веб-разработки: не «заменить разработчика», не «спрятать код», не «сгенерировать одноразовый макет», а соединить визуальный интерфейс, AI и нормальную инженерную основу.

Будем рады обсудить подход в комментариях.

Особенно интересно ваше мнение по двум вопросам:

• какие фичи вы бы хотели видеть для себя и своей команды
• и что для вас самое важное при работе с AI (вцелом, не только про веб)