Case Study · AI-native Web Engineering
OptFor.AI: referencyjna architektura AI-native dla landing page
Bazowy pomiar przed publikacją
pełna lokalna bramka wydania
Pomiar npm run check:ci pod Node.js 22 z 4 sierpnia 2026 roku.
testów automatycznych
Bazowy zestaw testów integracyjnych i Chromium uruchomiony na tymczasowym statycznym buildzie.
strona główna po kompresji
Wygenerowany HTML gzip przy utrzymanym budżecie 21 kB.
01 · System
Referencyjna architektura z działającym wdrożeniem
- Właściciel
- OptFor.AI
- Zastosowanie
- Landingi i statyczne serwisy eksperckie
- Zasięg
- Serwis dwujęzyczny: polski i angielski
- Technologia
- Astro, TypeScript, Playwright, GitHub Actions, Vercel
- Status
- Referencyjne wdrożenie działające produkcyjnie
02 · Problem
Ograniczenia modelu opartego na builderze
WordPress z rozbudowanym builderem pozwala szybko układać widoki, ale rozdziela stan strony między bazę danych, konfigurację wtyczek, panel i kod. Trudniej wtedy zobaczyć pełny zakres zmiany, odtworzyć wcześniejszą wersję i sprawdzić całość jednym zestawem testów.
Potrzebowaliśmy landingów, które można rozwijać z pomocą AI tak samo jak kod: przez mały diff, automatyczną weryfikację, review i rollback. Dlatego źródłem prawdy zostało repozytorium, a wersja produkcyjna powstaje w statycznym buildzie.
03 · Realizacja
Kod, Git i jeden proces wydania
Astro generuje statyczny serwis. Git przechowuje komponenty, dane strony, trasy i konfigurację wdrożenia, więc zmiana interfejsu oraz reguła, która ją sprawdza, trafiają do tego samego pull requestu.
Komenda npm run check:ci uruchamia kontrole statyczne, buduje wersję produkcyjną i wykonuje testy na tymczasowej kopii strony. GitHub Actions powtarza ten proces w trzech zadaniach, a deployment czeka na ich wynik.
Nowa osoba lub narzędzie automatyzujące zmianę może sprawdzić typy, uruchomić testy i prześledzić wcześniejsze decyzje w historii Git. Instrukcje pracy są wersjonowane razem z kodem, więc nie trzeba odtwarzać kontekstu z rozmów ani ręcznie porównywać stanów edytora.
04 · Kontrola jakości
Kontrole przed wdrożeniem
- 14 kontroli statycznych uruchamianych równolegle, w tym typy, zależności, formatowanie, CSS, architektura, trasy i nieużywany kod.
- 13 repozytoryjnych skryptów
check-*objętych kontrolą, która blokuje dodanie lokalnej bramki bez podłączenia jej do CI. - Walidacja wszystkich wygenerowanych tras, linków wewnętrznych, danych Schema.org, polityki adresów i granicy między plikami prywatnymi a publicznym artefaktem.
- 101 testów integracyjnych i przeglądarkowych uruchamianych na świeżym, tymczasowym buildzie.
- Testy dostępności według WCAG 2.1 AA, regresji interfejsu od 320 do 1280 pikseli oraz budżet skompresowanego HTML strony głównej.
W pomiarze z 4 sierpnia 2026 roku pełna bramka przeszła pod Node.js 22 w 68,4 sekundy. Typecheck nie zgłosił błędów, ostrzeżeń ani podpowiedzi, a audit zależności nie wykazał znanych podatności. Niepoprawna zmiana kończy się konkretnym komunikatem przed wdrożeniem, zamiast ręcznym szukaniem różnicy na produkcji.
05 · Widoczność
Automatyczne punkty wejścia dla systemów AI
OptFor.AI publikuje llms.txt, dwie mapy witryny, dane Schema.org, adresy kanoniczne i wzajemne alternatywy językowe. robots.txt opisuje zasady dostępu dla wyszukiwarek oraz systemów AI.
llms.txt jest kompilowany z opublikowanych case studies i materiałów bazy wiedzy. Ta sama zasada dotyczy map witryny. Nowa publikacja trafia do maszynowych punktów wejścia bez dopisywania jej do osobnej listy, a test porównuje wygenerowany wynik z publicznymi kolekcjami. Sprawdza też, czy każdy materiał występuje dokładnie raz i czy treści noindex zostały pominięte.
06 · Iteracja
Przebudowa warstwy wizualnej
Pierwsza wersja warstwy wizualnej była zbyt rozbudowana. 14 lipca przebudowa usunęła 1367 linii i dodała 227 w pięciu plikach. Jeszcze tego samego dnia wdrożono prostszy, spójniejszy system.
Obie wersje pozostały w historii Git. Różnicę można było przejrzeć, pełny zestaw kontroli uruchomić ponownie, a w razie potrzeby wrócić do poprzedniego commita. Duża zmiana interfejsu nie wymagała utrzymywania kopii strony ani ręcznego porównywania dwóch konfiguracji.
07 · Przykład
Regresja przełącznika języka
30 lipca mechanizm zachowania pozycji przewijania ujawnił błąd na stronach case studies. Po zmianie języka strona mogła przesunąć czytelnika, mimo że przełączał język na samej górze.
Test Playwright otwiera polskie case study przy scrollY równym zero, przełącza je na angielski adres i ponownie sprawdza pozycję. Poprawka zapisuje informację atPageStart przed nawigacją i na stronie docelowej przywraca górę dokumentu. Ten scenariusz pozostaje w zestawie regresji.
Od 26 czerwca do 4 sierpnia historia projektu zapisała 425 commitów, w tym 232 zmiany bez merge commitów i 191 scaleń pull requestów. Każdą z tych iteracji można przejrzeć, sprawdzić i wycofać niezależnie.
08 · Zastosowanie
Podstawa dla kolejnych wdrożeń
OptFor.AI działa produkcyjnie jako dwujęzyczny, statyczny serwis z indywidualnym interfejsem. Gotowy zestaw komponentów, komend i kontroli może być punktem wyjścia dla kolejnych landingów oraz serwisów eksperckich.
O podejściu AI-native nie decyduje sam wybór Astro. Decyduje to, czy zmianę da się jednoznacznie odczytać, przetestować i wycofać. Repozytorium zapewnia te warunki, dzięki czemu automatyzacja przyspiesza pracę, a zespół zachowuje kontrolę nad publikacją.
Case study · Ostatnia aktualizacja:
OptFor.AI
Potrzebujesz landingu, który można rozwijać z agentami AI?
Porozmawiajmy o referencyjnej architekturze, migracji z edytora wizualnego i bramkach jakości dopasowanych do Twojego serwisu.