Agent do kodowania, który nie obniża kosztów utrzymania, to tylko drogi dług techniczny

Matematyka Shore'a jest prosta i niewygodna: agent do kodowania musi obniżać koszty utrzymania dokładnie w takim samym stosunku, w jakim zwiększa output. Inaczej zespół nie zarabia na szybkości, lecz drożej płaci.

Szybsze pisanie kodu nie wystarczy, gdy backlog rośnie tak samo szybko jak dług techniczny

James Shore napisał to bez owijania w bawełnę: jeśli zespół dzięki agentowi podwoi wolumen zmian, ale koszty utrzymania pozostaną takie same, nie zyskał 2× produktywności. Zyskał 2× maintenance backlog. Arytmetyka jest bezpośrednia. Dwukrotnie szybszy output przy tych samych kosztach utrzymania oznacza podwojenie całkowitego kosztu własności. Dwukrotnie szybszy output przy podwojeniu kosztów utrzymania oznacza czterokrotny wzrost całkowitych kosztów.

Żeby liczby wyszły na zero, agent musi obniżać koszty utrzymania odwrotnie proporcjonalnie do tempa, w jakim dodaje kod. Podwójna produktywność wymaga o połowę niższych kosztów utrzymania. Potrójna produktywność wymaga jednej trzeciej kosztów utrzymania.

Dla zespołów inżynierskich to zmienia metrykę sukcesu

Śledzenie liczby pull requestów, story pointów czy zaoszczędzonych godzin przy implementacji nie wystarczy. Istotne jest to, czy agent produkuje kod, który jest tańszy w utrzymaniu: mniejsze zmiany z jasnym przeznaczeniem, lepsze testy, czytelniejszy projekt, bezpieczniejszy refaktoring, decyzje udokumentowane na bieżąco.

Simon Willison skuratorował tę myśl na swoim blogu 11 maja 2026. Sam nie dodał rozbudowanej analizy. Wybrał ją jako wystarczająco silną, by stała samodzielnie. To jest sygnał kuratorski: Shore nazwał problem, który producenci coding agents konsekwentnie ignorują, bo ich metryką jest szybkość pisania, nie koszt własności kodu.

Argument Shore'a jest matematycznie poprawny, ale pomija nieliniowe koszty

Argument Shore'a jest matematycznie poprawny, ale pomija jedną kwestię: nie wszystkie uwzględnione koszty są mierzalne liniowo z góry. Maintenance cost zależy od architektury, zwinności zespołu i tego, kto będzie czytał kod w przyszłości. Agent, który zmusza programistę do dokładniejszego myślenia o projekcie, może obniżać maintenance cost w sposób, który nie jest widoczny w metrykach PR.

Druga zastrzeżenie: ramy Shore'a sprawdzają się dobrze dla kodu brownfield. W projektach greenfield, gdzie zespół aktywnie refaktoruje i testuje kod generowany przez AI, kalkulacja może wyglądać inaczej.

Agent, który zmienia review, a nie tylko output, będzie dowodem w praktyce

Agenci, którzy tylko generują kod, to turboszpadle. Dowód na to, że agent naprawdę obniża maintenance cost, będzie widoczny w narzędziach: agent, który potrafi wyjaśnić każdą zmianę, znaleźć skutki uboczne w kodzie, utrzymywać sieć testów i obniżyć koszty review. Dopóki te możliwości nie są standardem w coding agents, Shore ma rację.

Werdykt Lilith

Zespół z 3× większą liczbą pull requestów, który nie nadąża z review, nie jest 3× bardziej produktywny. Jest 3× bardziej zadłużony. Agent, który nie obniża maintenance, to tylko szybszy sposób na kopanie dołka.