Przepisanie kodu Cisco z AI stawia cel 98% za nieograniczonymi tokenami

Cisco miało przyznać 27-letniemu inżynierowi nieograniczone tokeny AI, aby w ciągu 24 miesięcy przepisał 98% jego starszego kodu. Projekt przepisywania kodu Cisco z AI łączy wyjątkowo szeroki cel z niewielkim proponowanym zespołem. Jego znaczenie zależy od tego, co Cisco zamierza zmienić i jak potwierdzi, że zmiany działają.

Według Tom’s Hardware, przekazującego informacje Fortune, prezes i dyrektor ds. produktów Jeetu Patel poparł byłego założyciela startupu Padmanabhana Krishnamurthy’ego po rozmowie w San Francisco. Zadanie ma obejmować początkowy czterotygodniowy okres weryfikacji koncepcji. Szczegóły te opisują eksperyment i ambicję, a nie niezależnie zweryfikowane wyniki modernizacji.

Kluczowe napięcie dotyczy nieograniczonego generowania kodu kontra odpowiedzialnego dostarczania oprogramowania. Amazon opisał już modernizacje aplikacji wspierane przez AI, zapewniając użyteczny punkt odniesienia. Ambicja przypisywana Cisco rodzi szersze pytanie: jak dużą odpowiedzialność organizacyjną może przejąć niewielki zespół inżynierski, gdy wprowadzanie zmian staje się łatwiejsze?

Przepisanie kodu Cisco z AI zaczyna się od celu, a nie ukończonej migracji

Opisywane zadanie potwierdza poparcie kadry zarządzającej; nie dowodzi, że Cisco zmodernizowało swoje oprogramowanie.

Relacja Tom’s Hardware dotycząca zadania związanego ze starszym kodem wskazuje Krishnamurthy’ego, znanego jako Paddy, jako inżyniera stojącego za propozycją. Miał on zaproponować dwuosobowy zespół. Patel zapewnił wsparcie, w tym nieograniczone tokeny — jednostki tekstu przetwarzane przez modele AI podczas odbierania poleceń i generowania odpowiedzi.

Według raportu Krishnamurthy pracował wcześniej pięć poziomów organizacyjnych poniżej Patela. Przedstawia on projekt jako zmianę odpowiedzialności w takim samym stopniu jak zmianę narzędzi. Były założyciel otrzymałby przestrzeń do zakwestionowania utrwalonych założeń inżynierskich.

Istnieje możliwa do niezależnego zweryfikowania historia przejęcia, która stoi za tym powiązaniem. Komunikat Cisco o przejęciu EzDubs podaje, że transakcję sfinalizowano 25 listopada 2025 roku. Cisco opisało EzDubs jako firmę tworzącą oprogramowanie AI specjalizującą się w tłumaczeniu mowy w czasie rzeczywistym. Wśród podanych powodów znalazło się poszerzenie talentów inżynierskich w obszarze współpracy.

Ta historia wspiera relację o przejętym startupie dołączającym do Cisco. Nie potwierdza jednak niezależnie propozycji przepisania kodu ani jej wykonalności. Ogłoszenie przejęcia dotyczy możliwości współpracy, a nie opublikowanego planu transformacji starszego oprogramowania Cisco.

Ostrożności wymaga również sformułowanie opisywanego zadania. Refaktoryzacja oznacza zmianę wewnętrznej struktury oprogramowania przy zachowaniu jego obserwowalnego z zewnątrz zachowania. Przepisanie może oznaczać zastąpienie implementacji, potencjalnie wprowadzając inne decyzje projektowe i ryzyka zgodności.

Terminy te mogą opisywać nakładające się prace, ale nie są zamiennymi miarami postępu. Zautomatyzowane wewnętrzne porządki znacząco różnią się od zastąpienia komponentu, od którego zależą klienci. Program modernizacji musi wskazać, do której kategorii należy każda zmiana.

