Przejdź do treści
SwankyForge
SwankyForge
Wszystkie insights
Artykuł9 min czytania

AI obniżyło koszt pisania kodu. Nie obniżyło samo z siebie kosztu projektów programistycznych.

Kontrolowane pomiary pokazują umiarkowane albo ujemne przyspieszenie dzięki narzędziom AI do kodowania, a samo kodowanie to mniejszość czasu projektu, więc uczciwy rabat za AI jest niewielki i da się go przypisać do konkretnych faz.

W lipcu 2025 roku organizacja badawcza non-profit METR opublikowała randomizowane badanie narzędzi AI do kodowania na prawdziwej pracy. Szesnastu doświadczonych programistów open source wykonało 246 zadań we własnych repozytoriach, a każde zadanie losowo przypisano do grupy „AI dozwolone” albo „AI niedozwolone”. Z AI zadania trwały o 19% dłużej. Przed badaniem ci sami programiści spodziewali się, że AI przyspieszy ich o 24%. Po badaniu nadal uważali, że byli dzięki niemu o około 20% szybsi.

Ta rozbieżność między odczuwaną a zmierzoną szybkością jest najbardziej przydatna dla każdego, kto kupuje oprogramowanie. Wykonawcy reklamują dziś dostarczanie przyspieszone przez AI i uwzględniają to w cenie. Część oszczędności jest prawdziwa. Większość tej obietnicy dotyczy jednak pisania kodu i zostaje przyłożona do budżetu, który w większości nie jest pisaniem kodu.

Ta notatka omawia, co mówią dane z 2025 roku, na co idą godziny w projekcie machine learning i o co zapytać wykonawcę, który proponuje rabat za AI.

Co mówią dane z 2025 roku

Cztery źródła, cztery metody. Żadne z nich nie potwierdza tezy, że projekt kosztuje o połowę mniej, bo kod napisano z asystentem.

Źródło Metoda Wynik
METR, lipiec 2025 Badanie randomizowane: 16 programistów, 246 zadań, repozytoria ze średnio 22k+ gwiazdek i 1M+ linii kodu Z AI o 19% wolniej; programiści uważali, że byli o około 20% szybsi
Stack Overflow Developer Survey, lipiec 2025 Ankieta, 26k–34k odpowiedzi na pytanie 84% używa narzędzi AI lub planuje ich używać; 46% nie ufa ich trafności, 33% ufa; 66% jako główną frustrację wskazuje „prawie dobrze, ale jednak nie”
Google DORA report, wrzesień 2025 Ankieta wśród prawie 5 000 specjalistów technologicznych 90% używa AI w pracy; wdrożenie AI wiąże się z wyższą przepustowością dostarczania, a jednocześnie z niższą stabilnością dostarczania
Bain Technology Report, wrzesień 2025 Badanie branżowe Zespoły z asystentami zyskują 10–15% produktywności; pisanie i testowanie kodu to 25–35% czasu od pomysłu do wdrożenia

Wynik METR ma ograniczenia, które autorzy wprost podają: mała próba, doświadczeni programiści pracujący na dużych, znanych im już bazach kodu oraz narzędzia z początku 2025 roku (Cursor Pro z Claude 3.5 i 3.7 Sonnet). Badanie nie dowodzi, że AI spowalnia wszystkich. Pokazuje dwie węższe rzeczy. Deklarowane przyspieszenie nie jest dowodem. A przy dojrzałym, złożonym kodzie czas poświęcony na pisanie promptów, czekanie, przeglądanie i poprawianie może zniwelować czas zaoszczędzony na pisaniu.

Ankiety wskazują w tę samą stronę z innej perspektywy. Używanie AI to rutyna: 51% zawodowych programistów w ankiecie Stack Overflow korzysta z narzędzi AI codziennie, a respondenci DORA spędzają z nimi medianowo dwie godziny dziennie. Zaufanie rutyną nie jest: 45% respondentów Stack Overflow twierdzi, że debugowanie kodu wygenerowanego przez AI zajmuje więcej czasu, a 30% respondentów DORA deklaruje niewielkie zaufanie do kodu wygenerowanego przez AI albo jego brak. Podsumowanie DORA brzmi: AI wzmacnia to, czym zespół już jest. Mocne zespoły przyspieszają. Zespoły ze słabymi testami i wolną informacją zwrotną wypuszczają więcej zmian i więcej z nich psują.

Dlaczego tańsze pisanie kodu nie oznacza tańszego projektu

