Copilot napisał to, ale kto jest właścicielem? Luka w zarządzaniu, której mogą nie zauważać zespoły inżynieryjne

Inżynier otwiera Copilot, aby pomóc w tworzeniu kodu dla witryny klienta. W ciągu kilku sekund otrzymuje kod, którego ręczne napisanie wcześniej zajęłoby znacznie więcej czasu. Dla wielu programistów webowych i firm optymalizujących swoje strony naturalne jest zadawanie sobie pytania: czy ten kod jest niezawodny? Czy jest bezpieczny? Czy powinien być sprawdzony przed wdrożeniem?  Wszystkie te pytania mieszczą się pod jedną kwestią: kto będzie odpowiedzialny za kodowanie wspomagane przez SI? I, co najważniejsze, kto jest właścicielem zysku produktywności?

Jeśli SI pozwala zespołowi inżynieryjnemu wykonać więcej pracy w tym samym czasie, wszyscy mogą bardziej skorzystać z tej wartości ekonomicznej. Może to być programista oszczędzający czas, pracodawca uzyskujący większą wartość z zaoszczędzonych godzin lub klient otrzymujący to, za co zapłacił, z dodatkowymi godzinami do dyspozycji. Niezależnie od tego, jak korzyści z zaoszczędzonego czasu się przejawiają, najważniejsze pozostaje pytanie, jak praca jest zarządzana i wyceniana.

AI i programowanie stają się nieuniknione

Narzędzia do kodowania oparte na SI szybko zyskują popularność i wkraczają do głównego nurtu programowania. Według 2025 Stack Overflow Developer Survey, 84 % respondentów używało lub planowało używać narzędzi SI w swoim procesie tworzenia.

Mimo że wdrażanie SI do przepływów pracy programistów webowych staje się coraz powszechniejsze, wciąż istnieje niepewność co do jej niezawodności. Ta sama ankieta wykazała, że 46 % nie ma pełnego zaufania do dokładności wyników SI, a około 66 % wskazało rozwiązania SI, które były „prawie prawidłowe, ale nie do końca”, jako źródło frustracji.

Debata na temat kodowania z użyciem SI, która się kształtuje, dotyczy bardziej jej niezawodności niż tego, czy kod tworzy większą wartość i kto jest odpowiedzialny za zapewnienie tego.

SI łamie zależność między godzinami a wynikiem

Wynagrodzenie za rozwój oprogramowania zawsze opierało się na założeniu, że wynik inżynieryjny jest ściśle powiązany z nakładem pracy. Jednak generatywna SI teraz komplikuje to równanie.

Kontrolowany eksperyment z udziałem 95 programistów wykazał, że uczestnicy z dostępem do GitHub Copilot ukończyli określone zadanie serwera HTTP w JavaScript 55,8% szybciej niż bez dostępu.

To podkreśla, że SI może przyspieszyć rozwój, potencjalnie nie rezygnując z jakości. Jednak te wyniki są skuteczne tylko dlatego, że eksperyment obejmował bardzo konkretne zadanie programistyczne. Mimo że zadanie zostało wykonane szybciej, nie oznacza to, że Copilot sprawia, że cała organizacja inżynieryjna jest o 55,8 % bardziej produktywna.

Inne badanie ilustruje tę koncepcję. próba z udziałem 96 pełnoetatowych inżynierów oprogramowania Google wykazała, że programiści korzystający z SI ukończyli zadanie klasy korporacyjnej w około 96 minut, w porównaniu z 114 minutami dla tych, którzy nie mieli dostępu. Skorygowana szacunkowa ocena badaczy sugerowała około 21 % skrócenia czasu realizacji. Jednak badanie nie badało jakości kodu generowanego przez SI, ani nie poruszało kwestii równości związanej z poleganiem na tej technologii.

Istnieją również dowody na to, że SI spowalnia czas kodowania. randomizowane badanie przeprowadzone przez METR obejmowało 16 doświadczonych programistów open‑source, którzy pracowali nad 246 rzeczywistymi problemami w repozytoriach, które dobrze znali. Korzystając z narzędzi dostępnych na początku 2025 roku, w tym Claude Sonnet 3.5 i 3.7 oraz Cursor Pro, zajęło im to około 19 % dłużej, aby ukończyć zadania, mimo że wielu zakładało, że te narzędzia zaoszczędzą czas.

