Poza v0.app: jak zbudowaliśmy generator UI oparty na AI dla Vue i Nuxt (eksperyment z czerwca 2025)

Pierwotnie opublikowano w czerwcu 2025 roku. Zaktualizowano we wrześniu 2026 roku.

Ten artykuł opisuje eksperyment, który przeprowadziliśmy w czerwcu 2025 roku: zbudowaliśmy n0, generator UI oparty na AI dla Vue i Nuxt, na bazie open source'owego projektu bolt.diy.

Od tamtej pory narzędzia AI do tworzenia kodu bardzo się zmieniły. v0.dev to dziś v0.app, Nuxt 4 jest już stabilny, a Nuxt UI jest w pełni darmowy. Oryginalną historię zostawiliśmy bez zmian.

Tam, gdzie informacje się zdezaktualizowały, znajdziesz wyraźnie oznaczone notatki aktualizacja 2026, a do tego osobną sekcję o tym, co nadal jest aktualne, a co już nie.

Czym jest n0 i dlaczego je zbudowaliśmy?

n0 to wewnętrzny generator UI oparty na AI, który zbudowaliśmy w czerwcu 2025 roku do projektów w Vue i Nuxt. Powstał na bazie alternatywy open source dla v0.dev i łączył dobre praktyki, własne prompty oraz strukturę projektu Nuxt 4. Poniżej pokazujemy, dlaczego go zbudowaliśmy, jak działał i jak możesz stworzyć coś podobnego.

Dlaczego zaczęliśmy od v0.dev?

Od pewnego czasu używaliśmy wewnętrznie v0.dev i byliśmy całkiem zadowoleni z rezultatów. Pozwalał nam szybko generować proof of concept i prototypy, które mogliśmy potem weryfikować zarówno na potrzeby naszych wewnętrznych inicjatyw, jak i potencjalnych klientów. Generowane UI i funkcjonalność stały na bardzo wysokim poziomie i były świetnym punktem wyjścia dla nowego projektu.

v0.dev stworzył Vercel, firma stojąca za Next.js, czyli frameworkiem React do budowy stron renderowanych po stronie serwera i generowanych statycznie.

Source: Early version of v0.app

Właśnie dlatego v0.dev generował wysokiej jakości kod w React i Next.js, ale miał trudności z tworzeniem projektów w innych frameworkach, takich jak Vue czy Angular.

Aktualizacja 2026: v0.dev zmieniło nazwę na v0.app w sierpniu 2025 roku i zostało pozycjonowane jako agentic AI builder, który planuje, prowadzi research i debugguje w wielu krokach. W lutym 2026 Vercel dodał import repozytorium z GitHub, środowisko sandbox oraz workflow oparty na branchach i pull requestach. Ale nacisk na konkretny framework się nie zmienił: FAQ v0 nadal podaje, że „v0 uses Next.js, React, TypeScript, Tailwind CSS, and shadcn/ui.” Dla zespołów pracujących w Vue i Nuxt opisana poniżej luka nadal istnieje.

Dlaczego v0 ma trudności z Vue i Nuxt?

W Monterail jesteśmy mocno związani ze społecznościami Vue i Nuxt. Zrealizowaliśmy ponad 40 projektów Vue i wspieramy ten ekosystem przez inicjatywy takie jak raport State of Vue. Próbowaliśmy używać v0.dev do generowania projektów, ale nie byliśmy zadowoleni z wyników, więc zaczęliśmy szukać innych narzędzi do szybkiego prototypowania. Jako oficjalni partnerzy Vue i Nuxt chcieliśmy narzędzia, które odpowiada naszym preferowanym frameworkom i standardom pisania kodu.

Oto ograniczenia, na które trafiliśmy w v0.dev:

• Słabo radzi sobie z generowaniem kodu w Vue/Nuxt.

• Opiera się na założeniach i konwencjach z ekosystemu React.

• Daje niewielką kontrolę nad dobrymi praktykami właściwymi dla frameworka i strukturą projektu.

To nie jest krytyka v0. To naturalny efekt narzędzia budowanego przez zespół stojący za Next.js.

Jakie alternatywy dla v0.dev sprawdzaliśmy?

Pierwszym narzędziem, które zwróciło naszą uwagę, było bolt.new, narzędzie od StackBlitz, które pomaga programistom JavaScript generować nowe projekty i uruchamiać je w przeglądarce dzięki StackBlitz. bolt.new nie jest związany z żadnym konkretnym frameworkiem, co oznacza, że może generować projekty z użyciem dowolnego nowoczesnego stosu narzędzi: React, Vue, Angulara, Node.js i innych. Projekty, które tworzył, były dobre, ale po głębszym rozeznaniu doszliśmy do wniosku, że model cenowy i ogólny charakter tego narzędzia nie są dla nas najlepszym wyborem. Szukaliśmy czegoś skoncentrowanego na Vue i Nuxt.