Publiczne doniesienia nie zawierają szczegółowego wykazu stojącego za liczbą 98%. Nie wyjaśniają również, czy ukończenie oznacza wygenerowane zmiany, zaakceptowane zmiany, wdrożenie produkcyjne czy wycofanie starych implementacji. Bez tych definicji odsetek wyraża ambicję wyraźniej niż zakres operacyjny.

Ta sama ostrożność dotyczy harmonogramu. Relacje opublikowane 30 października 2026 roku nie dowodzą, że zegar projektu zaczął biec tego dnia. Czytelnicy nie powinni wyliczać dokładnej daty ukończenia wyłącznie na podstawie daty publikacji.

Użyteczny punkt wyjścia jest więc wąski. Prezes Cisco miał autoryzować ambitny eksperyment inżynierski z określonym, nagłośnionym celem. To, czy eksperyment stanie się powtarzalnym programem modernizacji, pozostaje odrębnym pytaniem.

Nieograniczone tokeny przenoszą presję na przegląd i odpowiedzialność

Usunięcie limitu generowania zmienia miejsce, w którym kumuluje się praca inżynierska; nie eliminuje pracy niezbędnej do zaakceptowania zmiany.

Nieograniczone tokeny AI brzmią jak nieograniczone możliwości inżynierskie, ponieważ widocznym wynikiem jest kod. Jednak wygenerowany patch, czyli proponowana zmiana w plikach źródłowych, nadal musi mieć uzasadnienie. Ktoś musi ustalić, co zmienia, dlaczego jest bezpieczny i kto będzie go utrzymywać.

Rozważmy hipotetyczną modernizację współdzielonego komponentu uwierzytelniania. Narzędzie AI może zaproponować czytelniejszy kod, nowsze zależności i dodatkowe testy. Taka propozycja nadal wymagałaby oceny względem istniejących reguł uprawnień i obsługiwanych konfiguracji klientów.

Ten przykład ma charakter ilustracyjny, a nie opis projektu Cisco. Pokazuje, dlaczego tworzenie wiarygodnie wyglądającego oprogramowania i przyjmowanie odpowiedzialności za zachowanie wdrożonego systemu to różne działania. Szybsze tworzenie wersji roboczych może ujawnić niedobór recenzentów, zamiast wyeliminować niedobór programistów.

Menedżerowie inżynierii odczuwają natychmiastową presję. Jeśli proponowane zmiany napływają szybciej, niż zespoły mogą je ocenić, rośnie kolejka przeglądów. Menedżerowie muszą wtedy zdecydować, czy zawęzić zakres prac, zwiększyć możliwości przeglądu, czy zmienić sposób dołączania dowodów do każdej propozycji.

Specjaliści ds. bezpieczeństwa mierzą się z powiązanym problemem. Muszą zrozumieć, czy proces zachowuje granice dostępu i odpowiednio obsługuje wrażliwe informacje. Patch, który wygląda czyściej, może nadal zmieniać założenia wcześniej egzekwowane pośrednio.

Właściciele produktów muszą odróżniać wewnętrzne usprawnienia od zmian wpływających na klientów. Zastąpienie zależności, czyli zewnętrznego komponentu oprogramowania, może wprowadzić zachowanie wykraczające poza pliki bezpośrednio edytowane przez narzędzie AI. Akceptacja zależy więc od otaczającego systemu, a nie tylko od atrakcyjności zamiennika.

Wsparcie kadry zarządzającej ma znaczenie, ponieważ obowiązki te przekraczają linie raportowania. Niewielki centralny zespół może opracować podejście, lecz zespoły, których to dotyczy, nadal potrzebują sposobu zatwierdzania zmian. Niejasne uprawnienia zamieniłyby każdą udaną demonstrację w negocjacje o tym, kto przyjmuje konsekwencje.

To jest organizacyjne znaczenie ambicji związanych z przepisywaniem kodu Cisco z AI. Eksperyment sprawdza, czy mały zespół potrafi stworzyć proces, któremu zaufają inne zespoły. Jego rezultaty musiałyby obejmować odtwarzalne dowody, zrozumiałe granice zmian i jasne ścieżki obsługi awarii.