Razem te badania podważają oczekiwania, że SI umożliwia programistom szybszą pracę. Zamiast tego sprawia, że czas i wartość programistów stają się mniej przewidywalne dla firm świadczących usługi webowe oraz dla klientów, którzy z nich korzystają.

Problem wyceny, o którym nikt nie mówi

Model Czas i Materiał (T&M) jest powszechnym modelem w rozwoju stron internetowych przy zakupie oprogramowania, ponieważ rozwiązuje powtarzający się problem branżowy: projekt będący w ciągłym rozwoju.

W tym modelu, zamiast wymagać zdefiniowania każdej funkcji lub zadania przed rozpoczęciem prac, klienci mogą płacić za czas inżynieryjny w miarę postępu i zmian projektu.

Jednak SI wprowadza zakłócenia w tym sprawdzonym modelu. Gdy wynagrodzenie jest bezpośrednio powiązane z godzinami inżynieryjnymi, bardziej efektywny czas rozwoju może skutkować mniejszą liczbą godzin rozliczanych dla klientów. Jeśli SI zapewnia te same wyniki w krótszym czasie, technologia może tworzyć wartość dla klientów, ale redukcja godzin rozliczanych oznacza niższe przychody dla dostawców.

Rozwiązaniem nie jest zachęcanie programistów do wolniejszej pracy. Model T&M stoi teraz przed strukturalnym problemem dotyczącym sposobu projektowania cen i zachęt. Stosowanie stawek godzinowych do określania wartości może być ograniczające. Nabywca może dokładnie znać koszt każdej godziny inżynieryjnej, a jednak pozostawać niepewny co do całkowitej inwestycji potrzebnej do osiągnięcia pożądanego rezultatu.

W miarę jak SI zmienia produktywność inżynieryjną, pytanie może przesunąć się z:

„Ile kosztuje godzina programisty?” → „Co się dzieje z wartością, gdy potrzebna jest mniejsza liczba godzin programistów?”

Ustalenia METR komplikują to pytanie. Jeśli programiści wierzą, że mogą zaoszczędzić czas, podczas gdy w rzeczywistości zajmuje im to dłużej, ani przyjęcie SI, ani postrzegana produktywność nie są wystarczające, aby wykazać wartość finansową. Dlatego organizacje potrzebują zarządzania, które potrafi zmierzyć, co faktycznie się wydarzyło.

Luka w zarządzaniu ma czterech właścicieli

Omówienie zarządzania rozwojem wspomaganym przez SI musi wykraczać poza polityki określające, jakich narzędzi programiści mogą używać.

Istnieją co najmniej cztery rodzaje własności, które organizacje inżynieryjne powinny określić.

1. Kto jest właścicielem kodu?

SI może wygenerować implementację, ale nie może stać się wymówką dla rozwoju bez odpowiedzialności. Ktoś nadal musi być odpowiedzialny za przegląd, testowanie i zatwierdzanie kodu, aż do etapu produkcji.

2. Kto jest właścicielem ryzyka?

Szybszy kod jest wartościowy tylko wtedy, gdy nie powoduje problemów w innych miejscach. empiryczne badanie kodu generowanego przez SI zidentyfikowało luki bezpieczeństwa w 29,5 % badanych fragmentów Pythona i 24,2 % fragmentów JavaScript. Badanie wykazało również słabości obejmujące 43 kategorie z Common Weakness Enumeration.

Jednak badanie wykazało, że wprowadzanie ostrzeżeń analizy statycznej z powrotem do Copilot Chat może naprawić do 55,5 % zidentyfikowanych problemów bezpieczeństwa. Badania pokazują, jak SI może tworzyć i rozwiązywać problemy kodowania, ale organizacje potrzebują procesów, które określą, jak weryfikować jej wyniki.

