Automatyczne generatory stron internetowych Lovable i Bolt masowo serwują użytkownikom fałszywe potwierdzenia wysłania wiadomości. Badanie zespołu Formgong przeprowadzone na 793 serwisach wykazało, że aż 27 z 105 aktywnych formularzy (25,7%) wyświetlało komunikat „Message sent!”, nie generując przy tym żadnego zapytania sieciowego. Dla firm korzystających z wygenerowanego kodu oznacza to cichą utratę leadów sprzedażowych przy braku jakichkolwiek błędów w konsoli przeglądarki.
Skala cichej awarii w generatorach kodu
Tworzenie serwisów przez platformy Lovable i Bolt pozwala na natychmiastowe wdrażanie interfejsów, lecz rodzi ryzyko nietestowanej infrastruktury backendowej. Testy przeprowadzone przez zespół Formgong na próbie 793 stron ujawniły, że 27 z 105 jednoznacznie ocenionych formularzy kontaktowych generowało komunikat sukcesu bez wysyłania jakichkolwiek danych do sieci.
Przeanalizowana przez Formgong próba obejmowała serwisy wygenerowane automatycznie, z których 119 posiadało formularze kontaktowe, a 105 pozwoliło na uzyskanie jednoznacznego wyniku technicznego. Wyniki badania rozłożyły się w następujących proporcjach:
- 54 formularze (51,4%): pomyślnie przesłały dane do serwera docelowego za pomocą żądania sieciowego.
- 27 formularzy (25,7%): wyświetliło potwerdzenie „Message sent!”, nie wykonując żadnego żądania w sieci.
- 12 formularzy (11,4%): nie zareagowało w żaden widoczny sposób na kliknięcie przycisku.
- 7 formularzy (6,7%): wywołało nagłówek
mailto:, próbując otworzyć lokalnego klienta poczty. - 3 formularze (2,9%): przekierowało na inną podstronę bez przekazania zawartości pól.
- 2 formularze (1,9%): odświeżyły stronę bez przesłania formularza.
Zjawisko fałszywych formularzy nie dotyczy wyłącznie wersji demonstracyjnych. Po odrzuceniu projektów typu hackathon i szablonów testowych, Formgong zbadał 73 rzeczywiste witryny komercyjne bez cech demo — aż 16 z nich (21,9%) posiadało atrapę formularza. W grupie 30 serwisów działających pod własnymi domenami biznesowymi fałszywe powiadomienie generowało 5 serwisów (16,7%).
Czy formularze na Lovable i Bolt naprawdę milczą?
Analiza kodu interfejsów wygenerowanych przez Lovable oraz Bolt wskazuje, że problem wynika ze stosowania domyślnych procedur narzędzi AI. Skrypty wysyłkowe na witrynach Lovable i Bolt często ograniczają się do symulowania opóźnienia sieciowego, wyświetlenia zielonego komunikatu oraz wyczyszczenia pól tekstowych, pomijając wywołania funkcji fetch, interfejsów API czy bazy danych.
Model językowy generujący kod na platformach Lovable i Bolt skupia się na odtworzeniu warstwy wizualnej (UI). Gdy użytkownik nie dostarczy gotowych kluczy API do usług takich jak Formgong, Resend czy SendGrid, generator tworzy zaślepkę w języku JavaScript. Przykładowa obsługa zdarzenia onSubmit na stronach z Lovable i Bolt wykonuje operację setTimeout, wywołuje komponent powiadomienia (toast) z treścią „Message sent!” i czyści pola formularza.
| Element potoku danych | Zachowanie na witrynach Lovable i Bolt | Rzeczywisty stan techniczny |
|---|---|---|
| Interfejs użytkownika (UI) | Wyświetlenie zielonego powiadomienia toast | Wynik dodatni (200 OK w UI) |
| Konsola przeglądarki | Brak błędów JavaScript | Status poprawny |
| Ruch sieciowy (Network Tab) | Brak żądań HTTP POST z danymi | Brak transmisji danych |
| Powiadomienie e-mail / CRM | Brak wpisu w bazie danych lub skrzynce | Cicha utrata leadu |
Sytuacja ta tworzy pozór poprawnego działania. Właściciel serwisu klikając przycisk na stronie zbudowanej w Lovable lub Bolt, widzi komunikat o sukcesie i uznaje integrację za zakończoną. Odwiedzający witrynę otrzymuje sygnał o przyjęciu zgłoszenia, podczas gdy zapytanie bezpowrotnie znika.
Pięć błędów w automatyzacji weryfikacji formularzy
Narzędzie weryfikacyjne stworzone przez zespół Formgong wykazało, że automatyczne testowanie formularzy na stronach Lovable i Bolt wymaga uwzględnienia nietypowych zachowań przeglądarki. Wstępne algorytmy testowe w projekcie Formgong popełniły 5 kolejnych błędów klasyfikacji, błędnie interpretując ruchem wysyłkowym analitykę, okna dialogowe, znikające komunikaty, pułapki botów oraz ukryte elementy formularzy.
Tworzenie automatycznego skryptu testującego wymagało rozwiązania następujących problemów technicznych:
- Ruch analityczny traktowany jako wysyłka danych: Pierwsza wersja testu uznawała każde żądanie sieciowe po kliknięciu za udaną wysyłkę. Strony Lovable wywoływały po kliknięciu pings do narzędzi Google Analytics, Clarity, Hotjar, PostHog oraz Vercel Insights, co maskowało atrapy. Formgong wprowadził wymóg obecności wpisanych wartości testowych (
example.com, numer z prefiksem555) w treści żądania. - Komunikaty w oknach dialogowych alert(): Część witryn wyświetlała potwierdzenie przez natywne okno
alert(), które było automatycznie zamykane przez okno testowe bez odczytania treści. Wdrożono przechwytywanie zdarzeń dialogowych przeglądarki. - Znikające powiadomienia toast: Niektóre formularze na witrynach Lovable i Bolt pokazywały komunikat sukcesu przez 2–3 sekundy, po czym go usuwały z drzewa DOM. Odczyt strony po 5 sekundach kwalifikował formularz jako niedziałający, co wymusiło próbkowanie stanu strony co 250 ms.
- Pułapki na boty typu honeypot: Wypełnienie wszystkich pól tekstowych aktywowało niewidoczne pola zabezpieczające przed botami. Formularz zwracał wówczas status sukcesu, lecz cicho odrzucał wiadomość. Skrypt Formgong zmodyfikowano tak, aby pomijał ukryte pola tekstowe.
- Niewidoczne pola wyboru Radix / shadcn: Wykluczenie ukrytych pól spowodowało pomijanie natywnych elementów
o wymiarach 1×1 px (aria-hidden) stosowanych w bibliotekach Radix i shadcn, na których opiera się Lovable. Uniemożliwiało to walidację formularza, co wymusiło osobną regułę dla ukrytych pól wyboru.
Dla potwierdzenia skuteczności algorytmu zespół Formgong zbudował zestaw 23 lokalnych stron testowych o znanej strukturze; ostateczna wersja testu prawidłowo sklasyfikowała 100% z nich. Z 27 formularzy uznanych za fałszywe na stronach Lovable i Bolt, 21 zostało bezpośrednio potwierdzonych poprzez analizę kodu źródłowego funkcji onSubmit.
Koszty biznesowe i ryzyko cichej utraty leadów
Zjawisko cichej awarii na portalach stworzonych w Lovable i Bolt przekłada się na bezpośrednie straty finansowe i spadek efektywności budżetów reklamowych. Według badań Form Huntsman uszkodzenia doręczalności występują w 1 na 5 formularzy biznesowych, a uszkodzony potok na stronach Lovable i Bolt powoduje bezpowrotną utratę klientów, którzy są przekonani o poprawnym wysłaniu zapytania.
Koszty błędów w automatyzacji testów i doręczaniu wiadomości wykazują dużą asymetrię:
- Koszty fałszywego alarmu (False Positive): Przypadek, w którym test zgłasza awarię sprawnego formularza. Powoduje stratę 20–40 minut pracy inżyniera na weryfikację logów oraz stopniowy spadek zaufania zespołu do narzędzi QA. Gdy wskaźnik fałszywych alarmów przekracza 30%, inżynierowie zaczynają ignorować czerwone alerty w CI/CD.
- Koszty cichej awarii (False Negative): Przypadek, w którym niekompletny formularz przechodzi testy lub wyświetla sukces użytkownikowi bez wysyłki danych. Powoduje marnowanie budżetu Google Ads i Meta Ads, bezpowrotną utratę kontaktów na rzecz konkurencji oraz konieczność przeprowadzania awaryjnych prac wdrożeniowych.
Z badań nad testowaniem oprogramowania wynika, że aż 46,5% nieregularnych błędów testowych (flaky tests) ma swoje źródło w niestabilności zasobów i opóźnieniach asynchronicznych. Pomiary kosztów wytwarzania aplikacji webowych wskazują z kolei, że same procesy testowe frontendu pochłaniają blisko 50% całkowitego budżetu deweloperskiego.
Wnioski praktyczne i rekomendacje
Zapewnienie ciągłości pozyskiwania leadów z witryn Lovable i Bolt wymaga odejścia od wyrywkowego testowania ręcznego na rzecz stałego monitorowania potoku danych. Architekci IT i CTO nadzorujący wdrożenia na platformach Lovable i Bolt muszą zweryfikować zachowanie nagłówków sieciowych oraz skonfigurować bezpośrednie zapisy zdarzeń w bazach danych, aby wyeliminować ryzyko sztucznego potwierdzania wysyłki.
Plany wdrożeniowe dla zespołów technicznych obejmują następujące kroki:
- Zweryfikuj każdy formularz wygenerowany przez Lovable lub Bolt za pomocą narzędzi deweloperskich przeglądarki (DevTools -> Network Tab). Przeprowadź wysyłkę testową i upewnij się, że po kliknięciu przycisku powstaje nowe żądanie HTTP POST zawierające wpisane wartości tekstowe.
- Skonfiguruj persystencję danych po stronie backendu, wymuszając bezpośredni zapis każdego zgłoszenia w bazie danych przed wywołaniem zewnętrznych uslug e-mailowych lub powiadomień CRM.
- Zmierz rzeczywistą doręczalność formularzy, wdrażając automatyczny test end-to-end (np. w Playwright lub testRigor), który co 4–6 godzin wysyła unikalne dane testowe i sprawdza, czy nowy rekord pojawił się w bazie danych oraz skrzynce odbiorczej.
- Wdróż reguły pomijania ukrytych pól tekstowych (honeypot) w automatyzacji QA oraz prawidłową obsługę ukrytych podokien wyboru w bibliotekach Radix i shadcn, zapobiegając fałszywym wynikom testów na stronach zbudowanych w Lovable i Bolt.
Źródła
- 7 Essential End-to-End Testing Best Practices – Testim Blog
- A Survey on Web Testing: On the Rise of AI and Applications in Industry – arXiv
- Agentic AI News: Why Web Automation Keeps Failing on CAPTCHA – CapSolver
- Beyond the Button Click: Using AI to Discover Hidden Edge Cases
- Checking if contact form’s works (automated testing) – Stack Overflow
- False Positive vs False Negative in Testing: a QA Primer – Drizz.dev
- How to Automate Contact Us Form Testing – testRigor AI-Based Automated Testing Tool
- How to Test If Your Contact Form Is Working (And Never Miss a Lead Again)

Dodaj komentarz