В мире веб-разработки и искусственного интеллекта появляются проекты, которые выходят далеко за рамки привычных представлений о создании программного обеспечения. Одним из таких необычных и вдохновляющих примеров является процесс разработки AI-конструктора приложений с помощью уже существующего AI-конструктора, который, в свою очередь, был создан таким же AI-конструктором. Это своего рода технологический парадокс, который заставляет взглянуть под новым углом на возможности современных инструментов и вызовы, с которыми сталкиваются разработчики при реализации подобных концепций. Идея создания AI-конструктора приложений при помощи другого AI-конструктора звучит интересно, но она сопряжена с множеством технических и концептуальных сложностей. Все начинается с выбора подхода к разработке.
Многие современные конструкторы сайтов и приложений функционируют на основе единственного React-приложения, созданного с помощью сборщика Vite, что обеспечивает достаточно быструю разработку и удобную структуру проекта. Однако такие приложения нередко сталкиваются с ограничениями, связанными с вызовами API и политикой CORS, что особенно актуально при работе с облачными сервисами вроде API антропического происхождения. Чтобы обойти эти ограничения, создается отдельный бекенд-сервер на Node.js, который выступает в роли прокси для API-запросов. Такой сервер хранит ключи доступа безопасно и осуществляет взаимодействие с внешними API за фронтендом, разгружая клиентскую часть и предотвращая блокировки по безопасности.
Это первый шаг к реализации работы полноценного веб-приложения, которое может масштабироваться и поддерживать комплексные интерактивные функции. Однако далеко не все так просто – помимо вопросов безопасности и архитектуры, большое внимание уделяется работе с виртуальной файловой системой, необходимой для полноценного редактора кода, встроенного в браузер. Создание такой файловой системы требует глубокого понимания особенностей веб-контейнеров. Веб-контейнер, представляющий собой изолированную среду выполнения Node.js прямо в браузере, позволяет запускать фулл-стек приложения без необходимости обращаться на удаленные серверы.
Это кардинально меняет подход к построению подобных конструкторов, поскольку разработчик теперь может запускать, редактировать и тестировать приложения полностью на клиентской стороне, используя преимущества песочницы. Важным и интересным открытием стало понимание механизма работы таких систем как bolt.new или stackblitz, которые применяют веб-контейнеры. Они не только запускают код локально, но и обеспечивают обратную связь между фронтендом и бэкендом через встроенные iframe и прокси-сервера. Благодаря этому создается эффект полноценного удаленного сервера, который на самом деле функционирует прямо в браузере, что резко ускоряет процессы и упрощает разработку.
При создании второго уровня AI-конструктора (то есть AI-конструктора, созданного внутри первого) появились серьезные проблемы с реализацией настоящей среды выполнения React-приложения. Изначально код внутри приложения был представлен в виде статического HTML, который фактически не компилировался и не запускался как полноценный интерфейс, а лишь имитировал работу. Подобный подход имел ограничения и не позволял реализовать полную функциональность, необходимую для полноценного создания приложений внутри конструктора. Решением стало интегрирование настоящего webcontainer, позволяющего запускать полноценный пакет с React и Node.js на виртуальной файловой системе в браузере.
Переход к использованию webcontainer выявил множество тонкостей. Например, в процессе конфигурирования Vite необходимо было внимательно проверять настройки для корректной работы MIME-типов и отслеживать состояние файловой системы. Ошибка, связанная с тем, что файлы исчезали из каталога и не попадали в сборку, была связана с механизмом объединения нескольких файловых деревьев в одну структуру. Глубокое слияние виртуальной файловой системы оказалось критически важным для сохранения вложенных папок и возможности полноценного отображения в редакторе. Другая интересная и важная проблема касалась взаимодействия с чат-ботом Claude, отвечающим на запросы пользователя и помогающим редактировать код.
Для корректной работы этого диалогового интерфейса необходимо было обеспечить возможность читать и записывать файлы через API, что привело к реализации специального текстового редактора на стороне сервера. Задача заключалась в том, чтобы бот мог динамически получать доступ к содержимому виртуальной файловой системы и вносить изменения согласно запросам, не повреждая при этом исходный код конструктора. Один из наиболее любопытных моментов проекта — автоматическое саморедактирование приложения. Интеграция AI, способного самостоятельно изменять исходный код, породила неожиданные ситуации, когда приложение случайно переписывало собственные основные файлы, приводя к краху и нарушениям в работе. Для решения этой проблемы потребовался тщательный контроль зон, к которым имел доступ бот, а также внедрение механизмов ограничения прав редактирования.
Проблемы управления состоянием и синхронизацией между виртуальной файловой системой на клиенте и серверной частью также сыграли важную роль. Отсутствие полноценного взаимодействия между сервером Node.js и фронтендом привело к тому, что изменения, внесённые ботом, не отображались сразу в редакторе и не запускались в живом превью. Ключевым решением стало внедрение механизмов двунаправленного обмена файлами — обновлённый набор файлов теперь подгружался обратно и монтировался в виртуальную файловую систему, что обеспечило согласованность состояния. Разработка API взаимодействия с ключевыми сервисами, такими как антропический API, потребовала дополнительного внимания.
В особенности при работе с несколькими уровнями AI-конструкторов возникли сложности с проксированием запросов и обходом ограничений CORS. Для их решения создавался отдельный сервер с включенной политикой CORS, который выступал посредником и корректно обрабатывал запросы с разных уровней вложенности, обеспечивая стабильную работу всех сервисов. Опыт работы с AI-конструкторами, создаваемыми внутри друг друга, даёт уникальное понимание современных инструментов разработки. Он показывает, насколько важны правильно спроектированные архитектуры, гибкие виртуальные среды и надежная интеграция с AI-моделями, способными анализировать, создавать и исправлять код. Текущий подход позволяет разработчикам быстро создавать прототипы, тестировать идеи и даже строить целые рабочие приложения напрямую в браузере, используя лишь мощь AI и современные веб-технологии.
Это меняет традиционные представления о необходимости сложных бэкендов и серверов, открывая двери для минимума инфраструктуры при максимуме возможностей. Одним из важных этапов развития подобных проектов является обеспечение сохранности и доступности разработанных приложений. К сожалению, полноценная интеграция с GitHub или автоматические деплои на Netlify на данный момент не реализованы из-за сложности реализации и дополнительной нагрузки на систему. Вместо этого используется сохранение виртуальной файловой системы в локальном хранилище браузера и возможность скачивания полного пакета проекта для дальнейшей синхронизации с системами контроля версий вручную. В перспективе подобные AI-конструкторы смогут полностью заменить традиционные инструменты разработки для многих типов приложений, особенно когда дело касается создания простых сайтов и утилит.
Наличие встроенного AI, способного писать, исправлять и оптимизировать код в реальном времени, значительно увеличивает производительность, сокращает время от идеи до реализации и расширяет возможности для начинающих программистов. Подводя итоги, можно сказать, что создание AI-конструктора приложений с помощью AI-конструктора, который был построен другим AI-конструктором — это не просто смешная игра с технологией, а глубокий исследовательский опыт, расширяющий границы современных подходов. Он демонстрирует потенциал искусственного интеллекта в автоматизации и оптимизации процессов программирования и открывает новый путь к более интеллектуальным, доступным и гибким инструментам разработки.