Uznani opiekunowie kodu pozostają kluczowi dla tego procesu. Często wiedzą, dlaczego istnieje niezręczna implementacja lub który wymóg klienta wyjaśnia nietypową gałąź. Ta wiedza jest użytecznym dowodem, nawet gdy sugeruje, że bieżąca implementacja powinna się zmienić.

Dokumentacja staje się częścią kwestii możliwości inżynierskich. Zespoły potrzebują dostępu do decyzji projektowych, historii incydentów i wymagań dotyczących zgodności przed oceną proponowanego zastąpienia. Przeszukiwalna baza wiedzy inżynierskiej rozwiązuje ten problem informacyjny równolegle z przepływem pracy programistycznej.

Wynikająca z tego presja spada na obie strony eksperymentu. Mały zespół musi uczynić swoją pracę możliwą do przeglądu, podczas gdy istniejące zespoły muszą konkretnie wyjaśniać zastrzeżenia. Ani nieograniczone generowanie, ani doświadczenie instytucjonalne nie zapewniają automatycznej odpowiedzi.

Modernizacje aplikacji Amazonu stanowią węższe porównanie

Ograniczona migracja dostarcza wyraźniejszych dowodów niż odsetek obejmujący niezdefiniowany zasób oprogramowania.

Amazon stanowi branżowy precedens dla modernizacji wspieranej przez AI. W swoim grudniowym ogłoszeniu z 2024 roku dotyczącym transformacji aplikacji firma opisała aktualizację wewnętrznych aplikacji do Java 17. Java to język programowania i środowisko wykonawcze używane w oprogramowaniu przedsiębiorstw.

Amazon podał, że wysiłek objął dziesiątki tysięcy aplikacji produkcyjnych i zaoszczędził ponad 4500 osobolat pracy programistów. Są to wyniki raportowane przez firmę, a nie niezależna ocena. Opisują jednak bardziej konkretną transformację niż ogólna obietnica przepisania starszego kodu.

Ta konkretność ma znaczenie. Aktualizacja wersji zapewnia możliwy do zidentyfikowania stan początkowy i docelowy. Recenzenci mogą sprawdzić, czy aplikacja się buduje, czy oczekiwane zachowanie pozostaje nienaruszone i czy nowe środowisko wykonawcze obsługuje jej wymagania.

Szersze przepisanie może łączyć wiele różnych celów. Może obejmować uproszczenie architektury, zastąpienie zależności, poprawę łatwości utrzymania lub usunięcie przestarzałej funkcjonalności. Każdy cel wymaga własnych kryteriów akceptacji, nawet jeśli te same narzędzia AI pomagają tworzyć zmiany.

Proces aktualizacji Java AWS również zachowuje wyraźny etap akceptacji przez człowieka. Dokumentacja opisuje budowanie oryginalnego kodu, przeprowadzenie transformacji oraz prośbę do programisty o zweryfikowanie i zaakceptowanie wyników. Rozróżnia zmiany zgodności językowej od dodatkowych aktualizacji zależności.

To rozróżnienie jest użyteczne, ponieważ modernizacja rzadko jest pojedynczą operacją. Udana aktualizacja języka nie dowodzi, że każda biblioteka jest aktualna. Pomyślne zbudowanie nie dowodzi, że każdy przepływ pracy klienta zachowuje się prawidłowo.

Przykład Amazonu wspiera zatem ograniczony wniosek: transformacja wspierana przez AI ma konkretne zastosowania przedsiębiorstw z możliwymi do opisania granicami. Nie dowodzi, że zgłaszany cel Cisco jest osiągalny. Nie pokazuje też, że niewielki zespół wdrożeniowy może samodzielnie wykonać każde powiązane zadanie akceptacyjne.