Aktualizacja 2026: bolt.new nadal działa w modelu cen opartych na tokenach: darmowy plan (1 mln tokenów miesięcznie, 300 tys. dziennie), Pro od 25 USD miesięcznie, Teams za 30 USD za użytkownika miesięcznie oraz indywidualne plany Enterprise.

Jak zbudowaliśmy własny generator UI oparty na AI?

Nie budowaliśmy n0 od zera. Zrobiliśmy fork projektu open source, który miał już za sobą najtrudniejsze elementy, a nasz wysiłek skupiliśmy na kontekście specyficznym dla Vue i Nuxt. Samodzielne odtworzenie czatu, załączników, generowania kodu i podglądów zajęłoby nam miesiące, dlatego szukaliśmy rozwiązania open source, które moglibyśmy dopasować do naszych potrzeb.

Wtedy trafiliśmy na bolt.diy, otwartoźródłową wersję bolt.new. Obsługuje generowanie projektów, integrację z GitHubem, czat, załączniki, uzupełnianie kodu przez AI i nie tylko. To było dokładnie to, czego potrzebowaliśmy!

Source: GitHub repository for bolt.diy

bolt.diy pozwala podłączyć wybrany przez ciebie LLM, w tym Anthropic Claude, Google Gemini, OpenAI i wielu innych dostawców. Możesz też dostosować zarówno UI aplikacji, jak i jej funkcjonalność.

Tak powstało n0, nazwa nadal jest robocza, czyli alternatywa dla v0.dev stworzona specjalnie z myślą o projektach w Vue i Nuxt. Jego system prompt uwzględnia dobre praktyki dotyczące SEO, wydajności, dostępności i nie tylko.

Source: early version of Monterail's n0

Jak hostowaliśmy n0 i kontrolowaliśmy dostęp?

n0 hostowaliśmy na Cloudflare, bo w tamtym czasie była to jedyna platforma obsługiwana przez bolt.diy. Ponieważ wciąż testowaliśmy to narzędzie wewnętrznie, ograniczyliśmy dostęp za pomocą Cloudflare Zero Trust, dopóki nie upewniliśmy się, że projekt spełnia wszystkie nasze potrzeby.

Chcesz hostować własną wersję? Ten wideo tutorial wdrożenia bolt.diy na Cloudflare pokazuje cały proces krok po kroku.

Aktualizacja 2026: bolt.diy nie jest już ograniczony do Cloudflare. Jak podaje jego repozytorium na GitHubie, możesz teraz uruchomić go lokalnie, w Dockerze albo jako aplikację desktopową w Electronie. Potrafi wdrażać wygenerowane aplikacje na Vercel, Netlify lub GitHub Pages, obsługuje ponad 19 dostawców LLM i integruje się z Model Context Protocol (MCP). Projekt jest nadal aktywnie rozwijany. Jedno ważne zastrzeżenie z tego samego README: API WebContainers, na którym działa, wymaga licencji komercyjnej do użycia produkcyjnego w działalności nastawionej na zysk, choć prototypy jej nie wymagają.

Co zawiera Monterail Nuxt Starter?

Monterail Nuxt Starter to publiczny szablon, którego n0 używało jako bazy dla każdego wygenerowanego projektu, dzięki czemu każdy prototyp startował z tym samym zestawem pakietów, strukturą i konwencjami. Wybraliśmy Nuxt jako domyślny framework Vue ze względu na jego dojrzałość, wygodę pracy i elastyczność. Nuxt daje ci narzędzia do budowy każdego rodzaju projektu w Vue, od prostej aplikacji jednostronicowej (SPA) po złożoną aplikację renderowaną po stronie serwera (SSR).

Nasz Monterail Nuxt Starter jest publicznie dostępny. Zawiera z góry skonfigurowane pakiety, takie jak Nuxt Image, Nuxt UI, Nuxt Fonts i VueUse, które uważamy za niezbędne w różnego rodzaju projektach Vue/Nuxt.

W standardzie od razu dostajesz, stan na czerwiec 2025:

• @nuxt/image do optymalizacji mediów

• @nuxt/ui (v2) do dostępnych komponentów UI

• nuxt-fonts i vueuse dla wydajności oraz narzędzi pomocniczych

• Wstępnie skonfigurowaną strukturę projektu i dobre praktyki

Dlaczego użyliśmy Nuxt UI v2 zamiast v3?