NIST SP 800-218A odzwierciedla tę zasadę, rozszerzając swój Secure Software Development Framework o najlepsze praktyki dotyczące generatywnej SI i modeli o podwójnym zastosowaniu.

3. Kto jest właścicielem zysku produktywności?

Umowy handlowe od samego początku są kluczowe w określaniu, kto powinien otrzymać korzyści z efektywności. SI może pomóc klientom wydawać mniej, umożliwić zespołom dostarczanie większej liczby aplikacji lub nie przynieść żadnych korzyści finansowych po zakończeniu projektu.

To, co pozostaje niezmienne, to potrzeba przejrzystych procesów i dostarczania jakościowej, uzgodnionej pracy.

4. Kto jest właścicielem priorytetyzacji?

SI może uczynić tworzenie funkcji tańszym i szybszym, ale nie może decydować, czy te funkcje są potrzebne.

W rzeczywistości zwiększenie zdolności rozwojowych może sprawić, że priorytetyzacja stanie się ważniejsza. Gdy zespoły mogą szybciej budować i eksperymentować, wciąż ktoś musi określić, które wyniki uzasadniają dostępny budżet, a które pomysły należy odrzucić.

Zarządzanie SI staje się kwestią finansową

Te pytania sprawiają, że zarządzanie SI staje się coraz bardziej istotne. Wyobraźmy sobie dwóch partnerów rozwojowych pobierających podobne stawki godzinowe.

Jeden zintegrował SI z solidnym procesem inżynieryjnym i osiąga wymagany rezultat znacznie szybciej, podczas gdy drugi potrzebuje więcej czasu. Porównywanie samych stawek godzinowych nie mówi nabywcy wiele o procesach, które będą realizowane.

Nabywcy będą musieli ocenić:

• Całkowita przewidywana inwestycja
• Odpowiedzialność za przekroczenia budżetu
• Kontrole jakości dotyczące pracy generowanej przez SI
• Jak dzielone są zyski efektywności

Model T&M może pozostać użyteczny dla obu stron, jeśli świadomie akceptują niepewność w usługach. Umowy o stałej cenie mogą również działać, gdy wymagania i rezultaty są stabilne.

Jednak SI sprawia, że alternatywne struktury są warte zbadania. Jednym z podejść jest ustalenie maksymalnego limitu finansowego przy zachowaniu elastycznego zakresu. Następnie funkcje mogą być priorytetyzowane według wartości biznesowej w ramach tego modelu.

Jeśli inżynieria stanie się bardziej efektywna, zyski mogą przełożyć się na dodatkowe możliwości produktu, a nie na dodatkowy czas rozliczany. Zachęty handlowe powinny promować ten sam rezultat co zachęty inżynieryjne, tworząc bardziej użyteczne oprogramowanie tak efektywnie, jak to możliwe.

Ta sama rozmowa o SI

Liderzy inżynierii muszą rozumieć, jak zachęty handlowe wpływają na dostawę. Zespoły finansowe i zakupowe potrzebują wystarczającej przejrzystości w zakresie inżynierii wspomaganej SI, aby ocenić, czy deklarowana efektywność przynosi wymierną wartość.

Oznacza to, że dojrzałe zarządzanie SI nie może kończyć się na zatwierdzonych listach modeli, kontrolach bezpieczeństwa, politykach danych czy wymaganiach przeglądu kodu. Musi obejmować odpowiedzialność, ryzyko finansowe, priorytetyzację oraz własność zysków produktywności.

Ale istnieje drugie pytanie o własność, które może mieć znacznie większy wpływ na budżety technologiczne: kto jest właścicielem wartości stworzonej lub utraconej, gdy SI zmienia tempo tworzenia oprogramowania?

Organizacje, które określą, czy szybsza inżynieria rzeczywiście prowadzi do lepszych produktów, kontrolują inwestycje i osiągają wymierne wyniki biznesowe, będą tymi, które utrzymają przewagę nad konkurencją.

Jeśli Twój zespół deweloperski przyjąłby SI jutro, czy Twój obecny model zarządzania i handlowy w ogóle poinformowałby Cię, czy dostawa stała się bardziej wartościowa?