Jest również lekcja dotycząca pomiaru. Szacowany zaoszczędzony czas programistów zależy od założonego alternatywnego procesu. Szacunek staje się bardziej informacyjny, gdy towarzyszą mu wdrożone aplikacje, zaakceptowane zmiany i utrzymująca się wydajność operacyjna.

Eksperyment Cisco skorzystałby na podobnie konkretnym raportowaniu. Opis początkowego obciążenia ujawniłby, czy zespół testuje powtarzalną transformację, czy bada szersze przeprojektowanie. Oba podejścia mogą być wartościowe, lecz wiążą się z inną niepewnością.

Dla nabywców korporacyjnych to rozróżnienie wpływa na interpretację twierdzeń dostawców. Wewnętrzna demonstracja jest dowodem dotyczącym określonego procesu w określonym środowisku. Wspierana funkcjonalność dla klientów wymaga dodatkowych zobowiązań dotyczących utrzymania, dokumentacji i obsługi awarii.

Presja konkurencyjna dotyczy dowodów w takim samym stopniu jak szybkości. Firmy omawiające modernizację AI coraz częściej muszą wyjaśniać, co przekształcono i jak przebiegała akceptacja. Dramatyczny odsetek w nagłówku dostarcza mniej użytecznych informacji niż jasno ograniczony rezultat.

Porównanie utrzymuje także historię Cisco w realiach. Jej znaczenie wynika z testowania, czy agresywne wsparcie kadry zarządzającej może poszerzyć zasięg inżynierii wspieranej przez AI. Doświadczenie Amazonu dostarcza kontekstu, nie rozstrzygając tego eksperymentu z góry.

Liczba 98% potrzebuje definicji, zanim stanie się użytecznym wskaźnikiem

Procent modernizacji nabiera znaczenia dopiero wtedy, gdy czytelnicy wiedzą, co wlicza się do ukończenia.

Procent wymaga mianownika — całkowitej wielkości, względem której mierzy się postęp. W tym przypadku mogą to być linie kodu źródłowego, repozytoria, aplikacje lub wybrane komponenty. Opublikowane informacje nie określają, która interpretacja ma zastosowanie.

Te wybory mogą prowadzić do bardzo różnych obrazów postępu. Przeformatowanie plików może objąć wiele linii kodu źródłowego bez zmiany łatwości utrzymania. Zastąpienie niewielkiego, lecz centralnego komponentu może wymagać rozległej walidacji, mimo że dotyczy stosunkowo niewielkiej ilości kodu.

Równie ważna jest reguła ukończenia. Wygenerowanie proponowanej zmiany jest etapem pośrednim. Jej zaakceptowanie w repozytorium źródłowym to kolejny etap, a wdrożenie jej i wycofanie starej implementacji wymaga dalszej pracy.

Nie oznacza to, że cel 98% jest z natury nierozsądny. Oznacza to, że na podstawie publicznego opisu trudno go ocenić. Czytelnicy potrzebują definicji zakresu i akceptacji, zanim potraktują go jako prognozę inżynieryjną.

Język refaktoryzacji tworzy kolejne wyzwanie pomiarowe. Zachowanie dotychczasowego działania jest kluczowe dla refaktoryzacji, lecz istniejące testy badają jedynie zachowania, które obejmują. Pomyślne uruchomienie testów nie dowodzi, że każdy nietestowany warunek pozostał bez zmian.

Ta luka wyjaśnia, dlaczego znaczenie mają przegląd i obserwacja działania systemu. Regresja, czyli niezamierzona utrata istniejącego zachowania, może wystąpić poza scenariuszami reprezentowanymi w automatycznych testach. Pewność wynika z łączenia dowodów, a nie z traktowania pojedynczej kontroli jako rozstrzygającej.

Badania ostrzegają też przed utożsamianiem poczucia szybkości z mierzoną produktywnością. Eksperyment METR dotyczący produktywności programistów objął 16 doświadczonych programistów wykonujących 246 zadań w znanych im projektach open source. Dopuszczenie narzędzi AI z początku 2025 roku wydłużyło czas realizacji o 19%.

