Wyceniłeś stronę na 60 godzin, bo model zrobi połowę: gdzie uciekają godziny

Model generuje komponent formularza kontaktowego w cztery minuty. Przeczytanie go ze zrozumieniem, dopisanie walidacji po stronie serwera, obsługa błędu sieci i sprawdzenie, czy po zamknięciu komunikatu fokus wraca tam, gdzie był — czterdzieści. Jeśli wycena powstała z założenia „model zrobi połowę roboty, więc liczę połowę godzin”, to wyceniona została ta czterominutowa część.

Problem nie polega na tym, że modele nie pomagają. Polega na tym, że pomagają w fazie, którą łatwo zobaczyć, a obciążają fazę, której nikt nie mierzy. Wycena robiona „na oko” trafia w to pierwsze i pomija drugie — i dlatego projekt sprzedany na 60 godzin kończy się na 90, bez żadnego rozszerzenia zakresu ze strony klienta.

Godziny nie znikają, tylko zmieniają kategorię

Najciekawsze dane w tej sprawie nie mówią o tym, czy AI przyspiesza, tylko o rozjeździe między odczuciem a stoperem. W kontrolowanym badaniu METR z lipca 2025 szesnastu doświadczonych deweloperów open source wykonało 246 realnych zadań (średnio po dwie godziny) w repozytoriach, które sami utrzymują. Przed startem szacowali, że narzędzia AI przyspieszą ich o 24%. Po wykonaniu pracy nadal oceniali, że były szybsze o 20%. Pomiar pokazał, że z AI pracowali o 19% dłużej.

To badanie ma wąski zakres i autorzy sami to podkreślają: dotyczy ludzi, którzy znają na wylot bardzo duże repozytoria, i narzędzi z początku 2025 roku. Nie przenosi się wprost na budowę strony od zera, gdzie generowanie boilerplate’u faktycznie oszczędza czas. Przenosi się natomiast jedna rzecz, i to ta istotna przy wycenie: różnica między szacunkiem a wynikiem sięgała blisko czterdziestu punktów procentowych, i to u ludzi przekonanych, że mierzą własną pracę trafnie.

Kierunek potwierdza raport DORA z 2025 roku: 90% badanych specjalistów używa AI w pracy, ponad 80% odczuwa wzrost produktywności, a wyższa adopcja koreluje jednocześnie ze wzrostem przepustowości dostarczania i ze wzrostem niestabilności — większą liczbą nieudanych zmian i większą ilością przeróbek. Autorzy nazywają to podatkiem od weryfikacji: czas zaoszczędzony przy pisaniu wraca przy sprawdzaniu.

Skala tego podatku wychodzi w ankiecie. W badaniu Stack Overflow z 2025 roku (ponad 49 tysięcy respondentów ze 177 krajów) największą bolączką pracy z AI okazało się rozwiązanie „prawie dobre, ale nie do końca” — wskazało je 66% odpowiadających. Druga w kolejności: debugowanie kodu z modelu zajmuje więcej czasu, niż zakładali — 45%. Zaufanie do trafności wyników spadło do 33% z 43% rok wcześniej.

Trzy pozycje, których nie ma w typowej wycenie

Wyceniając stronę, zwykle rozpisuje się projekt, kodowanie szablonów, integrację CMS-a, testy i wdrożenie. Praca z modelem dokłada trzy pozycje, które nie mają własnej rubryki, więc rozpływają się w pozostałych.

Przegląd cudzego kodu, a nie własnego. Czytanie kodu, którego się nie napisało, jest wolniejsze od czytania własnego — nie znasz intencji, więc każdą linijkę weryfikujesz zamiast rozpoznawać. Wygenerowany komponent trzeba przejrzeć tak, jak przegląda się pull request od nowej osoby w zespole, bo dokładnie tym jest.

Drugi obieg po „prawie działa”. Kod, który się kompiluje, przechodzi testy i wygląda poprawnie, a rozjeżdża się na przypadku brzegowym, kosztuje więcej niż kod, który od razu nie działa. Ten drugi odpada w pierwszej minucie. Pierwszy odpada u klienta, po odbiorze, kiedy godziny są już rozliczone. Mechanizm jest ten sam co przy automatyzacji zadań biurowych, gdzie wynik trzeba przepuścić przez próg pewności dla pól krytycznych: warto z góry ustalić, które fragmenty zawsze idą pod ludzkie oko, zamiast decydować o tym za każdym razem od nowa.

