Jeśli vibe coding zepsuł Twoją aplikację — nie jesteś sam i sytuacja jest do naprawienia.

Vibe coding — tworzenie oprogramowania przez prompty w narzędziach AI takich jak Cursor, Copilot czy ChatGPT zamiast ręcznego pisania kodu — daje imponujące prototypy w kilka godzin. Ale te prototypy regularnie rozpadają się w warunkach bojowych: luki bezpieczeństwa, brak obsługi błędów, nietestowalny spaghetti-kod i wdrożenia, które po cichu padają.

Wiemy to nie z cudzych artykułów. Z ponad 40 projektów, które trafiły do nas na naprawę kodu AI od początku 2025 roku, ponad połowa była całkowicie lub częściowo wygenerowana przez sieć neuronową. Wzorce awarii są na tyle powtarzalne, że potrafimy przewidzieć problemy po pierwszym git log: dziesięć commitów z komunikatem „fix”, brak branchy, bezpośrednie pushe do main — i już wiemy, że testów nie ma, a deploy jest ręczny.

Rozwiązanie wymaga systematycznego audytu, celowanego refaktoringu i w wielu przypadkach profesjonalnej interwencji — tego, co nazywamy code rescue.

Dlaczego vibe coding psuje aplikacje — raz za razem

Termin „vibe coding” ukuł Andrej Karpathy na początku 2025 roku: opisujesz, czego chcesz, w naturalnym języku, model AI generuje kod, a Ty akceptujesz wynik na podstawie wrażenia — „wydaje się, że działa” — zamiast sprawdzać każdą linijkę.

Podejście z dnia na dzień zdemokratyzowało tworzenie oprogramowania. Nietechniczni założyciele, designerzy i product managerowie nagle mogli budować działające MVP w kilka godzin. I nie ma w tym nic złego — problem zaczyna się dalej.

„Działa na demo” i „gotowe na produkcję” to zupełnie różne standardy inżynierskie. Modele AI optymalizują pod wiarygodność: generują kod, który wygląda poprawnie i uruchamia się bez natychmiastowych błędów. Nie optymalizują pod utrzymywalność, bezpieczeństwo ani wydajność pod obciążeniem.

Ale nie chodzi o to, że AI to „złe narzędzie”. AI to świetny akcelerator. Problem polega na tym, że akcelerator bez dyscypliny inżynierskiej nie tworzy oprogramowania — przyspiesza narastanie długu technicznego. Każdy prompt zaakceptowany bez review to decyzja architektoniczna, za którą nikt nie wziął odpowiedzialności. Pomnóż to przez setki promptów — i otrzymujesz bazę kodu wygenerowaną przez AI, gdzie każdy moduł podejmował decyzje lokalnie, a za całość nie odpowiadał nikt.

7 najczęstszych przyczyn awarii kodu AI

Po przeanalizowaniu kilkudziesięciu projektów z vibe codingu, które trafiły do nas na ratunek, zidentyfikowaliśmy wyraźne wzorce. To nie są pojedyncze przypadki — pojawiają się w niemal każdej aplikacji wygenerowanej przez AI, której nigdy nie sprawdził doświadczony programista.

1. Luki bezpieczeństwa na widoku

AI nie myśli o atakujących. Pisze happy path. Rezultat — zahardkodowane klucze API w plikach frontendowych, brak walidacji danych wejściowych, SQL injection i uwierzytelnianie, które można obejść zmodyfikowanym requestem.

Ale najgroźniejsze podatności to nie te widoczne od razu. Oto realny wzorzec, który znajdujemy w co drugim SaaS-ie wygenerowanym przez AI z obsługą płatności:

// ❌ Kod obsługi płatności wygenerowany przez AI
app.post('/api/upgrade', async (req, res) => {
  const { planId } = req.body;
  const user = await User.findById(req.userId);
  user.plan = planId;            // Zmieniamy plan
  await user.save();             // Zapisujemy
  await stripe.charges.create({  // Pobieramy opłatę
    amount: getPlanPrice(planId),
    customer: user.stripeId
  });
  res.json({ success: true });
});

Na pierwszy rzut oka wygląda normalnie. Ale jeśli wywołanie Stripe się nie powiedzie — użytkownik już otrzymał plan premium, a pieniądze nie zostały pobrane. Brak transakcji, brak rollbacku. W środowisku testowym Stripe zawsze zwraca 200, więc bug nie ujawnia się do produkcji.