Uczestnicy mimo to sądzili, że narzędzia pomogły im szybciej zakończyć pracę. Wynik pokazuje, dlaczego postrzegana wygoda i mierzona szybkość dostarczania wymagają oddzielnej oceny. Nie przewiduje on rezultatów Cisco ani nie dowodzi, że późniejsze narzędzia AI mają te same ograniczenia.

METR później podkreślił to rozróżnienie. Jego aktualizacja projektu eksperymentu z lutego 2026 roku opisała trudności w interpretowaniu nowszych pomiarów, ponieważ zmieniły się uczestnictwo i dobór zadań. Badacze uznali poprawę szybkości za prawdopodobną, ostrzegając jednocześnie, że dostępne dowody nie pozwalają precyzyjnie określić skali zysku.

Łącznie te ustalenia przemawiają za ostrożnym pomiarem, a nie za uniwersalnym werdyktem dotyczącym programowania z AI. Możliwości narzędzi się zmieniają, a różne zadania ujawniają odmienne ograniczenia. Wyników dotyczących utrzymania znanych projektów open source nie można po prostu przenieść na program modernizacji w dużej firmie.

W przypadku Cisco istotne pytanie brzmi, czy poprawia się cały proces. Szybsze generowanie miałoby ograniczoną wartość, gdyby przegląd i korekty pochłaniały zaoszczędzony czas. Z drugiej strony niezawodny proces mógłby zapewniać wartość, nawet gdyby celowo pozostawiał znaczną część kodu nietkniętą.

Wiarygodna ocena powinna zatem odróżniać aktywność od rezultatów. Proponowane poprawki pokazują aktywność; zaakceptowane transformacje pokazują postęp po przejściu przeglądu. Stabilne wdrożenie i mniejsze obciążenie utrzymaniowe dostarczają silniejszych dowodów, że praca osiągnęła swój cel.

Nieograniczone tokeny usuwają potencjalne ograniczenie eksperymentowania. Nie rozstrzygają jednak tych kwestii pomiarowych. Opisywany cel staje się bardziej informacyjny, gdy Cisco wyjaśni, jak odróżni efektowną demonstrację od trwałej poprawy inżynieryjnej.

Mały zespół nadal potrzebuje dostępu do wiedzy instytucjonalnej

Najsilniejsza wersja tego eksperymentu łączy swobodę przeprojektowania z dostępem do powodów, dla których istniejące oprogramowanie działa tak, jak działa.

Historia zatrudnienia zachęca do prostej interpretacji pokoleniowej. Młody założyciel kwestionuje założenia akceptowane przez dużą organizację. Takie ujęcie oddaje opisywaną zmianę szans, lecz nie pozwala ustalić, które osądy inżynieryjne są właściwe.

Młodość nie gwarantuje trafnej architektury, podobnie jak staż nie uzasadnia automatycznie zachowania implementacji. Użyteczne rozróżnienie dotyczy tego, czy propozycja wytrzymuje analizę. Mały zespół potrzebuje wystarczającej swobody, by testować pomysły, oraz dość kontekstu, by interpretować wyniki.

Opisywane doświadczenie Krishnamurthy’ego jako założyciela jest istotne dla tego organizacyjnego pytania. Doświadczenie startupowe może sprzyjać patrzeniu na cały problem, a nie tylko na wąsko przydzielone zadanie. Wciąż jednak nie zastępuje zrozumienia systemów, których dotyka zmiana.

Wiedza instytucjonalna może wyjaśniać pozorne nieefektywności. Nietypowa sekwencja ponowień może uwzględniać określony warunek operacyjny. Nadmiarowa kontrola może chronić starszą integrację. Są to hipotetyczne przykłady, a nie zidentyfikowane cechy oprogramowania Cisco.

Takie wyjaśnienia należy, o ile to możliwe, przekształcać w testowalne wymagania. W przeciwnym razie modernizacja zależy od odnalezienia osoby pamiętającej dawną decyzję. Uchwycenie jej uzasadnienia pozwala nowej implementacji zachować konieczne zachowanie, a jednocześnie kwestionować pierwotny projekt.

