W listopadzie 2025 roku Collins Dictionary ogłosił „vibe coding” słowem roku i zdefiniował je jako używanie AI, sterowanego językiem naturalnym, do pomocy w pisaniu kodu. Określenie się przyjęło, bo to doświadczenie jest prawdziwe. Opisuje się aplikację, akceptuje to, co napisze model, i w niedzielę wieczorem jest działający ekran. Założyciel może dziś pokazać demo klientom, zanim zatrudni inżyniera.
Tańsza nie stała się ta część, która sprawia, że oprogramowanie jest niezawodne. W Stack Overflow Developer Survey 2025 66% programistów wskazało „rozwiązania AI, które są prawie dobre, ale jednak nie” jako główną frustrację związaną z narzędziami AI, a 45% stwierdziło, że debugowanie kodu wygenerowanego przez AI zajmuje więcej czasu. Prototyp to miejsce, w którym „prawie dobrze” wystarcza. Produkcja to miejsce, w którym nie wystarcza.
Ta notatka wylicza, co produkcja dodaje do prototypu, podaje przybliżony podział nakładu pracy i podpowiada, jak osoba odpowiedzialna za budżet powinna traktować demo, które właśnie zobaczyła.
Przyspieszenie jest realne i wciąż niezmierzone
Najstaranniejszy pomiar szybkości kodowania z AI pochodzi od METR, organizacji badawczej non-profit. Jej randomizowane badanie z 2025 roku wykazało, że doświadczeni programiści open source potrzebowali na zadania o 19% więcej czasu, gdy AI było dozwolone, z przedziałem ufności od +2% do +39%.
24 lutego 2026 roku METR opublikował badanie uzupełniające: 57 programistów, 143 repozytoria, ponad 800 zadań, prowadzone od sierpnia 2025 roku. Na tej samej skali zmiany czasu, na której wynik z 2025 roku wynosił +19%, nowe estymacje punktowe to -18% dla programistów powracających z pierwszego badania (przedział od -38% do +9%) oraz -4% dla nowo zrekrutowanych programistów (przedział od -15% do +9%). Obie estymacje punktowe wskazują teraz, że AI oszczędza czas. Oba przedziały obejmują zero.
Sam METR nazywa nowe dane niewiarygodnym sygnałem. Od 30% do 50% programistów przyznało, że zdecydowało się nie zgłaszać części zadań, bo nie chcieli wykonywać ich bez AI. Zadania, w których AI pomaga najbardziej, wypadły więc z próby, a METR uważa, że rzeczywiste przyspieszenie jest prawdopodobnie większe niż jego estymacja.
Dla kupującego wniosek jest wąski. AI przyspiesza część kodowania o wartość, której staranni badacze nie zdołali precyzyjnie ustalić. Nie zmienia tego, czego system potrzebuje, zanim ludzie będą mogli na nim polegać.
Czego prototyp dowodzi, a czego nie
Weekendowy prototyp dowodzi trzech przydatnych rzeczy: pomysł działa na danych, które ktoś wypróbował, interfejs jest zrozumiały dla osób, które go widziały, i ktoś tego chce.
Nie dowodzi, że system działa na danych, których nikt nie wypróbował, że działa dla dwustu osób jednocześnie, że każdej osobie pokazuje tylko to, co wolno jej zobaczyć, że kosztuje miesięcznie tyle, ile się wydaje, ani że ktokolwiek potrafi go naprawić, gdy zepsuje się w nocy. Na te pytania odpowiada produkcja.
Jest też druga różnica, którą łatwo przeoczyć. Prototyp ocenia osoba, która go zbudowała, w dniu, w którym go zbudowała, na danych, które sama wybrała. System produkcyjny oceniają ludzie, którzy nigdy nie widzieli dema, miesiące później, na danych, które nie istniały, gdy pisano kod. Większość pracy z następnej tabeli istnieje po to, żeby ta druga ocena wypadła dobrze.
Co dodaje produkcja
Poniższe udziały to poglądowy podział dla wewnętrznego narzędzia LLM, na przykład copilota do przeszukiwania dokumentów, przechodzącego od działającego prototypu do kilkuset użytkowników dziennie. To opinie planistyczne, a nie pomiary. Wagi warto dopasować do własnego przypadku; liczy się kształt.
| Element pracy | Co oznacza | Bez niego | Udział poglądowy |
|---|---|---|---|
| Logika główna | To, co prototyp już pokazuje | Nie ma produktu | 20% |
| Kontrakty danych i potoki | Kontrola schematu każdego źródła danych; harmonogramowane, idempotentne ładowania | Eksport po stronie źródła się zmienia, a odpowiedzi pogarszają się bez żadnego błędu | 15% |
| Zbiór ewaluacyjny i bramki jakości | Prawdziwe pytania z oczekiwanymi odpowiedziami, uruchamiane przy każdej zmianie promptu lub modelu | Nikt nie wie, czy zmiana coś poprawiła, czy pogorszyła | 12% |
| Uwierzytelnianie i uprawnienia | Single sign-on; reguły dostępu egzekwowane w momencie wyszukiwania | Pracownicy widzą dokumenty, których nie powinni | 8% |
| Walidacja wejścia i obsługa błędów | Limity rozmiaru i formatu; obsługa wrogiego tekstu w przesłanych i wyszukanych dokumentach | Jeden nietypowy plik kładzie usługę albo steruje modelem | 8% |
| Monitoring i alerty | Opóźnienie, odsetek błędów, koszt na zapytanie, odsetek pustych wyszukiwań, opinie użytkowników | O problemach informują użytkownicy, kilka dni później | 8% |
| Przegląd bezpieczeństwa i poprawki | Sekrety, zależności, dane wysyłane do zewnętrznych API | Wyciek klucza albo naruszenie zasad przetwarzania danych | 8% |
| Dyżury i runbooki | Wskazany właściciel i spisane kroki dla typowych awarii | Jedyna osoba, która wie, jest na urlopie | 7% |
| Rollback i proces wydań | Wersjonowane prompty, modele i indeksy; przełącznik do ostatniej dobrej wersji | Złe wydanie działa dalej, dopóki ktoś go debuguje | 5% |
| Dokumentacja i przekazanie | Jak to działa, jak to zmienić, jak to uruchomić | System nie przetrwa odejścia autora | 5% |
| Limity kosztów | Kwoty na użytkownika, limity tokenów, bezpiecznik wydatków | Pętla albo intensywny użytkownik generuje niespodziewaną fakturę | 4% |
Pierwszy wiersz to prototyp. W tym podziale to jedna piąta pracy. Pozostałe cztery piąte są w demie niewidoczne i dlatego demo jest tak słabą wskazówką do budżetu.
Dla inżynierów: na co idzie czas
Kilka wierszy zasługuje na więcej szczegółów, bo to w nich zwykle mylą się wyceny.
Uprawnienia należą do wyszukiwania, a nie do odpowiedzi. W systemie retrieval-augmented kontrola dostępu musi filtrować dokumenty, zanim trafią do modelu. Filtrowanie po wygenerowaniu nie działa: model już przeczytał tekst objęty ograniczeniem i może go sparafrazować. To oznacza, że indeks przechowuje metadane dostępu, pozostaje zsynchronizowany z systemem źródłowym, a ktoś testuje go na kontach z różnymi uprawnieniami.
Zbiór ewaluacyjny to specyfikacja w wykonywalnej postaci. To wersjonowany plik z prawdziwymi danymi wejściowymi i oczekiwanymi wynikami lub regułami oceny, uruchamiany w CI przy każdej zmianie promptów, modeli, chunkingu albo ustawień wyszukiwania. Zbudowanie go oznacza usiąść z ludźmi, którzy będą używać systemu, i spisać, czym jest poprawna odpowiedź. To powolne i żaden asystent tego nie zrobi, bo ta wiedza jest u użytkowników.
Walidacja wejścia obejmuje dziś tekst, który atakuje model. Dokument w indeksie może zawierać instrukcje. Przesłane pliki mogą być ogromne, puste, być skanami albo mieć złe kodowanie. Każdy przypadek wymaga określonego zachowania i testu.
Rollback wymaga wersjonowania wszystkiego razem. Wydanie to prompt, wersja modelu, build indeksu i kod. Jeśli w git jest tylko kod, cofnięcie kodu nie cofa zachowania.
Limity kosztów to funkcja produkcyjna. Prototyp ma jednego użytkownika. System produkcyjny ma ich kilkuset, do tego skrypty i ponowienia. Kwoty na użytkownika, maksymalna liczba tokenów i alert o dziennych wydatkach są tanie w budowie i zapobiegają najczęstszej nieprzyjemnej niespodziance.
Jak traktować prototyp, jeśli odpowiada się za budżet
Traktować go jako specyfikację. Działający prototyp to najjaśniejszy opis tego, czego się chce, jaki większość projektów kiedykolwiek dostaje. Warto przekazać go inżynierom razem z listą danych, na których był testowany, i przypadków, w których zawiódł.
Nie traktować go jako 80% produktu. Jeśli wycena jest niska, bo prototyp istnieje, warto zapytać, które z powyższych wierszy obejmuje. Jeśli odpowiedź brzmi „tylko pierwszy”, to jest wycena drugiego prototypu.
Użyć go do sprawdzenia popytu, zanim sfinansuje się produkcję. Warto dać go docelowym użytkownikom na dwa tygodnie. Jeśli do niego nie wracają, zaoszczędzono budżet produkcyjny, a to najbardziej przydatna rzecz, jaką prototyp może zrobić.
Kiedy wyrzucić prototyp
Lepiej przepisać, niż rozbudowywać, gdy spełniony jest co najmniej jeden z warunków:
- sekrety są w kodzie albo w historii repozytorium;
- dostęp do danych odbywa się przez czyjeś prywatne konto albo prywatny klucz API;
- interfejs, logika i dostęp do danych są ze sobą wymieszane, więc uprawnień nie da się egzekwować w jednym miejscu;
- nikt nie potrafi wyjaśnić, jak powstała konkretna odpowiedź;
- działa na hostowanym kreatorze, którego nie da się wdrożyć w Państwa środowisku ani dostosować do Państwa zasad dotyczących danych;
- logika jest długa i nie ma testów.
Warto go zachować, gdy logika główna jest krótka, czytelna i dająca się wydzielić, istnieje już kilka testów, a przepływ danych przypomina produkcyjny.
Wyrzucenie kodu kosztuje mniej, niż się wydaje. Prototyp już spełnił swoje zadanie: decyzje są podjęte, przykłady zebrane, interfejs wypróbowany. Prompty, przykładowe dane wejściowe i zrzuty ekranu zwykle przetrwają przepisanie, nawet jeśli kod nie przetrwa.
Jak ta luka wygląda w pieniądzach
Nasze własne opublikowane przedziały cenowe pokazują tę samą proporcję. Proof of concept to 14k–38k € w ciągu 4–7 tygodni. Budowa produkcyjna to 45k–120k € w ciągu 10–20 tygodni. Na obu krańcach przedziału produkcja kosztuje około trzech razy więcej niż proof of concept: 45 / 14 ≈ 3,2 oraz 120 / 38 ≈ 3,2. Ta wielokrotność to koszt wszystkich wierszy powyżej poza pierwszym. Z tego samego powodu dostarczamy monitoring i rollback przed przekazaniem: to one pozwalają klientowi utrzymywać system bez nas.
Jeśli mają Państwo już prototyp i chcą wiedzieć, które wiersze obejmuje, bezpłatny teardown to pierwsza kontrola w sześciu pytaniach, a krótkie płatne discovery odpowiada na to w pełni. Ta sama lista dotyczy wewnętrznych copilotów do dokumentów, gdzie najwięcej czasu zajmują zwykle uprawnienia i zbiór ewaluacyjny.
Źródła
- CNN, 'Vibe coding' named Collins Dictionary's Word of the Year, listopad 2025 — https://www.cnn.com/2025/11/06/tech/vibe-coding-collins-word-year-scli-intl
- Stack Overflow, 2025 Developer Survey: AI, lipiec 2025 — https://survey.stackoverflow.co/2025/ai
- METR, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity, lipiec 2025 — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- METR, We are Changing our Developer Productivity Experiment Design, luty 2026 — https://metr.org/blog/2026-02-24-uplift-update/