Ile naprawdę oszczędza AI w developmencie? Jak uczciwie liczyć czas i koszt

AI
Marcin Różański
Latest posts by Marcin Różański (see all)

Oszczędność czasu z AI w wytwarzaniu oprogramowania to różnica między pracą wykonaną z agentem AI a tą samą pracą bez niego, liczona dla całego procesu, a nie dla jednego etapu. W naszym pomiarze dodanie pola NIP z walidacją do SuiteCRM zajęło deweloperowi około 21 minut zamiast szacowanych 3 godzin. Cały proces trwał jednak 104 minuty, a ta proporcja nie przenosi się liniowo na złożone zadania.

Ile czasu zajęło dodanie jednego pola z pomocą agenta AI?

Dodanie pola NIP z walidacją formatu i sumy kontrolnej do modułu kontrahentów w SuiteCRM zajęło łącznie 104 minuty. W tym czasie czas aktywnej pracy dewelopera z agentem AI wyniósł około 21 minut. Resztę wykonał orkiestrator: proces, który w eVolpe prowadzi user story od numeru zgłoszenia w Redmine do instancji testowej. Orkiestrator planuje implementację, generuje scenariusze testów, pisze kod, uruchamia testy i przekazuje zadanie do code review.

W tym konkretnym zadaniu agent AI wygenerował scenariusze testowe i zautomatyzował 14 z 16 z nich. Uruchomił 35 testów, a w ramach samodzielnego code review znalazł i poprawił jeden błąd. Dwa obszary świadomie zostały dla człowieka: import rekordów kontrahentów oraz polskie etykiety pola, bo instancja testowa nie miała zainstalowanej polskiej paczki językowej. Raport z procesu pokazał te luki wprost, więc tester wiedział, co sprawdzić ręcznie.

ai w developmencie

Dlaczego 104 minuty i 21 minut to dwie różne miary?

104 minuty to czas przejścia zadania przez cały proces, a 21 minut to czas pracy człowieka nad tym zadaniem. Pierwsza liczba odpowiada na pytanie, kiedy zmiana będzie gotowa. Druga mówi, ile godzin specjalisty zostało zużytych. Obie są potrzebne, ale nie wolno ich mieszać. Kierownik projektu planuje terminy na podstawie czasu przejścia, a kontroler finansowy liczy koszt na podstawie czasu pracy ludzi i kosztu modelu AI.

Pułapką jest perspektywa pojedynczego etapu. Deweloper, który oddał kod do code review, ma poczucie, że zadanie jest skończone. Michał Nowacki, który przeprowadził pomiar, przyznał, że pierwsza reakcja na 104 minuty brzmiała „tak długo na jedno pole?”. Dopiero po doliczeniu czasu recenzenta kodu i testera wynik okazał się spójny. Kto mierzy wyłącznie własny etap, przenosi koszt na kolejne osoby w procesie i raportuje oszczędność, której organizacja nie widzi.

Na czym polega błąd porównania „21 minut zamiast 3 godzin”?

Porównanie 21 minut z 3 godzinami zestawia zmierzoną wartość z wartością szacowaną, więc nie jest pomiarem oszczędności. Trzy godziny to wycena „po staremu” zrobiona po fakcie, uwzględniająca obliczanie sumy kontrolnej NIP i pytanie o numery zagraniczne. Same 21 minut są przybliżeniem: liczyliśmy czas od pytania agenta do odpowiedzi człowieka, bo nie ma narzędzia, które mierzy to automatycznie. Do tego zadanie było proste i dobrze nadawało się do prezentacji.

Rozbieżność między odczuciem a pomiarem jest dobrze udokumentowana. W randomizowanym badaniu METR 16 doświadczonych programistów rozwiązało 246 rzeczywistych zadań. Przed badaniem przewidywali przyspieszenie o 24%, po badaniu oceniali je na 20%, a zmierzony czas wykonania wzrósł o 19% (METR, 2025). W 2026 roku METR zmienił metodologię, bo coraz więcej programistów odmawiało pracy bez AI w grupie kontrolnej, a pomiar czasu przestał być wiarygodny przy pracy z kilkoma agentami jednocześnie (METR, 2026).

ai w developmencie

Dlaczego oszczędność z AI nie rośnie liniowo ze złożonością zadania?

Oszczędność z AI maleje wraz ze złożonością zadania, bo rośnie liczba decyzji, które musi zatwierdzić lub poprawić człowiek. W naszym procesie około połowy decyzji podejmowanych przez agenta AI na etapie planowania wymaga korekty. Przy prostym polu oznacza to kilka krótkich odpowiedzi. Przy nowym mechanizmie lub integracji z ERP plan jest dłuższy, pytań jest więcej, a każda błędna decyzja przechodzi przez kolejne pętle poprawek.