Znaczenie ma też odwrotny obowiązek. Ugruntowane zespoły powinny odróżniać udokumentowane wymagania od nawyków, które przetrwały bez analizy. Sprzeciw staje się możliwy do wykorzystania, gdy wskazuje warunek awarii lub kryterium akceptacji.

W tym miejscu wsparcie kadry kierowniczej może pomóc, nie zastępując osądu inżynieryjnego. Kierownictwo może upoważnić do dostępu, rozstrzygać spory o odpowiedzialność i chronić czas na ocenę. Nie może jednak ustanowić poprawności samym entuzjazmem ani sprawić, by termin zastąpił dowody.

Najcenniejszym wkładem małego zespołu może być zatem powtarzalny proces, a nie duża ilość kodu zastępczego. Taki proces łączyłby proponowane transformacje z odpowiednimi wymaganiami i jasną ścieżką zatwierdzania. Inne zespoły mogłyby wtedy oceniać podobną pracę bez odtwarzania całej procedury.

Ta możliwość zmienia sposób interpretowania proponowanego poziomu zatrudnienia. Niewielki zespół może opracować metody transformacji i koordynować ich wdrażanie. To różni się od twierdzenia, że te osoby same mogą przejąć każdą odpowiedzialność za testowanie, bezpieczeństwo, wsparcie i utrzymanie.

Ogranicza to również to, co ta historia mówi o zatrudnieniu na stanowiskach juniorskich. Przyznanie przejętemu założycielowi nietypowej odpowiedzialności nie dowodzi ogólnego wzorca zatrudniania. Przypadek dostarcza dowodów dotyczących konkretnej decyzji zarządczej, a nie rezultatu na rynku pracy.

Dla programistów praktyczna implikacja dotyczy pracy otaczającej generowany kod. Zrozumienie wymagań, wyjaśnianie kompromisów i ustanawianie dowodów pozostają konieczne, gdy tworzenie szkiców staje się łatwiejsze. Obowiązki te stają się bardziej widoczne, gdy projekt próbuje wprowadzać zmiany ponad granicami organizacyjnymi.

Dla pracowników wiedzy w szerszym ujęciu analogią jest dostęp do kontekstu. System AI może stworzyć wiarygodną odpowiedź, nie dostrzegając powodu, dla którego wcześniejsza decyzja miała znaczenie. Użyteczna automatyzacja potrzebuje sposobu na odzyskanie tego uzasadnienia i ujawnienie niepewności.

Eksperyment Cisco jest zatem również testem uczenia się organizacji. Jego perspektywy poprawiają się, jeśli mały zespół potrafi przekształcić rozproszoną wiedzę w wielokrotnie używalne dowody akceptacji. Słabną, jeśli projekt traktuje doświadczonych opiekunów systemów wyłącznie jako przeszkody dla szybszego tworzenia wyników.

Obserwuj dowody z pilotażu, akceptację produkcyjną i obciążenie utrzymaniowe

Kolejna użyteczna aktualizacja wyjaśniłaby, co przeszło ocenę, kto to zaakceptował i co wydarzyło się później.

Przepisanie kodu Cisco z użyciem AI stanie się łatwiejsze do oceny dzięki konkretnym dowodom w nadchodzących miesiącach. Opisywany czterotygodniowy okres proof of concept daje czytelnikom krótkoterminowy punkt odniesienia. Relacje nie ustalają jednak jego dokładnej daty rozpoczęcia ani nie obiecują publicznej publikacji.

Pierwszym sygnałem jest opis zakresu i wyników pilotażu. Czytelnicy powinni szukać rozpoznawalnego obciążenia pracą, określonego celu transformacji i kryteriów akceptacji. Takie szczegóły pokazałyby, czy zespół przetestował coś reprezentatywnego dla szerszych ambicji.

