Pięć funkcji tworzenia kodu wdrożonych między 2 a 16 kwietnia 2026. Zero funkcji utrzymaniowych. Ten stosunek mówi wszystko o tym, gdzie naprawdę jest rynek AI do kodowania — i czego ten rynek odmawia uczciwie wycenić.

Cursor 3 (2 kwietnia) odpalił równoległe Agent Tabs — wiele agentów AI pisze kod jednocześnie na osobnych branchach. GitHub Copilot (4 kwietnia) dodał tryb Autopilot — agenty same zatwierdzają swoje wywołania narzędzi, nie pytając cię o zdanie. Windsurf 2.0 (10 kwietnia) wypuścił Agent Command Center. Claude Code (14 kwietnia) wprowadził Routines — zaplanowane agenty działające w tle, generujące kod na triggerach. Codex od OpenAI (16 kwietnia) dostał multi-agentowe workflow. Żadna z tych zapowiedzi nie porusza tematu tego, co dzieje się z kodem po jego wdrożeniu.

To nie jest przeoczenie. To strategia produktowa.

60%, którego nikt nie sprzedaje

Barry Boehm ustalił w 1976 roku, że utrzymanie pochłania 60–80% całkowitego kosztu cyklu życia oprogramowania. IBM potwierdzał to wielokrotnie przez kolejne dekady. Nic przez pięćdziesiąt lat inżynierii oprogramowania nie obaliło tego stosunku.

AI wygląda na to, że go jeszcze pogarsza.

Badanie opublikowane na arXiv 8 kwietnia 2026 przeanalizowało dziesięć dużych projektów wygenerowanych przez Cursora, z których każdy miał średnio 17 000 linii kodu. Poprawność funkcjonalna: 91% — kod działał. CodeScene, narzędzie do analizy kondycji kodu, znalazło 1 305 problemów projektowych w tych projektach: 28,4% zduplikowanego kodu, metody o średniej długości 171 linii (dobre praktyki kończą się na 20–30) i złożoność cyklomatyczna — liczba ścieżek rozgałęzień przez funkcję — średnio 17, prawie dwukrotność zalecanego pułapu.

Demo leci. Codebase jest strukturalnie wroga dla każdego, kto dotknie jej następny — łącznie z AI, które ją napisało.

Każdy ważny benchmark AI do kodowania wzmacnia tę ślepą plamkę. SWE-bench testuje poprawki błędów. HumanEval testuje generowanie funkcji. Żaden benchmark nie pyta 'czy ten model potrafi bezpiecznie dodać ficzer do splątanego codebase'u, który sam wygenerował trzy miesiące temu bez żadnej dokumentacji projektowej?" Bez takiego benchmarku vendorzy mają zerową motywację rynkową, żeby optymalizować pod kątem tego, co faktycznie kosztuje pieniądze.

Dlaczego AI strukturalnie nie potrafi utrzymać tego, co tworzy

Utrzymanie wymaga trzech zdolności, których tworzenie nie wymaga: spójnych decyzji projektowych między sesjami, zrozumienia dlaczego kod istnieje (a nie tylko co robi), oraz dyscypliny, żeby refaktoryzować zamiast duplikować.

Obecne narzędzia AI oblewają we wszystkich trzech.

Każda nowa sesja zaczyna się z zerową pamięcią wcześniejszych decyzji projektowych. Model generuje jakikolwiek wzorzec pasuje do aktualnego prompta, a nie ten, którego użył we wtorek. Dlatego badanie z arXiv znalazło 28,4% duplikacji — AI rozwiązuje ten sam problem za każdym razem inaczej, bo nie pamięta, że już go rozwiązywało.

Randomizowane badanie kontrolowane METR — opublikowane w lipcu 2025, wciąż jedyne kontrolowane badanie tego typu — zmierzyło przepaść między percepcją a rzeczywistością: 16 doświadczonych programistów na swoich własnych repozytoriach pracowało o 19% wolniej z narzędziami AI, jednocześnie wierząc, że są o 20% szybsi. 39 punktów procentowych delty między tym, co programiści myślą że się dzieje, a tym, co faktycznie się dzieje. Na znajomych codebase'ach. Na nieznanym kodzie wygenerowanym przez AI nikt tego nie zmierzył, bo nikt nie stworzył odpowiedniego benchmarku.

Czego wymagałoby narzędzie utrzymaniowe