Drugim ograniczeniem są testy automatyczne dla procesów wieloetapowych. W systemie HCM, takim jak MintHCM, przetestowanie nowego kroku zwalniania pracownika wymaga najpierw przeprowadzenia go przez zatrudnienie, czyli kilkunastu minut przeklikiwania w przeglądarce. Agent AI musi mieć skille, które opisują takie ścieżki dla konkretnego systemu. Na razie orkiestrator działa produkcyjnie na SuiteCRM, a dla MintHCM jest w końcowej weryfikacji. Kolejne w kolejce są Creatio i SpiceCRM.

W których momentach procesu z AI człowiek nadal zużywa czas?

Człowiek zużywa czas w tak zwanych bramkach, czyli w momentach, w których zatwierdza lub koryguje kierunek pracy agenta AI. W orkiestratorze eVolpe są to: akceptacja planu implementacji, weryfikacja działania na instancji, ocena raportu z automatycznego code review i akceptacja testera. Agent może też zadać pytanie w dowolnym momencie, gdy natrafi na decyzję, której nie przewidział plan. Bramki są kosztem, ale bez nich koszt błędów byłby wyższy.

Przykład z praktyki: agent AI miał dostęp do instancji MintHCM przez MCP i przy analizie zadania dla klienta uznał, że powinien sprawdzić dane w tym systemie. Połączył się z naszą wewnętrzną instancją produkcyjną, a nie z instancją klienta. Deweloper zatrzymał go na etapie planu. W przypadku pola NIP człowiek zmienił dwie decyzje: kazał dodawać link do istniejącego rekordu przy wykryciu duplikatu i zrezygnował z niepotrzebnej zmiany we frontendzie.

Jak liczyć koszt AI dla każdego etapu wytwarzania oprogramowania?

Koszt AI per etap to suma czasu ludzi, kosztu modelu i kosztu poprawek przypisana do konkretnego kroku procesu: planowania, implementacji, testów, code review i akceptacji. Taki podział pokazuje, który etap jest najdroższy i dlaczego. Łączny koszt zadania tego nie pokaże. Etap generowania testów może być tani w minutach człowieka, ale drogi w zużyciu tokenów. Code review może być tanie dla agenta, ale drogie dla seniora, który ocenia raport.

Najbardziej użyteczną jednostką jest koszt jednej zaakceptowanej zmiany, czyli zadania, które przeszło przez wszystkie bramki i trafiło do gałęzi deweloperskiej. Pomiar kosztu per etap jest naszym kolejnym krokiem, a nie gotowym wynikiem: orkiestrator już zapisuje artefakty każdego etapu, a na następnych projektach będziemy przypisywać do nich koszty. Pętlę testową ograniczyliśmy do trzech prób, po których agent wraca do człowieka. Bez tego limitu koszt jednego zadania mógłby rosnąć bez kontroli.

Etap procesuKto wykonujeCo mierzyćCo zaobserwowaliśmy przy polu NIP
Planowanie implementacjiAgent AI, akceptuje deweloperMinuty człowieka na bramce, liczba korekt planuDwie decyzje agenta zmienione przez dewelopera
Scenariusze testówAgent AI na podstawie user storyLiczba scenariuszy, odsetek zautomatyzowanych14 z 16 scenariuszy zautomatyzowanych
Implementacja i self-reviewAgent AIKoszt modelu, liczba poprawek po self-reviewJeden błąd wykryty i poprawiony przez agenta
Testy automatyczneAgent AI w pętli (maks. 3 próby)Liczba pętli, liczba testów, luki w pokryciu35 testów, luki: import i polskie etykiety
Code reviewAgent AI generuje raport, recenzent oceniaMinuty seniora, odsetek trafnych uwagBrak danych w tym przypadku
Testy akceptacyjneTesterMinuty testera, testy ręczne dla lukCzas testera wliczony w 104 minuty

Jak rzetelnie zmierzyć oszczędność z AI, zanim się ją ogłosi?

Rzetelny pomiar oszczędności z AI wymaga zmierzonego punktu odniesienia, próby zadań o różnej złożoności i trzech miar liczonych jednocześnie. Pojedynczy przypadek, nawet dobrze opisany, jest sygnałem do obserwacji, a nie wynikiem. Przed ogłoszeniem oszczędności warto sprawdzić pięć warunków:

  • punkt odniesienia jest zmierzony na podobnych zadaniach, a nie oszacowany po fakcie,
  • próba obejmuje co najmniej kilkanaście zadań podzielonych na kategorie złożoności, na przykład pole, moduł, proces, integracja,
  • mierzone są razem czas przejścia, czas pracy ludzi i koszt modelu AI,
  • liczona jest liczba błędów, które przeszły przez wszystkie bramki i wróciły z testów lub produkcji,
  • wynik obejmuje czas recenzentów i testerów, a nie tylko dewelopera.