// ✅ Prawidłowa kolejność: najpierw pieniądze, potem upgrade
app.post('/api/upgrade', async (req, res) => {
  const { planId } = req.body;
  const user = await User.findById(req.userId);

  const charge = await stripe.charges.create({
    amount: getPlanPrice(planId),
    customer: user.stripeId
  });

  // Upgrade tylko gdy płatność przeszła
  user.plan = planId;
  user.lastChargeId = charge.id;
  await user.save();

  res.json({ success: true });
});

Realny przypadek z naszej praktyki: produkt SaaS w całości wygenerowany w Cursorze — integracja ze Stripe żyła w klienckm JavaScripcie, łącznie z kluczem tajnym. Każdy z DevToolsami w przeglądarce mógł go zobaczyć. Znaleźliśmy klucz w 40 sekund po otwarciu projektu.

2. Zero pokrycia testami

Narzędzia AI prawie nigdy nie generują testów, chyba że się o to wyraźnie poprosi, a nawet wtedy testy są powierzchowne — sprawdzają, czy funkcja nie pada, ale nie testują przypadków brzegowych i logiki biznesowej. Typowy projekt z vibe codingu: dokładnie 0% pokrycia. Każda zmiana to loteria. Nie można refaktorować, aktualizować zależności ani dodawać funkcji bez ryzyka cichej awarii w zupełnie innym miejscu aplikacji.

3. Architektura spaghetti i zduplikowana logika

LLM generuje kod jeden prompt na raz. Każda odpowiedź jest lokalnie spójna, ale globalnie chaotyczna.

Oto co typowo widzimy — i jak to naprawiamy:

// ❌ Przed refaktoringiem: trzy komponenty, trzy kopie tego samego wywołania

// Dashboard.jsx
const userData = await fetch('/api/user').then(r => r.json());

// Profile.jsx
const user = await fetch('/api/user').then(r => r.json()).catch(() => null);

// Settings.jsx
const currentUser = await fetch('/api/user').then(res => res.json());

Trzy komponenty, trzy kopie tego samego wywołania, trzy różne sposoby obsługi błędów. Kiedy API się zmieni — psują się wszystkie trzy i naprawiać trzeba w trzech miejscach. A za miesiąc będzie ich sześć.

// ✅ Po refaktoringu: jeden serwis z obsługą błędów

// services/userService.js
class UserService {
  #cache = null;
  #pending = null;