Dług strukturalny, który zapłacisz przy zmianie. Firma GitClear przeanalizowała 623 miliony zmian w kodzie z lat 2023–2026 i opublikowała wyniki w raporcie The Maintainability Gap. Udział linii kopiowanych wzrósł z 9,4% w 2022 do 15,7% w pierwszej połowie 2026. Udział kodu przenoszonego, czyli refaktoryzowanego, spadł w tym samym czasie z 21% do 3,8%. Duplikaty bloków kodu wzrosły o 81%, wywołania funkcji między plikami spadły o 35%, a dwutygodniowy churn wzrósł o 15%. To są korelacje na dużej próbie, nie dowód przyczynowy — ale opisują dokładnie ten rodzaj kodu, który tanio powstaje i drogo się zmienia.

Ostatnia pozycja jest zdradliwa przy wycenie, bo jej koszt nie pojawia się w tym projekcie. Pojawia się przy kolejnym zleceniu od tego samego klienta, w abonamencie na utrzymanie albo w reklamacji.

Co model realnie skraca, a czego nie rusza

Zamiast jednego mnożnika na cały projekt bardziej opłaca się osobny współczynnik na fazę. Poniżej rozkład typowy dla projektu strony wizytówkowej lub prostego sklepu — traktuj go jako punkt wyjścia do własnego pomiaru, nie jako cennik.

Wniosek dla wyceny jest prosty: rabat udzielony od całości projektu, bo „AI pomaga”, jest rabatem udzielonym również od faz, na które AI nie ma wpływu albo je wydłuża.

Policz własny współczynnik zamiast przyjmować cudzy

Wszystkie liczby powyżej pochodzą z cudzych warunków pomiaru. Twoje będą inne i jedyny sposób, żeby je poznać, to zmierzyć u siebie przez dwa lub trzy projekty. Wystarczą dwa narzędzia.

Pierwsze to rozbicie czasu na kategorie w tym, czym już rejestrujesz godziny. Zamiast jednego wpisu „frontend 6 h” potrzebujesz czterech osobnych: generowanie i prompty, przegląd wygenerowanego kodu, poprawki po przeglądzie, praca pisana ręcznie. Po dwóch projektach zobaczysz stosunek dwóch środkowych kategorii do pierwszej. To jest Twój mnożnik i nie musi przypominać żadnego z badań.

Drugie to prosty odczyt z repozytorium: ile z tego, co dodałeś w ostatnim miesiącu, zdążyło już zostać usunięte lub przepisane. Wysoki wynik oznacza, że praca wchodzi do projektu i zaraz wychodzi, a każde takie kółko ktoś opłacił.

# Przybliżenie rework rate w oknie 30 dni
git log --since="30 days ago" --numstat --format="%h" -- '*.js' '*.ts' '*.tsx' '*.css' \
  | awk 'NF==3 {dodane+=$1; usuniete+=$2} END {
      printf "dodane: %d, usuniete: %d, rework: %.1f%%\n", dodane, usuniete, usuniete/dodane*100 }'

To jest przybliżenie, nie miara akademicka: liczy usunięcia razem z porządkami i przenoszeniem plików, więc pojedynczy odczyt nic nie znaczy. Sens ma dopiero porównanie tej samej liczby między projektem prowadzonym z modelem a projektem prowadzonym bez, albo trend na przestrzeni kilku miesięcy. Jeżeli chcesz odciąć zmiany kosmetyczne, dołóż -w i ogranicz ścieżki do katalogów z logiką.

Komponent, który wygląda na gotowy

Poniżej fragment w stylu, jaki dostaje się z modelu na prompt „formularz kontaktowy z walidacją”. Kod się uruchamia i przechodzi ręczny test, bo szczęśliwa ścieżka działa.

async function wyslij(e) {
  e.preventDefault();
  const dane = new FormData(e.target);
  if (!dane.get('email').includes('@')) {
    setBlad('Podaj poprawny adres e-mail');
    return;
  }
  const odp = await fetch('/api/kontakt', {
    method: 'POST',
    body: JSON.stringify(Object.fromEntries(dane)),
    headers: { 'Content-Type': 'application/json' }
  });
  setWyslane(true);
}