Udana demonstracja wzmocniłaby argumenty, gdyby ujawniała zarówno osiągnięcia, jak i ograniczenia. Na przykład informacja o tym, które zmiany wymagały ludzkiej korekty, pomogłaby ustalić rzeczywiste wymagania procesu. To standard dowodowy, a nie prognoza dotycząca tego, co Cisco ujawni.

Demo pokazujące wyłącznie nowo wygenerowany kod stanowiłoby słabsze potwierdzenie. Demonstrowałoby wynik bez wyjaśnienia zgodności lub akceptacji. Różnica ma znaczenie, ponieważ długoterminowy cel dotyczy zmieniania istniejącego oprogramowania, a nie tworzenia samodzielnego przykładu.

Drugim sygnałem jest akceptacja w produkcyjnym procesie dostarczania. Czytelnicy powinni szukać potwierdzenia, że odpowiedzialne zespoły zatwierdziły ograniczoną transformację i ją wdrożyły. Procedura wycofania, czyli określony sposób przywrócenia wcześniejszej wersji, dodatkowo wyjaśniłaby, jak program radzi sobie z niepowodzeniem.

Ten sygnał wzmocniłby argument za modernizacją, ponieważ łączy eksperyment z odpowiedzialnością operacyjną. Pokazałby, że zespoły, których dotyczy zmiana, potrafią ocenić pracę, a nie tylko ją podziwiać. Zatwierdzenie nadal wymagałoby interpretacji w ramach zakresu danego wdrożenia.

Odwrotnie, powtarzające się demonstracje bez wdrożenia pozostawiłyby nierozstrzygnięte kluczowe pytanie. Proces mógłby generować użyteczne propozycje, mając jednocześnie trudności ze spełnieniem wymagań akceptacyjnych. Taki wynik wskazywałby ograniczenie dostarczania, a nie dowodził, że każda transformacja jest bezwartościowa.

Trzecim sygnałem jest obciążenie utrzymaniowe po wdrożeniu. Czytelnicy powinni obserwować dowody dotyczące późniejszych poprawek, potrzeb wsparcia oraz możliwości wycofania starej implementacji. Wyniki te pokazują, czy modernizacja redukuje pracę, czy jedynie przenosi ją gdzie indziej.

Zmiana, która pozostaje stabilna i upraszcza przyszłe utrzymanie, wspierałaby założenie projektu. Zmiana wymagająca rozległej, powtarzalnej interwencji osłabiałaby je. Żaden z tych wniosków nie powinien opierać się wyłącznie na szybkości pojawienia się pierwszego zastąpienia.

Sygnały te zapewniają również lepsze ramy dla nabywców korporacyjnych oceniających twierdzenia o modernizacji z AI. Poproście dostawców o rozdzielenie proponowanych zmian od wdrożonych zmian oraz wdrożonych zmian od trwałych usprawnień. Poproście o wystarczająco dużo szczegółów, aby zrozumieć, które obciążenia pracą przyniosły raportowany wynik.

Dla liderów inżynieryjnych natychmiastowym działaniem jest zbadanie ograniczonego problemu utrzymaniowego we własnej organizacji. Ustalcie istniejący standard akceptacji, zidentyfikujcie osoby rozumiejące jego ograniczenia i zmierzcie pełną ścieżkę do wdrożenia. Porównajcie nakład pracy na przegląd i korekty z szybkością generowania. Zapiszcie założenia, które ograniczałyby możliwość powtórzenia wyniku w innym miejscu. Przepisanie kodu Cisco z użyciem AI zasługuje na uwagę, ponieważ testuje, jak daleko wsparcie kadry kierowniczej i nieograniczone eksperymentowanie mogą posunąć modernizację oprogramowania. Jego ostateczne znaczenie będzie zależeć od tego, co pozostanie niezawodne po początkowym entuzjazmie. Gdy nadejdzie kolejna aktualizacja, zadajcie konkretne pytanie: która zaakceptowana zmiana ułatwiła utrzymanie oprogramowania i jakie dowody wspierają ten osąd?