Ostatni warunek ma znaczenie także w skali branży. Raport Faros AI oparty na telemetrii 22 000 programistów z 4000 zespołów pokazuje, że wraz ze wzrostem liczby zadań wykonywanych z AI mediana czasu code review wzrosła około pięciokrotnie, a liczba błędów na pull request o 28% (Faros AI, 2026; dane dostawcy narzędzi analitycznych).

Co pomiar oszczędności z AI oznacza dla firm zlecających rozwój CRM i HCM?

Dla firm zlecających rozwój CRM lub HCM pomiar oszczędności z AI oznacza, że warto pytać dostawcę o czas i koszt całej zmiany, a nie o deklarowany procent przyspieszenia. Wyceny zadań prostych, takich jak nowe pola czy modyfikacje struktury, mogą spadać szybciej niż wyceny integracji i procesów wieloetapowych. Rozliczanie w modelu Scrum lub Time & Material lepiej przenosi taką różnicę na klienta niż stała cena ustalona przed startem.

Drugą korzyścią jest proces, który poprawia się na podstawie własnych danych. W ciągu trzech miesięcy liczba skilli w orkiestratorze eVolpe wzrosła z 24 do 35, przybyło w nich około 40 000 linii, a automatyczne code review działało w 33 projektach. Audyt artefaktów z różnych projektów wykazał powtarzający się błąd: skill implementacji nie sprawdzał uprawnień użytkownika do nowych przycisków akcji. Skill został poprawiony, a to, czy błąd zniknął z raportów, sprawdzimy w kolejnym audycie.

Jeśli planujecie rozwój CRM lub HCM z udziałem agentów AI i chcecie policzyć, gdzie w Waszym procesie AI faktycznie skróci czas, a gdzie tylko przesunie koszt na inny etap, porozmawiajmy. Pokażemy, jak mierzymy to u siebie.

Umów bezpłatną konsultację z ekspertem wdrożeniowym eVolpe

Wybierz dogodny dla siebie termin.

Najczęściej zadawane pytania

Ile czasu oszczędza AI w programowaniu?

To zależy od złożoności zadania i sposobu pomiaru. W naszym przypadku czas pracy dewelopera przy prostym polu spadł z szacowanych 3 godzin do około 21 minut, ale cały proces trwał 104 minuty. Przy złożonych zadaniach oszczędność jest wyraźnie mniejsza.

Czy AI przyspiesza pracę doświadczonych programistów?

Nie zawsze. W randomizowanym badaniu METR z 2025 roku doświadczeni programiści pracujący z AI potrzebowali o 19% więcej czasu, choć sami oceniali, że byli o 20% szybsi. Efekt zależy od narzędzi, procesu i znajomości kodu.

Czym różni się lead time od czasu pracy dewelopera?

Lead time to czas od rozpoczęcia zadania do gotowej zmiany. Czas pracy dewelopera to minuty, które człowiek faktycznie poświęcił zadaniu. Przy pracy z agentem AI te wartości mocno się rozjeżdżają, dlatego trzeba mierzyć obie.

Jak liczyć koszt AI w wytwarzaniu oprogramowania?

Najlepiej per etap procesu: planowanie, implementacja, testy, code review i akceptacja. Dla każdego etapu sumuje się czas ludzi, koszt modelu AI i koszt poprawek. Wspólną jednostką jest koszt jednej zaakceptowanej zmiany.

Dlaczego oszczędność z AI nie jest liniowa?

Bo wraz ze złożonością zadania rośnie liczba decyzji wymagających człowieka i liczba pętli poprawek. W naszym procesie około połowy decyzji agenta na etapie planu wymaga korekty, a testy procesów wieloetapowych wymagają osobnego przygotowania.

Czy agent AI może samodzielnie testować kod?

Częściowo. Agent AI generuje scenariusze i testy przeglądarkowe, uruchamia je i poprawia błędy w pętli. W przypadku pola NIP zautomatyzował 14 z 16 scenariuszy. Luki, takie jak import danych, nadal sprawdza tester.

Na jakich systemach działa orkiestrator AI w eVolpe?

Produkcyjnie na SuiteCRM, a dla MintHCM jest w końcowej weryfikacji. W planach są Creatio i SpiceCRM. Warunkiem są skille i testy bazowe opisujące moduły i nawigację w danym systemie.

Źródła

Marcin Różański
Latest posts by Marcin Różański (see all)

Powiązane artykuły

Przewijanie do góry