Gdybyś projektował narzędzie AI do kodowania pod kątem 60–80% pracy, która faktycznie kosztuje, nie przypominałoby niczego, co jest dziś na rynku.

Uzasadnienie projektowe jako metadane. Nie tylko co kod robi — dlaczego jest tak zbudowany. Każda wygenerowana przez AI funkcja powinna nieść ze sobą zapis ograniczeń, rozważanych alternatyw i decyzji projektowych, które ją stworzyły. CLAUDE.md w Claude Code jest najbliższym przybliżeniem: trwały kontekst projektu między sesjami. Ale to plik tekstowy, który sam utrzymujesz ręcznie, nie zautomatyzowany rejestr architektoniczny.

Wymuszanie spójności między sesjami. Narzędzie nastawione na utrzymanie wykrywałoby, kiedy model wprowadza wzorzec sprzeczny z istniejącym, i blokowało konflikt zanim kod zostanie wygenerowany — nie po tym, jak człowiek go przejrzy. Indeksowanie codebase'u w Cursorze (do 500 MB, zapytania poniżej sekundy) zapewnia warstwę retrieval, jakiej to wymaga. Retrieval bez egzekwowania to biblioteka bez bibliotekarza.

Refaktoryzacja jako tryb domyślny. Obecne narzędzia optymalizują pod nowy kod. Narzędzie utrzymaniowe domyślnie modyfikowałoby istniejący kod — znajdując właściwe miejsce do dodania logiki zamiast generowania nowego pliku. Mierzyłoby i minimalizowało duplikację jako główną metrykę obok poprawności funkcjonalnej.

Bramki degradacji. Kiedy złożoność cyklomatyczna przekracza progi, kiedy metody puchną powyżej 30 linii, kiedy wskaźniki duplikacji rosną — narzędzie odmawia commita. Nie jako opcjonalny plugin. Jako domyślne zachowanie. Tak jak type checker blokuje nieprawidłowy kod, narzędzie utrzymaniowe blokuje kod niemożliwy do utrzymania.

Badanie longitudinalne JetBrains opublikowane 14 kwietnia 2026 śledziło 800 programistów przez 151,9 miliona zarejestrowanych zdarzeń i ujawniło sygnał, na który żadne narzędzie do kodowania dziś nie reaguje: programiści spędzają ponad jedną trzecią czasu weryfikując sugestie AI i wycofują mniej więcej co piątą zaakceptowaną kompletację, usuwając kod później. Ten wzorzec usuwania to darmowy sygnał treningowy — korpus danych 'model myślał, że to jest poprawne, człowiek udowodnił, że nie" — leżący w telemetrii każdego IDE. Ktoś mógłby zbudować pętlę zwrotną, która przetwarza te cofnięcia i uczy się generować możliwy do utrzymania kod od początku. Nikt tego nie zrobił, bo demo tworzenia się sprzedaje. 30-sekundowy screencast agenta stawiającego apkę z prompta zbiera miliony wyświetleń. Screencast agenta stapiającego starannie rozkładającego metodę o 171 liniach na sześć czystych funkcji — dostanie co najwyżej talk na konferencji.

Realia cenowe

Jeśli w tym kwartale zatwierdziłeś projekt budowany przez AI, oto czego żaden vendor ci nie powie: zabudżetuj trzykrotność kosztu tworzenia na pierwszy rok utrzymania. Jeśli twój agent AI napisał 17 000 linii w tydzień, twoi inżynierowie spędzą trzy tygodnie na rozplątywaniu problemów projektowych, zanim będą mogli bezpiecznie cokolwiek do tego dodać — a potem powtórzą ten cykl po każdym nowym ficzerze.

Uczciwe podejście: traktuj kod wygenerowany przez AI jako jednorazowy prototyp z sześciomiesięcznym terminem ważności. Zrób demo, zwaliduj pomysł, a potem przebuduj części, które udowodniły swoją wartość, z inżynierami rozumiejącymi architekturę.

Każdy vendor narzędzi AI do kodowania w kwietniu 2026 wycenia i marketuje tworzenie jako produkt. Faktyczne centrum kosztów w oprogramowaniu nigdy nie było tworzenie. Dopóki vendor nie zbuduje — i nie zacznie za to pobierać opłat — mnożnika utrzymaniowego, kupujesz najtańszą fazę procesu i płacisz pełną cenę za wszystko, co po niej następuje.