Rzeczy, które wyjdą dopiero w przeglądzie, a każda z nich to od kilkunastu minut do godziny:

• Walidacja istnieje tylko po stronie przeglądarki. Endpoint przyjmie dowolny ładunek wysłany poza formularzem.
• Odpowiedź serwera nie jest sprawdzana. Przy statusie 500 użytkownik zobaczy potwierdzenie wysyłki, a wiadomość nie dotrze — i nikt się o tym nie dowie.
• Brak obsługi wyjątku z fetch. Zerwane połączenie kończy się nieobsłużonym odrzuceniem obietnicy i zamrożonym przyciskiem.
• Brak blokady na czas wysyłki. Podwójne kliknięcie daje dwa zgłoszenia.
• Komunikat błędu nie jest powiązany z polem ani ogłaszany czytnikowi ekranu. Do zrobienia zostaje aria-describedby, aria-invalid i obszar z role="alert".
• Brak zabezpieczenia przed botami, więc po tygodniu skrzynka klienta zbiera spam i wraca reklamacja.

Żadna z tych poprawek nie jest trudna. Wszystkie razem to jednak realna praca, której w wycenie nie było, bo w wycenie był „formularz kontaktowy — 2 h”.

Co zapisać w wycenie i w umowie

Wycena chroni przed przekroczeniem budżetu wtedy, gdy nazywa pracę, która faktycznie się wydarzy. Kilka zapisów, które to załatwiają:

• Przegląd i utwardzenie kodu jako osobna pozycja. Nie „testy”, tylko wprost przegląd wygenerowanego kodu z listą tego, co obejmuje. Klient wtedy widzi, za co płaci, a Ty masz na co wskazać przy negocjacji.
• Kryteria odbioru w liczbach, nie w przymiotnikach. Zamiast „strona ma być szybka” — próg dla LCP i CLS mierzony konkretnym narzędziem, na konkretnym urządzeniu i łączu. Zamiast „zgodna z WCAG” — poziom AA na wskazanej liście widoków. Działa tu ta sama zasada co przy przekazywaniu zadania w zespole: praca wraca do poprawki najczęściej dlatego, że warunek ukończenia nie został spisany przed startem.
• Widełki zamiast jednej liczby przy nowej technologii. Jeżeli stack jest nowy dla zespołu, podaj zakres i warunek, który przesuwa wycenę do górnej granicy.
• Oddzielenie stawki od czasu tam, gdzie się da. Wycena za efekt, a nie za godziny, przenosi zysk z przyspieszenia na Twoją stronę zamiast oddawać go w rabacie.
• Zapis o poprawkach po odbiorze. Liczba obiegów wliczona w cenę i stawka za kolejne. Kod „prawie dobry” generuje właśnie takie obiegi.

Osobna sprawa to obietnice składane w rozmowie. Zdanie „robimy z AI, więc będzie szybciej i taniej” brzmi jak przewaga, a ustawia oczekiwanie, którego nie kontrolujesz — i przy pierwszym poślizgu staje się argumentem klienta przeciwko Tobie. Bezpieczniej mówić o tym, co się nie zmienia: odpowiedzialności za wynik, terminie i tym, że kod przed oddaniem przechodzi przegląd.

Zanim wyślesz następną wycenę

• Sprawdź, czy przegląd wygenerowanego kodu ma w niej własną pozycję i własne godziny.
• Sprawdź, czy rabat „bo AI” nie objął faz, na które model nie ma wpływu — ustaleń, integracji z danymi klienta, wdrożenia.
• Sprawdź, czy kryteria odbioru dotyczące wydajności i dostępności są zapisane jako wartości do zmierzenia.
• Sprawdź, czy w ostatnich dwóch projektach masz rozbicie godzin na generowanie, przegląd i poprawki. Jeśli nie — wprowadź je od najbliższego, bo bez tego kolejna wycena znów będzie zgadywaniem.
• Sprawdź, ile obiegów poprawek po odbiorze mieści się w cenie i co się dzieje po ich wyczerpaniu.

Jedna decyzja do podjęcia po tym tekście: na najbliższym projekcie rozbij ewidencję czasu na cztery kategorie i po odbiorze policz, jaką część godzin zjadł przegląd i poprawki. Dopiero ta liczba — Twoja, nie z raportu — mówi, o ile możesz zejść z wyceny, nie dokładając do zlecenia z własnej kieszeni.