Relacja TechCrunchu jest użyteczna, bo rozdziela dwa sygnały, które łatwo zlać w jeden: deweloperzy wyraźnie wolą pracować z asystentami AI, ale preferencja to coś innego niż produktywność.
Interesuje mnie nie to, że model szybko generuje kod – to już punkt wyjścia. Trudniejsze pytanie brzmi: czy zespół dostaje trwalsze oprogramowanie po doliczeniu review, kierowania modelem, debugowania i utrzymania.
- Według relacji METR miał problem z powtórzeniem kontrolowanego badania produktywności, bo wielu deweloperów nie chciało pracować bez AI nawet w ograniczonym zadaniu badawczym.
- Samoopisywane wzrosty produktywności nadal wyprzedzają twarde dowody na realną przepustowość całej organizacji.
- Zużycie tokenów jest słabym proxy wyniku. Wysokie użycie może oznaczać dźwignię, ale też kosztowne kręcenie się w miejscu.
- Kod z AI często przenosi koszt z pierwszej implementacji do review, napraw błędów, sprzątania architektury i długoterminowego utrzymania.
- Praktyczna odpowiedź nie brzmi „zakazać AI” ani „delegować wszystko”. Lepiej traktować wynik modelu jak pracę juniora: użyteczną, szybką i nadal wymagającą review, testów, ownershipu oraz osądu architektonicznego.
Perspektywa StackCompass: narzędzia AI coding są już częścią środowiska dostarczania, a nie pobocznym eksperymentem. To sprawia, że bramki jakości są ważniejsze, nie mniej. Zespół, który dodaje AI bez zmiany code review, dyscypliny testów, observability, polityki zależności i ownershipu architektury, głównie przyspiesza tempo, w którym niewycenione decyzje trafiają do repozytorium.
Lepsze pytanie nie brzmi: „ile AI użyliśmy?”. Brzmi: czy czas cyklu spadł bez wzrostu defektów trafiających na produkcję, obciążenia review, liczby incydentów albo kosztu przyszłych zmian?
Źródło: TechCrunch