Dwie liczby Bain wystarczą, żeby zobaczyć sufit. Jeśli pisanie i testowanie kodu to 30% czasu od pomysłu do wdrożenia, a asystent przyspiesza tę część o 30%, cały projekt przyspiesza o 9%: 0,30 × 0,30 = 0,09. Nawet gdyby kod stał się darmowy i natychmiastowy, pozostałe 65–75% pracy nadal by zostało. Inżynierowie znają to jako prawo Amdahla: przyspieszenie jednego etapu potoku jest ograniczone udziałem czasu, jaki ten etap zajmuje.

Reszta projektu to specyfikacja, praca z danymi, integracja, code review, testy, ewaluacja, wdrożenie i utrzymanie. Każdy z tych elementów ma własny powód, by nie kurczyć się w tym samym tempie.

  • Specyfikacja to rozmowa z ludźmi, do których należy problem. Asystent może przygotować szkic dokumentu. Nie zdecyduje, że metryką jest marża, a nie przychód.
  • Praca z danymi polega głównie na ustaleniu, co oznacza dana kolumna, kto jest właścicielem tabeli i dlaczego część wierszy się powtarza. Pisanie SQL nigdy nie było wolną częścią.
  • Integracja pochłania czas na API innego zespołu, dostępy, limity zapytań i okna wydań.
  • Code review staje się cięższe. Więcej wygenerowanego kodu dziennie oznacza więcej kodu do przeczytania dziennie, a kod, który jest prawie dobry, jest najdroższy w przeglądzie, bo wygląda na skończony.
  • Ewaluacja i utrzymanie biegną według kalendarza. Czeka się na tydzień ruchu, zamknięcie miesiąca albo na to, aż grupa kontrolna zbierze wystarczająco dużo danych.

Wynik DORA dotyczący stabilności to zmierzona wersja argumentu o code review. Zespoły wypuszczają więcej zmian, a bez solidnych testów automatycznych i szybkiej informacji zwrotnej więcej z tych zmian kończy się awarią.

Na co idą godziny w projekcie ML

Poniższa tabela jest poglądowa. To nasz przybliżony podział dla średniej wielkości projektu machine learning, na przykład systemu rekomendacji lub prognozowania podłączonego do istniejącego produktu, razem z naszymi założeniami co do tego, ile asystent AI oszczędza w każdej fazie. Procenty to opinie planistyczne, a nie pomiary. Warto podstawić własne i przeliczyć sumę.

Faza Udział godzin Godziny z 600 Zakładana oszczędność dzięki AI Zaoszczędzone godziny
Discovery: metryka, baseline, specyfikacja 10% 60 0% 0
Dostęp do danych, czyszczenie, potoki cech 25% 150 15% 22,5
Modelowanie i eksperymenty 15% 90 20% 18
Integracja z Państwa systemami 15% 90 20% 18
Testy, ewaluacja, code review 15% 90 0% 0
Wdrożenie, monitoring, rollback 10% 60 10% 6
Dema, odbiór, przekazanie 10% 60 0% 0
Razem 100% 600 64,5, czyli około 11%

Uzasadnienie każdego wiersza:

  • Discovery nie zyskuje nic, bo jego wynikiem są decyzje, a decyzje podejmuje biznes.
  • Praca z danymi zyskuje umiarkowanie. Asystenci szybko piszą zapytania, parsery i walidacje, ale większość godzin idzie na czekanie na dostęp i zrozumienie danych.
  • Modelowanie i integracja zyskują najwięcej, bo zawierają najwięcej kodu według wzorca: pętle treningowe, klienty API, serializację, konfigurację.
  • Testy i code review wychodzą na zero. Asystenci szybko piszą szkielety testów, a dodatkowy wygenerowany kod wydłuża przegląd. Zespoły z mocnymi zestawami testów mogą tu zyskać, zespoły bez nich mogą stracić.
  • Wdrożenie oszczędza trochę na szablonach konfiguracji. Czekanie, aż wydanie canary zbierze ruch, nie robi się krótsze.

Przy naszej opublikowanej stawce ML engineera 50 € za godzinę 600 godzin to 30 000 €, a 64,5 godziny to około 3 200 €. Taki jest rząd wielkości uczciwego rabatu za AI w projekcie o takim kształcie: realny, wart uwzględnienia i daleki od połowy. Mieści się też w przedziale 10–15% podanym przez Bain, co jest kontrolą sensowności, a nie dowodem.