Pewnie zauważyłeś, że starter korzysta z Nuxt UI v2, czyli poprzedniej głównej wersji. Wynika to z tego, że Nuxt UI 3 używa Tailwind CSS v4, który w tamtym czasie nie działał dobrze z WASM, czyli generowaniem projektów w StackBlitz. Projekt nie chciał się kompilować ani uruchamiać w kontenerze webowym, mimo że lokalnie i produkcyjnie działał bez zarzutu. Na razie postanowiliśmy zostać przy v2, ponieważ dobrze współpracował ze StackBlitz, a migrację do Nuxt UI 3 odłożyć na później.

Poleciliśmy n0, by zawsze używało tego szablonu, tak aby zarówno podgląd w kontenerze webowym, jak i wdrożona instancja działały zgodnie z oczekiwaniami.

Aktualizacja 2026: Tu trochę się zmieniło.

• Nuxt UI jest teraz w wersji v4. Nuxt UI v4, wydany we wrześniu 2025 roku, połączył Nuxt UI Pro w jeden darmowy pakiet open source z ponad 110 komponentami i udostępnia serwer MCP, dzięki czemu narzędzia AI mogą bezpośrednio odczytywać jego dokumentację. Połączenie z wersją Pro stało się możliwe po tym, jak Vercel przejął NuxtLabs w lipcu 2025 roku.

• Blokada związana z Tailwind v4 może już nie mieć zastosowania. Tailwind dodał od tamtej pory eksperymentalną kompilację WebAssembly swojego silnika Oxide, przeznaczoną do środowisk przeglądarkowych takich jak StackBlitz. Zanim przejdziesz na nową wersję, przetestuj to w swojej konfiguracji.

• Publiczny starter nie został jeszcze zaktualizowany. Według stanu na moment tej aktualizacji, w pliku package.json nadal przypięte są wersje nuxt ^3.16 i @nuxt/ui ^2.21, a Nuxt Fonts nie figuruje wśród zależności. Nuxt 3 osiągnął koniec wsparcia 31 lipca 2026 roku, więc traktuj ten starter jako punkt odniesienia dla struktury i konwencji, a nie jako bazę dla nowych projektów produkcyjnych.

Jak dopracować system prompt LLM pod Nuxt?

Spisujesz reguły, których twoi doświadczeni deweloperzy Vue już przestrzegają, formułujesz każdą z nich jako krótką, jednoznaczną instrukcję i umieszczasz je w system promptcie. Domyślny system prompt bolt.diy jest ogólny i przeznaczony do różnego rodzaju nowoczesnych projektów internetowych, więc od razu wiedzieliśmy, że trzeba go dostosować do Vue i Nuxt. Nasze doświadczenie z tymi frameworkami podpowiadało nam, jakich zasad LLM potrzebuje, żeby budować projekty, o jakie nam chodzi.

Poniżej znajdziesz reguły, które zapisaliśmy w system promptcie w czerwcu 2025 roku. Z każdą kolejną iteracją dalej je dopracowywaliśmy, żeby poprawić jakość prototypów.

<nuxt_best_practices>

  1. Use pnpm for all dependency installation and management.

  2. Use NuxtImg for images: modern formats, lazy loading, width/height set.

  3. Use NuxtLink for internal navigation.

  4. Do not write imports for Vue utils (ref, reactive, computed, watch) in script setup blocks—they are auto-imported.

  5. Use Nuxt UI components (UButton, UInput, USelect, etc.) for consistent, accessible design.

  6. Separate the app by pages based on context.

  7. Keep files under 100 lines; split into smaller files if needed.

  8. Extract reusable logic into composables (e.g., useCounter), never use the word "Store".

  9. Use Nuxt's useFetch for data fetching (SSR/client hydration), handle loading/error/data states, and mock data if needed.

  10. Use useHead for page title/meta tags.

  11. Use Nuxt layout components for page structure.

  12. Place all new components, pages, and composables in the app folder (Nuxt 4+ syntax).

  13. Write complete, copy-pasteable Vue component code.

  14. All code must be accessible and follow best practices.

  15. Remove unused imports; do not import auto-imported components/composables/utils.

  16. Create reusable components for logic like modals/forms; do not place such logic in pages.

  17. Each component, page, or composable must be in its own file.

  18. Wrap Nuxt UI components in custom components for reusability and consistent behavior.

  19. Keep as much logic as possible in composables, not components; components should focus on UI.

  20. Avoid logic in pages—move to composables/components. Only SEO logic belongs in pages.

  21. Use components in pages/layouts for maintainability and clarity.

  22. Always use Nuxt 4+ compatible syntax for all new code.

</nuxt_best_practices>