  async getCurrentUser() {
    if (this.#cache) return this.#cache;
    if (this.#pending) return this.#pending;

    this.#pending = fetch('/api/user')
      .then(r => {
        if (!r.ok) throw new Error(`User API: ${r.status}`);
        return r.json();
      })
      .then(data => { this.#cache = data; return data; })
      .finally(() => { this.#pending = null; });

    return this.#pending;
  }

  invalidate() { this.#cache = null; }
}

export const userService = new UserService();

Jeden punkt wejścia, jednolita obsługa błędów, cache, ochrona przed równoległymi requestami. Każda zmiana API — poprawka w jednym miejscu.

4. Luki we wdrożeniu i infrastrukturze

AI zbudowało Twoją aplikację dla localhost. Działa na Twoim komputerze. Ale nie ma Dockerfile, nie ma pipeline’u CI/CD, nie ma zarządzania zmiennymi środowiskowymi, nie ma środowiska staging. Pierwsza próba wdrożenia ujawnia dziesiątki problemów konfiguracyjnych — od brakujących zmiennych środowiskowych po zahardkodowane localhost:3000 w URL-ach API.

Nieoczekiwany szczegół: z naszych obserwacji wynika, że około 40% czasu przy ratowaniu projektów AI zajmuje nie kod, a infrastruktura. Konfiguracja prawidłowego CI/CD, środowiska staging i zarządzania sekretami często zabiera więcej czasu niż naprawa logiki biznesowej.

5. Schemat bazy danych, który się nie skaluje

Schematy baz danych generowane przez AI działają dla 10 użytkowników, ale padają przy 1000. Brak indeksów, brak strategii migracji, brak walidacji danych na poziomie schematu. Widzieliśmy projekt, w którym cała analityka użytkowników była przechowywana jako bloby JSON w kolumnach tekstowych SQLite — bo tak było szybciej uzyskać „działającą” odpowiedź od AI.

6. Chaos zależności

Modele AI dołączają każdą bibliotekę, która wydaje się pasować w momencie promptu. Rezultat: konfliktujące wersje zależności, porzucone pakiety ze znanymi podatnościami, trzy różne klienty HTTP (axios, node-fetch i natywny fetch) w jednym projekcie i package.json z 80+ zależnościami, z których połowa nie jest używana.

7. Brak obsługi błędów i logowania

Kiedy na produkcji coś idzie nie tak — a tak jest zawsze — aplikacje z vibe codingu nie dają nic. Brak strukturalnego logowania, brak error boundaries, brak monitoringu. Aplikacja pada — użytkownik widzi biały ekran. Ty widzisz biały ekran. Debugowanie oznacza czytanie tysięcy linii kodu AI bez komentarzy i bez zrozumiałych punktów wejścia.

Studium przypadku: platforma SaaS, 14 000 linii, 3 tygodnie do stabilności

Anonimowy przypadek z naszej praktyki — typowy pod względem struktury problemów.

Co do nas trafiło: B2B SaaS na React + Node.js + PostgreSQL, wygenerowany w Cursorze w ~3 tygodnie. 14 000 linii kodu. Integracja ze Stripe, role użytkowników, dashboard z analityką. Działało na demo. Na produkcji — błędy 500 przy równoległych requestach, wyciek kluczy Stripe na frontend, ani jednego testu.

Co znaleźliśmy podczas audytu:

• 11 podatności bezpieczeństwa, w tym 3 krytyczne (w tym Stripe secret key w klienckm bundle)
• To samo zapytanie do bazy danych zduplikowane w 7 miejscach
• Zerowe pokrycie testami
• Brak migracji — schemat zmieniany bezpośrednimi ALTER TABLE na produkcji
• 23 pakiety npm ze znanymi podatnościami

Co zrobiliśmy:

• Dzień 1–2: zamknięcie krytycznych podatności, rotacja wszystkich skompromitowanych kluczy
• Dzień 3–5: konfiguracja Sentry, CI/CD przez GitHub Actions, środowisko staging
• Tydzień 2: napisanie testów integracyjnych dla 5 krytycznych ścieżek, konsolidacja zduplikowanych zapytań do bazy
• Tydzień 3: refaktoring uwierzytelniania, normalizacja schematu, konfiguracja migracji przez Prisma

Czego się nie spodziewaliśmy: najtrudniejszą częścią okazały się nie podatności i nie refaktoring kodu. 60% czasu pochłonęło zrozumienie ukrytych zależności między modułami — które komponenty naprawdę zależą od siebie, jakie efekty uboczne wywołuje zmiana w jednym miejscu. Kod wygenerowany przez AI nie ma jawnej architektury i te powiązania trzeba odtwarzać na podstawie zachowania, a nie kodu. To praca, której nie da się zautomatyzować — wymaga doświadczenia i myślenia systemowego.

Rezultat: aplikacja działa stabilnie, zespół klienta może wprowadzać zmiany bez strachu, czas odpowiedzi API skrócił się 4-krotnie po dodaniu indeksów.

Jak naprawić zepsuty kod AI: plan krok po kroku

Nieważne, czy jesteś founderem wpatrującym się w zepsute MVP, czy programistą, któremu wciśnięto projekt z vibe codingu ze słowami „po prostu napraw” — oto systematyczne podejście do naprawy kodu wygenerowanego przez AI.

Krok 1: Triaż — co naprawdę działa?

Zanim dotkniesz kodu, zmapuj bieżący stan. Które funkcje działają poprawnie? Które — ze znanymi bugami? Które są kompletnie zepsute? Czy potrafisz niezawodnie wdrażać zmiany? Czy są aktywne podatności wymagające natychmiastowej łatki?

Każdy projekt zaczynamy od automatycznego skanowania: statyczna analiza kodu (ESLint z pluginami bezpieczeństwa, SonarQube), npm audit / pip audit dla zależności, sprawdzanie sekretów przez gitleaks. To daje obiektywny obraz w godzinę zamiast w cały dzień ręcznego przeglądania.

Triaż oddziela pilne poprawki od długoterminowych ulepszeń i zapobiega typowemu błędowi — rozpoczynaniu pełnego przepisania, gdy wystarczyłyby celowane naprawy.

Krok 2: Zamknąć perymetr bezpieczeństwa

Bezpieczeństwo — zawsze jako pierwsze. Zrotować wszystkie ujawnione klucze API. Dodać walidację danych wejściowych. Wdrożyć porządne uwierzytelnianie. Skonfigurować HTTPS. Każdy dzień, w którym niebezpieczna aplikacja działa na produkcji, to narastanie ryzyka prawnego i reputacyjnego — im dłużej czekasz, tym droższe będzie usuwanie skutków.

Krok 3: Ustawić monitoring przed zmianą kodu

Zainstaluj śledzenie błędów (Sentry, LogRocket lub podobne) i podstawową analitykę, zanim zaczniesz refaktorować. Musisz wiedzieć, co się psuje i jak często. Bez monitoringu naprawiasz na ślepo — i nie dowiesz się, czy zrobiłeś lepiej, czy gorzej.

Krok 4: Napisać testy dla krytycznych ścieżek

Wszystkiego naraz nie przetestujesz. Zidentyfikuj 3–5 najkrytyczniejszych scenariuszy użytkownika — rejestracja, płatność, główna funkcja — i napisz dla nich testy integracyjne. To da siatkę bezpieczeństwa: kiedy zaczniesz refaktorować, testy pokażą, jeśli coś się zepsuje.

Krok 5: Refaktorować inkrementalnie

Nie przepisuj wszystkiego naraz. Wynieś zduplikowaną logikę do współdzielonych serwisów. Skonsoliduj zarządzanie stanem. Wymieniaj jeden problematyczny moduł za drugim. Każda zmiana powinna być na tyle mała, żeby zweryfikować ją na testach z poprzedniego kroku.

Ratować czy przebudowywać: jak podjąć decyzję

Najdroższy błąd przy naprawianiu kodu AI — wybrać pełne przepisanie, gdy wystarczyło ratowanie. Albo odwrotnie — tygodniami łatać bazę kodu, która architektonicznie nie ma szans na przeżycie.

Ratowanie ma sens, gdy:

• Podstawowa architektura jest zdrowa — problemy leżą w implementacji, nie w fundamencie
• Aplikacja działa dla większości użytkowników przez większość czasu
• Stos technologiczny jest nowoczesny i odpowiedni do zadania
• Baza kodu ma zarządzalny rozmiar z umiarkowanym sprzężeniem modułów
• Aplikacja musi działać, podczas gdy trwają ulepszenia

Przebudowa ma sens, gdy:

• Fundamentalna architektura nie jest w stanie obsłużyć Twoich wymagań
• Problemy bezpieczeństwa są tak głębokie, że łatanie tworzy większe ryzyko niż nowy start
• Koszt zrozumienia istniejącego kodu przekracza koszt jego przepisania — to kluczowy wskaźnik
• Masz czas: przebudowa trwa zazwyczaj 2–4 miesiące

Jak to oceniamy? Nie po liczbie linii — 20 000 linii w React SPA i 20 000 linii w monolicie na Expressie to zupełnie inne sytuacje. Patrzymy na sprzężenie modułów, głębokość zależności, obecność wyraźnych punktów wejścia i złożoność cyklomatyczną krytycznych ścieżek. Jeśli zrozumienie modułu zabiera więcej czasu niż jego przepisanie — to sygnał.

Z naszego doświadczenia, około 70% projektów z vibe codingu da się uratować. Pozostałe 30% wymaga częściowej lub pełnej przebudowy — ale nawet wtedy logika biznesowa i badania użytkowników z oryginalnego prototypu mają ogromną wartość i są przenoszone do nowej architektury.

Dlaczego nie poprosić AI o naprawę własnego kodu?

To pierwsze pytanie każdego vibe codera. I jest logiczne — jeśli AI napisało kod, może go też naprawi?

Dla izolowanego buga — czasem to działa. Jeśli konkretna funkcja zwraca błędny wynik, AI całkiem może ją poprawić. Ale w przypadku problemów systemowych — tych, o których mówi ten artykuł — podejście „poproś AI jeszcze raz” najczęściej prowadzi do błędnego koła: poprawka psuje coś innego, poprawka tego psuje trzecią rzecz, a po czterech godzinach masz więcej problemów niż na początku.

Przyczyna jest prosta: narzędzia AI działają bez pamięci decyzji architektonicznych. Każdy prompt otrzymuje lokalnie optymalną odpowiedź, która może zaprzeczać poprzednim decyzjom. AI nie widzi systemu jako całości.

Profesjonalni programiści wnoszą właśnie to — odpowiedzialność architektoniczną. Widzą, dlaczego zmiana w module uwierzytelniania kaskadowo wpłynie na przepływ płatności. Stosują wzorce przetestowane w setkach projektów. I co ważne, najlepsze zespoły inżynierskie dziś aktywnie używają AI jako narzędzia — ale decyzje architektoniczne zostawiają ludziom.

Nie chodzi o to, że ludzie są „lepsi” od AI albo odwrotnie. Chodzi o odpowiedzialność. Ktoś musi odpowiadać za system jako całość — i na razie może to być tylko człowiek z myśleniem inżynierskim.

Nasze podejście do ratowania kodu AI

W Webappski od 2015 roku zajmujemy się code rescue — na długo przed tym, zanim AI zaczęło generować kod. Kiedyś trafiały do nas projekty po odejściu zespołów outsourcingowych, teraz — po vibe codingu. Wzorce chaosu są zadziwiająco podobne; różnica polega na szybkości, z jaką ten chaos się kumuluje.

Nie obiecujemy, że naprawa będzie szybka ani prosta. Projekty rescue to zawsze brud, kompromisy i niespodzianki. Czasem podczas audytu rekomendujemy całkowite wstrzymanie developmentu na 1–2 tygodnie — bo każdy nowy commit do niestabilnej bazy kodu zwiększa koszt naprawy. To nie jest to, co klienci chcą słyszeć, ale szczerość na starcie oszczędza miesiące na mecie.

Jak wygląda nasz proces:

1. Bezpłatny audyt diagnostyczny. Automatyczna analiza + ręczna weryfikacja krytycznych modułów. Na wyjściu — dokument z konkretną listą problemów, priorytetami i jasną rekomendacją: ratowanie, częściowa lub pełna przebudowa. Trwa 2–3 dni robocze. Bezpłatnie, bez zobowiązań.
2. Priorytetowa łatka bezpieczeństwa. Jeśli znajdziemy aktywne podatności — zamykamy je przed rozpoczęciem głównych prac.
3. Inkrementalna stabilizacja. Testy, monitoring, CI/CD. Aplikacja pozostaje online, podczas gdy ją ulepszamy. Typowy czas stabilizacji — 2–4 tygodnie dla projektów średniej wielkości.
4. Refaktoring architektoniczny. Przebudowujemy bazę kodu w utrzymywalne, udokumentowane moduły. Każda decyzja jest udokumentowana, każdy wzorzec wyjaśniony.
5. Transfer wiedzy. Nie tworzymy zależności od siebie. Po zakończeniu Twój zespół (lub przyszli deweloperzy) otrzymuje bazę kodu, z którą naprawdę można pracować, i dokumentację, która wyjaśnia dlaczego, a nie tylko co.

Pracujemy z React, Angular, Vue, Next.js, Node.js, Pythonem i innymi nowoczesnymi stosami. Konkretne narzędzie AI nie ma znaczenia — wzorce awarii są takie same dla Cursora, Copilota, ChatGPT, Claude i pozostałych.

Jak zapobiec następnemu załamaniu: najlepsze praktyki

Vibe coding to legitymny akcelerator developmentu przy prawidłowym użyciu. Klucz — traktować kod AI jako szkic, nie gotowy produkt.

• Sprawdzać każdy output AI. Czytaj kod, zanim go zaakceptujesz. Jeśli nie potrafisz zrozumieć, co robi — to sygnał ostrzegawczy, a nie powód, by kliknąć Accept.
• Wymagać testów. Proś AI o generowanie testów razem z funkcjami. Dodaj to do system promptu — sam z siebie tego nie zrobi.
• Kontrola wersji od pierwszego dnia. Commity w Git powinny być małe i opisowe. Jeśli coś się zepsuje — można cofnąć do działającego stanu.
• Ustalić reguły architektury z góry. Zdefiniuj strukturę folderów, podejście do zarządzania stanem i wzorce API przed pisaniem kodu. Przekaż te ograniczenia AI w system prompcie lub w .cursorrules.
• Zaplanować profesjonalne przeglądy. Nawet dwugodzinny przegląd kodu od doświadczonego programisty co dwa tygodnie potrafi wychwycić problemy, zanim urosnądo lawiny.
• Nie wdrażać bez audytu bezpieczeństwa. Przed każdym wdrożeniem na produkcję ktoś znający się na bezpieczeństwie powinien sprawdzić uwierzytelnianie, autoryzację i obsługę danych.

Podsumowanie: Twoja aplikacja z vibe codingu nie jest skazana

Kod może być chaotyczny, ale myślenie produktowe, scenariusze użytkowników i logika biznesowa za nim mają realną wartość. Z właściwym podejściem — systematyczny triaż, poprawki security-first, inkrementalny refaktoring — większość projektów AI da się przekształcić w stabilne, utrzymywalne oprogramowanie.

Najgorsze, co można zrobić — to nic nie robić. Podatności nie leczą się same, dług techniczny rośnie wykładniczo. Drugie najgorsze — prosić to samo AI o naprawienie własnych błędów w kółko.

Jeśli już podejrzewasz, że z aplikacją coś jest nie tak — najprawdopodobniej masz rację. Im wcześniej przeprowadzisz audyt, tym tańsza będzie naprawa.

Uzyskaj bezpłatny audyt diagnostyczny →
Co obejmuje: automatyczna analiza kodu + ręczna weryfikacja krytycznych modułów. Co otrzymasz: dokument z konkretną listą problemów, priorytetami i rekomendacją (ratowanie / częściowa / pełna przebudowa). Termin: 2–3 dni robocze. Koszt: bezpłatnie, bez zobowiązań.

FAQ: Naprawa zepsutego kodu AI

Czy mogę naprawić aplikację z vibe codingu, prosząc AI ponownie?

Dla izolowanych bugów — czasem tak. Dla problemów systemowych (architektura, bezpieczeństwo, skalowalność) — nie. AI nie ma pamięci architektonicznej: każdy prompt naprawczy może rozwiązać jeden problem, tworząc nowe. Kiedy zauważysz, że naprawiasz w kółko — to sygnał, by zwrócić się do inżyniera.

Ile kosztuje ratowanie projektu z vibe codingu?

Zależy od skali problemu. Łatka bezpieczeństwa i podstawowa stabilizacja to kwestia dni. Pełny refaktoring architektoniczny średniej aplikacji trwa zazwyczaj 2–6 tygodni. Zacznij od bezpłatnego audytu — pokaże zakres przed podjęciem decyzji.

Przepisywać od zera czy naprawiać?

Około 70% projektów da się uratować celowanym refaktoringiem — to szybsze i tańsze. Przepisanie od zera jest uzasadnione, gdy architektura fundamentalnie nie może obsłużyć Twoich wymagań. Profesjonalny audyt pokaże, która droga jest bardziej opłacalna.

Co jeśli nie mamy w ogóle dokumentacji?

To norma dla projektów z vibe codingu — przytłaczająca większość naszych klientów nie ma ani dokumentacji, ani README. Częścią naszego procesu jest inżynieria wsteczna bazy kodu i tworzenie dokumentacji od zera.

Co jeśli kod pisało kilka narzędzi AI jedno po drugim?

Widzimy to często: zaczęli w ChatGPT, kontynuowali w Cursorze, dokańczali w Copilocie. Każde narzędzie wniosło swoje wzorce i stylistykę. To komplikuje diagnostykę, ale nie zmienia podejścia — pracujemy z wynikiem, nie z historią jego powstawania.

Co jeśli projekt jest już na produkcji z realnymi użytkownikami?

To większość naszych klientów. Inkrementalna stabilizacja jest właśnie po to — aplikacja dalej działa, podczas gdy ją ulepszamy. Ani minuty przestoju.

Czy vibe coding to zawsze coś złego?

Nie. Vibe coding świetnie sprawdza się w szybkim prototypowaniu, walidacji pomysłów i narzędziach wewnętrznych o niskim ryzyku. Problemy pojawiają się, gdy prototyp trafia na produkcję jako gotowe oprogramowanie bez profesjonalnej weryfikacji. AI to akcelerator. Ale akcelerator bez kierownicy to nie innowacja, a wypadek.