Ciekawsza jest druga liczba Bain. Firmy, które przeprojektowały cały proces pod AI, zamiast tylko rozdać asystentów, raportowały zyski rzędu 25–30%. Ta oszczędność bierze się ze zmiany tego, co dzieje się pomiędzy liniami kodu: jak pisze się specyfikacje, jak działa code review, jak testuje się wydania. To zmiana procesu i wymaga wysiłku, zanim się zwróci. Bain zauważa też, że trzy na cztery firmy uznają skłonienie ludzi do zmiany sposobu pracy za najtrudniejszą część.

Jak zmieniła się praca programisty

Praca przesunęła się z pisania na specyfikowanie i sprawdzanie. Programista z asystentem spędza mniej czasu nad pierwszą wersją, a więcej nad trzema rzeczami.

  1. Precyzyjne instrukcje. Asystent robi to, co mówi specyfikacja, więc niejasna specyfikacja daje teraz szybciej wiarygodnie wyglądający, błędny kod.
  2. Czytanie i poprawianie wyniku. Tu mieszka frustracja „prawie dobrze”. Błędny kod, który głośno się wywraca, jest tani. Kod, który przechodzi oczywisty test i zawodzi w przypadku brzegowym, jest drogi.
  3. Kontrole, które sprawiają, że szybkość jest bezpieczna. Testy, zbiory ewaluacyjne, sprawdzanie typów, stopniowe wdrożenia.

W pracy z machine learning to trzeci punkt waży najwięcej. Zmiana modelu, która w notebooku wygląda dobrze, może na produkcji obniżyć metrykę biznesową. Asystent może napisać harness do ewaluacji. Nie zdecyduje, co powinien zawierać zbiór ewaluacyjny ani ile biznes kosztuje regresja.

Gdzie widać oszczędności

Nasze zdanie, które jest opinią, a nie pomiarem: asystenci realnie skracają czas przy

  • prototypach i jednorazowych analizach, gdzie „prawie dobrze” wystarcza, żeby się czegoś dowiedzieć;
  • kodzie o wyraźnym wzorcu: klientach API, klasach danych, konfiguracji, migracjach schematu;
  • nieznanych bibliotekach, gdzie asystent zastępuje godzinę czytania dokumentacji;
  • pierwszych wersjach testów i dokumentacji, które potem poprawia człowiek.

Niewiele oszczędzają na decyzjach, czekaniu, koordynacji i code review. Wiarygodny rabat za AI powinien być zgodny z tym podziałem.

O co zapytać wykonawcę, który obiecuje rabat za AI

  • Gdzie dokładnie AI skróciło godziny? Warto poprosić o wycenę w rozbiciu na fazy, z asystentem i bez niego. Rabat, którego nie da się przypisać do fazy, to rabat handlowy. To nic złego, ale powinien być tak nazwany.
  • Kto przegląda kod napisany przez AI i jak? Warto zapytać, czy człowiek przegląda każdą zmianę, co sprawdza i czy czas przeglądu jest w wycenie.
  • Jak mierzy się jakość? Testy na ścieżkach krytycznych, zbiór ewaluacyjny dla zachowania modelu, wskaźnik nieudanych zmian. Jeśli odpowiedź brzmi, że kod działa, warto zapytać, skąd to wiadomo.
  • Co się dzieje, gdy wygenerowany kod okaże się błędny na produkcji? Monitoring, rollback i osoba dyżurna odpowiedzialna za system należą do planu, a nie do późniejszego zlecenia zmiany.
  • Gdzie znajduje się repozytorium? Jeśli kod leży na koncie wykonawcy aż do faktury końcowej, nie da się sprawdzić niczego z powyższych wtedy, kiedy to jeszcze ma znaczenie.

Jak robimy to my

Nasz cennik jest opublikowany według ról i w stawkach godzinowych, więc każdą naszą wycenę można sprawdzić jako godziny razy stawka, faza po fazie. Co tydzień widzą Państwo działające demo, repozytorium od pierwszego dnia znajduje się w Państwa organizacji, a każdy kamień milowy fakturujemy dopiero po jego odbiorze. Typowe przedziały cen projektów są opublikowane obok cennika, a teardown wycenia osobno discovery, proof of concept i produkcję. Jeśli asystent AI przyspiesza którąś fazę, widać to jako mniej godzin na fakturze, a nie jako obietnicę w ofercie.

Źródła

Mają Państwo proces, który kosztuje za dużo?

Proszę nam o nim opowiedzieć. Pierwsza rozmowa jest bezpłatna, a jeśli AI nie jest odpowiedzią, powiemy to wprost.

Omów zadanie