Możesz śmiało zastosować te reguły we własnych projektach. Kierują model w stronę jakości oprogramowania, sprawdzonych wzorców i konwencji, których oczekujemy, dzięki czemu deweloperzy Vue/Nuxt mogą wejść do wygenerowanego projektu bez konieczności wcześniejszego rozplątywania jego struktury. Ta sama zasada dotyczy też asystentów AI do tworzenia kodu w ogóle.

Co nadal pozostaje aktualne, a co zdezaktualizowało się od czerwca 2025 roku?

Założenie stojące za n0 dobrze zniosło próbę czasu. Konkretne narzędzia i wersje już nie. To, czy kod Vue wygenerowany przez AI nadaje się do użycia, nadal zależy od kontekstu właściwego dla frameworka, ale sposób dostarczania tego kontekstu się zmienił. W tabeli poniżej omawiamy po kolei każde twierdzenie z oryginalnego artykułu.

Jak dziś dostarczylibyśmy ten sam kontekst?

W 2026 roku nie musisz już umieszczać wszystkiego w jednym system promptcie. Nuxt udostępnia teraz oficjalny serwer Nuxt MCP, a Nuxt UI ma własny serwer MCP. Oba pozwalają asystentom AI, takim jak Claude Code i Cursor, pobierać na żądanie aktualną dokumentację oraz metadane komponentów. Konfiguracja, która dziś dobrze się sprawdza, wygląda tak:

• Reguły, takie jak wspomniane wyżej 22, w pliku reguł lub instrukcji narzędzia, opisujące konwencje twojego zespołu.

• Serwery MCP zapewniające aktualną wiedzę o frameworku i komponentach, żeby model nie polegał na nieaktualnych danych treningowych.

• Utrzymywany starter oparty na Nuxt 4 i Nuxt UI v4, dzięki któremu każdy wygenerowany projekt zaczyna z dobrze znanej, sprawdzonej bazy.

To część szerszego przejścia od generatorów opartych na czacie do środowisk tworzenia oprogramowania typu agentic.

Czy warto zbudować własne narzędzie AI do prototypowania, czy lepiej skorzystać z gotowego?

Własne rozwiązanie buduj tylko wtedy, gdy standard frameworka albo wymagania dotyczące prywatności danych sprawiają, że gotowe narzędzia spowalniają cię bardziej niż utrzymanie forka. Tak było u nas w czerwcu 2025 roku. Własny generator hostowany samodzielnie nie jest jednak darmowy, a koszty łatwo zaniżyć:

• Licencjonowanie: bolt.diy działa na WebContainers od StackBlitz, które wymagają licencji komercyjnej do produkcyjnego użycia w działalności nastawionej na zysk.

• Koszty modeli: Korzystasz z własnych kluczy API do LLM, więc koszty rosną z każdym promptem wysyłanym przez twój zespół.

• Utrzymanie promptów i startera: Reguły i szablony starzeją się tak samo szybko jak frameworki. Widać to po naszym starterze, który nadal działa na Nuxt 3.

• Dostęp i bezpieczeństwo: Narzędzie wewnętrzne potrzebuje uwierzytelniania, my używaliśmy Cloudflare Zero Trust, oraz polityki określającej, do jakiego kodu i danych może mieć dostęp.

• Jakość kodu przy przekazaniu: Prototyp, który wygląda na gotowy, nie jest produkcyjną bazą kodu. Zanim wygenerowany kod trafi na produkcję, zaplanuj etap przeglądu i utwardzenia.

Jeśli żaden z tych warunków cię nie dotyczy, masz też inne opcje, na przykład gotowe narzędzie z dobrym plikiem reguł. 

Jak narzędzia UI oparte na AI mogą przyspieszyć prototypowanie w zespołach Vue?

Generatory UI oparte na AI pozwalają zespołowi przetestować pomysł w kilka minut zamiast kilku dni, o ile wynik trzyma się standardów tego zespołu. To właśnie lekcja płynąca z n0 i pozostała aktualna mimo zmian narzędzi. Dzięki bolt.diy każdy mógł zbudować własne narzędzie w stylu v0: sklonować projekt, dodać własny LLM i reguły system promptu, i można działać. Dziś pliki reguł, serwery MCP i asystenci agentic sprawiają, że to samo podejście jeszcze łatwiej wdrożyć.

Najtrudniejszy nigdy nie był sam generator. Chodziło o to, by wiedzieć, które konwencje zakodować i co dzieje się z prototypem, kiedy już działa. Jeśli chcesz w tym wsparcia, od szybkiego prototypowania przez przyspieszenie prac nad MVP z pomocą AI po skalowanie produkcyjnej aplikacji w Vue lub Nuxt, nasz zespół chętnie porozmawia z tobą o możliwościach.