La riscrittura del codice AI di Cisco punta al 98% con token illimitati

Secondo quanto riportato, Cisco avrebbe assegnato a un ingegnere di 27 anni token AI illimitati per riscrivere il 98% del proprio codice legacy entro 24 mesi. La riscrittura del codice AI di Cisco combina un obiettivo insolitamente ampio con un piccolo team proposto. La sua rilevanza dipende da ciò che Cisco intende modificare e da come stabilirà che le modifiche funzionano.

Secondo Tom’s Hardware, che rilancia un servizio di Fortune, il presidente e chief product officer Jeetu Patel avrebbe sostenuto l'ex fondatore di startup Padmanabhan Krishnamurthy dopo una conversazione a San Francisco. L'incarico includerebbe un periodo iniziale di prova di quattro settimane. Questi dettagli descrivono un esperimento e un'ambizione, piuttosto che risultati di modernizzazione verificati in modo indipendente.

La tensione centrale riguarda la generazione di codice senza restrizioni rispetto a una distribuzione del software responsabile. Amazon ha già illustrato aggiornamenti di applicazioni assistiti dall'AI, offrendo un confronto utile. L'ambizione attribuita a Cisco solleva una questione più ampia: quanta responsabilità organizzativa può assorbire un piccolo team di ingegneri quando generare modifiche diventa più facile?

La riscrittura del codice AI di Cisco parte da un obiettivo, non da una migrazione conclusa

L'incarico riportato dimostra il sostegno dei vertici; non dimostra che Cisco abbia modernizzato il proprio software.

Il resoconto di Tom’s Hardware sull'incarico relativo al codice legacy identifica Krishnamurthy, noto come Paddy, come l'ingegnere autore della proposta. Avrebbe suggerito un team di due persone. Patel avrebbe fornito il sostegno, inclusi token senza limiti, le unità di testo che i modelli AI elaborano quando ricevono istruzioni e generano risposte.

Il rapporto afferma che Krishnamurthy lavorava in precedenza cinque livelli organizzativi sotto Patel. Il resoconto presenta il progetto come un cambiamento nelle responsabilità tanto quanto negli strumenti. Un ex fondatore avrebbe avuto spazio per mettere in discussione presupposti ingegneristici consolidati.

Esiste una storia di acquisizione verificabile in modo indipendente alla base di quel collegamento. L'avviso di acquisizione di EzDubs di Cisco afferma che la transazione si è conclusa il 25 novembre 2025. Cisco ha descritto EzDubs come una società di software AI specializzata nella traduzione vocale in tempo reale. Tra le motivazioni dichiarate figurava l'espansione dei talenti nell'ingegneria della collaborazione.

Questa storia sostiene il resoconto di una startup acquisita entrata in Cisco. Non convalida in modo indipendente la proposta di riscrittura né la sua fattibilità. L'annuncio dell'acquisizione riguarda capacità di collaborazione, non un piano pubblicato per trasformare il software legacy di Cisco.

Anche la formulazione dell'incarico riportato richiede cautela. Il refactoring consiste nel modificare la struttura interna del software preservandone il comportamento osservabile esternamente. Una riscrittura può comportare la sostituzione di un'implementazione, introducendo potenzialmente scelte progettuali e rischi di compatibilità diversi.

Questi termini possono descrivere lavori sovrapposti, ma non sono misure intercambiabili dei progressi. Una pulizia interna automatizzata differisce sostanzialmente dalla sostituzione di un componente da cui dipendono i clienti. Un programma di modernizzazione deve identificare a quale categoria appartiene ciascuna modifica.

Le informazioni pubbliche non forniscono un inventario dettagliato alla base della cifra del 98%. Non spiegano nemmeno se il completamento significhi modifiche generate, modifiche accettate, distribuzione in produzione o dismissione delle vecchie implementazioni. Senza tali definizioni, la percentuale comunica l'ambizione più chiaramente dell'ambito operativo.

La stessa cautela vale per la tempistica. Un articolo pubblicato il 30 ottobre 2026 non dimostra che il cronometro del progetto sia partito quel giorno. I lettori dovrebbero evitare di calcolare una data di completamento esatta basandosi esclusivamente sulla data di pubblicazione.

Il punto di partenza utile è quindi circoscritto. Il presidente di Cisco avrebbe autorizzato un aggressivo esperimento ingegneristico con un obiettivo dichiarato. Resta una questione distinta se tale esperimento diventerà un programma di modernizzazione ripetibile.

I token illimitati spostano la pressione verso revisione e responsabilità

Rimuovere un limite alla generazione cambia dove si accumula il lavoro ingegneristico; non elimina il lavoro necessario per accettare una modifica.

I token AI illimitati sembrano capacità ingegneristica illimitata perché l'output visibile è il codice. Tuttavia, una patch generata, una modifica proposta ai file sorgente, deve comunque avere una ragione d'essere. Qualcuno deve stabilire cosa modifica, perché è sicura e chi la manterrà.

Si consideri un'ipotetica modernizzazione di un componente di autenticazione condiviso. Uno strumento AI potrebbe suggerire codice più chiaro, dipendenze più recenti e test aggiuntivi. Quella proposta dovrebbe comunque essere valutata rispetto alle regole di autorizzazione esistenti e alle configurazioni dei clienti supportate.

Questo esempio è illustrativo, non una descrizione del progetto di Cisco. Mostra perché generare software plausibile e assumersi la responsabilità del comportamento distribuito sono attività diverse. Una redazione più rapida può rivelare una carenza di revisori anziché eliminare una carenza di programmatori.

I responsabili dell'ingegneria affrontano la pressione immediata. Se le modifiche proposte arrivano più velocemente di quanto i team possano valutarle, la coda delle revisioni cresce. I responsabili devono quindi decidere se restringere il lavoro, aumentare la capacità di revisione o modificare il modo in cui le prove accompagnano ciascuna proposta.

Gli specialisti della sicurezza affrontano un problema correlato. Devono capire se il processo preserva i confini di accesso e gestisce le informazioni sensibili in modo appropriato. Una patch che appare più pulita può comunque modificare assunzioni precedentemente applicate in modo indiretto.

I responsabili di prodotto devono distinguere i miglioramenti interni dalle modifiche che riguardano i clienti. Sostituire una dipendenza, un componente software esterno, può introdurre comportamenti che vanno oltre i file modificati direttamente da uno strumento AI. L'accettazione dipende quindi dal sistema circostante, non semplicemente dall'attrattiva della sostituzione.

Il sostegno dei vertici è importante perché queste responsabilità attraversano le linee gerarchiche. Un piccolo team centrale può sviluppare un approccio, ma i team coinvolti necessitano comunque di un modo per approvare le modifiche. Un'autorità poco chiara trasformerebbe ogni dimostrazione riuscita in una negoziazione su chi accetta le conseguenze.

Questo è il significato organizzativo delle ambizioni di riscrittura del codice AI di Cisco. L'esperimento verifica se un piccolo team possa creare un processo di cui gli altri team si fidino. Il suo output dovrebbe includere prove riproducibili, confini delle modifiche comprensibili e percorsi chiari per gestire i guasti.

I manutentori affermati restano centrali in questo processo. Spesso sanno perché esiste un'implementazione scomoda o quale requisito del cliente spiega un ramo insolito. Questa conoscenza è una prova utile, anche quando suggerisce che l'implementazione attuale dovrebbe cambiare.

La documentazione diventa parte della questione sulla capacità ingegneristica. I team necessitano di accesso a decisioni progettuali, cronologie degli incidenti e requisiti di compatibilità prima di valutare una sostituzione proposta. Una base di conoscenza ingegneristica ricercabile affronta questo problema informativo insieme al flusso di lavoro di programmazione.

La pressione risultante ricade su entrambi i lati dell'esperimento. Il piccolo team deve rendere il proprio lavoro verificabile, mentre i team consolidati devono spiegare concretamente le proprie obiezioni. Né la generazione senza restrizioni né l'esperienza istituzionale forniscono una risposta automatica.

Gli aggiornamenti delle applicazioni di Amazon offrono un confronto più ristretto

Una migrazione delimitata fornisce prove più chiare di una percentuale che copre un patrimonio software non definito.

Amazon offre un precedente di settore per la modernizzazione assistita dall'AI. Nel suo annuncio sulla trasformazione delle applicazioni del dicembre 2024, l'azienda ha descritto l'aggiornamento di applicazioni interne a Java 17. Java è un linguaggio di programmazione e runtime utilizzato per il software aziendale.

Amazon ha dichiarato che l'iniziativa ha riguardato decine di migliaia di applicazioni di produzione e ha risparmiato oltre 4.500 anni-persona di lavoro degli sviluppatori. Si tratta di risultati dichiarati dall'azienda, non di una valutazione indipendente. Ciononostante, descrivono una trasformazione più specifica di una promessa generale di riscrivere il codice legacy.

Questa specificità è importante. Un aggiornamento di versione fornisce uno stato iniziale e uno stato finale identificabili. I revisori possono verificare se un'applicazione viene compilata, se il comportamento previsto rimane intatto e se il nuovo runtime supporta i suoi requisiti.

Una riscrittura più ampia può combinare molti obiettivi diversi. Potrebbe comportare la semplificazione dell'architettura, la sostituzione delle dipendenze, il miglioramento della manutenibilità o la rimozione di funzionalità obsolete. Ogni obiettivo richiede i propri criteri di accettazione, anche quando gli stessi strumenti AI aiutano a produrre le modifiche.

Il flusso di lavoro per l'aggiornamento Java di AWS conserva inoltre un passaggio esplicito di accettazione umana. La documentazione descrive la compilazione del codice originale, l'esecuzione di una trasformazione e la richiesta allo sviluppatore di verificare e accettare i risultati. Distingue le modifiche alla compatibilità del linguaggio dagli ulteriori aggiornamenti delle dipendenze.

Questa distinzione è utile perché la modernizzazione raramente è una singola operazione. Un aggiornamento del linguaggio riuscito non dimostra che ogni libreria sia aggiornata. Una compilazione riuscita non dimostra che ogni flusso di lavoro del cliente si comporti correttamente.

L'esempio di Amazon sostiene quindi una conclusione limitata: la trasformazione assistita dall'AI ha applicazioni aziendali concrete con confini descrivibili. Non dimostra che l'obiettivo attribuito a Cisco sia realizzabile. Né mostra che un piccolo team di implementazione possa svolgere autonomamente ogni attività di accettazione associata.

Vi è anche un insegnamento sulla misurazione. Il tempo di sviluppo stimato risparmiato dipende da un processo alternativo ipotizzato. Tale stima diventa più informativa quando è accompagnata da applicazioni distribuite, modifiche accettate e prestazioni operative continuative.

L'esperimento di Cisco trarrebbe vantaggio da una rendicontazione altrettanto concreta. Una descrizione del carico di lavoro iniziale rivelerebbe se il team stia testando una trasformazione ripetibile o esplorando una riprogettazione più ampia. Entrambe possono essere valide, ma comportano incertezze diverse.

Per gli acquirenti aziendali, questa distinzione influisce sull'interpretazione delle affermazioni dei fornitori. Una dimostrazione interna costituisce prova di un processo particolare in un ambiente particolare. Una capacità supportata per i clienti richiede impegni aggiuntivi in materia di manutenzione, documentazione e gestione dei guasti.

La pressione competitiva riguarda le prove tanto quanto la velocità. Le aziende che parlano di modernizzazione AI devono sempre più spiegare cosa è stato trasformato e come ha funzionato l'accettazione. Una percentuale da titolo eclatante fornisce informazioni meno utili di un risultato chiaramente delimitato.

Il confronto mantiene inoltre la storia di Cisco con i piedi per terra. La sua rilevanza deriva dal verificare se un aggressivo sostegno dei vertici possa ampliare la portata dell'ingegneria assistita dall'AI. L'esperienza di Amazon offre contesto senza risolvere in anticipo quell'esperimento.

La cifra del 98% necessita di una definizione prima di diventare una metrica utile

Una percentuale di modernizzazione diventa significativa solo quando i lettori sanno cosa conta ai fini del completamento.

Una percentuale richiede un denominatore, ovvero la quantità totale rispetto alla quale si misura il progresso. Per questa iniziativa, tale quantità potrebbe essere costituita da righe di codice sorgente, repository, applicazioni o componenti selezionati. Il resoconto non chiarisce quale interpretazione si applichi.

Queste scelte possono produrre immagini molto diverse dell’avanzamento. Riformattare i file può coinvolgere molte righe di codice senza modificare la manutenibilità. Sostituire un componente piccolo ma centrale può richiedere una validazione approfondita pur interessando relativamente poco codice.

La regola di completamento conta altrettanto. Generare una modifica proposta è un passaggio intermedio. Accettarla nel repository sorgente è un altro passaggio, mentre distribuirla e dismettere la vecchia implementazione richiedono ulteriore lavoro.

Questo non rende l’obiettivo del 98% intrinsecamente irragionevole. Rende l’obizione difficile da valutare sulla base della descrizione pubblica. I lettori hanno bisogno di definizioni di ambito e accettazione prima di interpretarla come una previsione ingegneristica.

Il linguaggio del refactoring crea un’altra sfida di misurazione. La preservazione del comportamento è centrale nel refactoring, ma i test esistenti esaminano soltanto il comportamento che coprono. Un’esecuzione dei test riuscita non può dimostrare che ogni condizione non testata resti invariata.

Questo divario spiega perché la revisione e l’osservazione operativa siano importanti. Una regressione, ovvero una perdita involontaria di comportamenti esistenti, può comparire al di fuori degli scenari rappresentati nei test automatizzati. La fiducia deriva dalla combinazione delle evidenze, non dal trattare un singolo controllo come conclusivo.

La ricerca mette inoltre in guardia dall’equiparare la sensazione di velocità alla produttività misurata. L’esperimento sulla produttività degli sviluppatori di METR ha esaminato 16 sviluppatori esperti impegnati in 246 attività all’interno di progetti open source a loro familiari. Consentire l’uso di strumenti di IA dell’inizio del 2025 ha aumentato il tempo di completamento del 19%.

Ciononostante, i partecipanti ritenevano che gli strumenti li avessero aiutati a terminare più rapidamente. Il risultato illustra perché la praticità percepita e la velocità di consegna misurata richiedano valutazioni separate. Non predice i risultati di Cisco né stabilisce che gli strumenti di IA successivi presentino le stesse limitazioni.

METR ha successivamente sottolineato questa distinzione. Il suo aggiornamento sul disegno sperimentale del febbraio 2026 ha descritto le difficoltà nell’interpretare misurazioni più recenti, poiché erano cambiati sia la partecipazione sia la selezione delle attività. I ricercatori hanno ritenuto plausibile un miglioramento della velocità, avvertendo però che le evidenze disponibili non potevano quantificare con precisione il guadagno.

Nel loro insieme, questi risultati sostengono una misurazione prudente anziché un verdetto universale sulla programmazione con IA. Le capacità degli strumenti cambiano e compiti diversi espongono vincoli diversi. I risultati della manutenzione di progetti open source familiari non possono essere trasferiti semplicemente a un programma di modernizzazione di una grande azienda.

Per Cisco, la questione rilevante è se migliori il processo completo. Una generazione più rapida avrebbe valore limitato se revisione e correzione assorbissero il tempo risparmiato. Al contrario, un processo affidabile potrebbe produrre valore anche se lasciasse deliberatamente invariata una parte sostanziale del codice.

Una valutazione credibile distinguerebbe quindi l’attività dai risultati. Le patch proposte mostrano attività; le trasformazioni accettate mostrano avanzamento attraverso la revisione. Una distribuzione stabile e un minore onere di manutenzione forniscono prove più solide che il lavoro abbia raggiunto il suo scopo.

Token illimitati eliminano un potenziale vincolo alla sperimentazione. Non risolvono queste questioni di misurazione. L’obiettivo riportato diventa più informativo quando Cisco spiega come distinguerà una dimostrazione impressionante da un miglioramento ingegneristico duraturo.

Anche un piccolo team ha bisogno di accesso alla conoscenza istituzionale

La versione più solida di questo esperimento combina la libertà di riprogettare con l’accesso alle ragioni per cui il software esistente si comporta nel modo in cui si comporta.

La storia sul personale invita a una semplice interpretazione generazionale. Un giovane fondatore mette in discussione assunzioni che una grande organizzazione ha accettato. Questa cornice coglie il cambiamento di opportunità riportato, ma non può stabilire quali giudizi ingegneristici siano corretti.

La giovinezza non produce automaticamente un’architettura valida, così come l’anzianità non giustifica automaticamente la conservazione di un’implementazione. La distinzione utile è se una proposta resista all’esame. Un piccolo team ha bisogno di sufficiente libertà per testare le idee e di sufficiente contesto per interpretarne i risultati.

Il background da fondatore riportato per Krishnamurthy è rilevante per questa questione organizzativa. L’esperienza nelle startup può incoraggiare l’attenzione all’intero problema anziché a un compito assegnato in modo ristretto. Non sostituisce comunque la comprensione dei sistemi interessati da una modifica.

La conoscenza istituzionale può spiegare apparenti inefficienze. Una sequenza di tentativi insolita potrebbe adattarsi a una particolare condizione operativa. Un controllo ridondante potrebbe proteggere un’integrazione più datata. Questi sono esempi ipotetici, non caratteristiche identificate del software di Cisco.

Tali spiegazioni dovrebbero trasformarsi in requisiti verificabili, ove possibile. Altrimenti, la modernizzazione dipende dal rintracciare la persona che ricorda una vecchia decisione. Catturarne la ragione consente a una nuova implementazione di preservare il comportamento necessario, mettendo al contempo in discussione il progetto originario.

Anche l’obbligo inverso è importante. I team consolidati dovrebbero distinguere i requisiti documentati dalle abitudini sopravvissute senza esame. Un’obiezione diventa attuabile quando identifica una condizione di errore o un criterio di accettazione.

È qui che il sostegno dei dirigenti può aiutare senza sostituire il giudizio ingegneristico. La leadership può autorizzare l’accesso, risolvere controversie sulla titolarità e proteggere il tempo destinato alla valutazione. Non può stabilire la correttezza con l’entusiasmo né trasformare una scadenza in un sostituto dell’evidenza.

Il contributo più prezioso di un piccolo team potrebbe quindi essere un processo ripetibile, anziché una grande quantità di codice sostitutivo. Tale processo collegherebbe le trasformazioni proposte ai requisiti pertinenti e a un percorso di approvazione chiaro. Gli altri team potrebbero quindi valutare lavori simili senza dover ricostruire la procedura.

Questa possibilità modifica il modo in cui interpretare il livello di personale proposto. Un team compatto potrebbe sviluppare metodi di trasformazione e coordinarne l’adozione. Ciò è diverso dall’affermare che quelle persone possano da sole assumersi ogni responsabilità di test, sicurezza, supporto e manutenzione.

Limita inoltre ciò che questa storia dice sull’occupazione entry-level. Affidare a un fondatore acquisito responsabilità insolite non stabilisce un modello generale di assunzione. Il caso offre evidenza di una particolare decisione manageriale, piuttosto che di un esito del mercato del lavoro.

Per gli sviluppatori, l’implicazione pratica riguarda il lavoro che circonda il codice generato. Comprendere i requisiti, spiegare i compromessi e stabilire evidenze restano necessari quando la stesura diventa più semplice. Queste responsabilità diventano più visibili quando un progetto tenta cambiamenti oltre i confini organizzativi.

Per i knowledge worker più in generale, il parallelo riguarda l’accesso al contesto. Un sistema di IA può produrre una risposta plausibile senza cogliere il motivo per cui una decisione precedente fosse importante. Un’automazione utile necessita di un modo per recuperare tale ragione e rendere visibile l’incertezza.

L’esperimento di Cisco è quindi anche un test dell’apprendimento organizzativo. Le sue prospettive migliorano se un piccolo team riesce a trasformare conoscenze frammentarie in evidenze di accettazione riutilizzabili. Si indeboliscono se il progetto tratta i manutentori esperti esclusivamente come ostacoli a un output più rapido.

Osservate le evidenze del pilota, l’accettazione in produzione e l’onere di manutenzione

Il prossimo aggiornamento utile dovrebbe spiegare cosa ha superato la valutazione, chi lo ha accettato e cosa è accaduto in seguito.

La riscrittura del codice con IA di Cisco diventerà più facile da valutare attraverso evidenze concrete nei prossimi mesi. Il periodo di prova riportato di quattro settimane offre ai lettori un punto di riferimento a breve termine. Tuttavia, il resoconto non ne stabilisce la data di inizio esatta né promette una pubblicazione pubblica.

Il primo segnale è una descrizione dell’ambito e dei risultati del pilota. I lettori dovrebbero cercare un carico di lavoro identificabile, un obiettivo di trasformazione dichiarato e criteri di accettazione. Questi dettagli mostrerebbero se il team ha testato qualcosa di rappresentativo dell’ambizione più ampia.

Una dimostrazione riuscita rafforzerebbe il caso se rendesse visibili sia i risultati sia i limiti. Per esempio, riferire quali modifiche hanno richiesto correzioni umane contribuirebbe a definire le effettive esigenze del processo. Si tratta di uno standard di evidenza, non di una previsione su ciò che Cisco divulgherà.

Una demo che mostrasse solo codice appena generato fornirebbe un supporto più debole. Dimostrerebbe l’output senza spiegare la compatibilità o l’accettazione. La differenza conta perché l’obiettivo a lungo termine riguarda la modifica del software esistente, non la produzione di un esempio autonomo.

Il secondo segnale è l’accettazione in un processo di consegna in produzione. I lettori dovrebbero cercare conferma che team responsabili abbiano approvato una trasformazione circoscritta e l’abbiano distribuita. Una procedura di rollback, un modo definito per ripristinare una versione precedente, chiarirebbe ulteriormente come il programma gestisce gli errori.

Questo segnale rafforzerebbe il caso della modernizzazione perché collega l’esperimento alle responsabilità operative. Mostrerebbe che i team interessati possono valutare il lavoro anziché limitarsi ad ammirarlo. L’approvazione dovrebbe comunque essere interpretata nel perimetro di quella distribuzione.

Al contrario, dimostrazioni ripetute senza distribuzione lascerebbero irrisolta una questione centrale. Il processo potrebbe generare proposte utili, pur faticando a soddisfare i requisiti di accettazione. Tale esito identificherebbe un vincolo di consegna, anziché dimostrare che ogni trasformazione sia priva di valore.

Il terzo segnale è l’onere di manutenzione dopo la distribuzione. I lettori dovrebbero osservare evidenze riguardo alle correzioni successive, alle richieste di supporto e alla possibilità di dismettere la vecchia implementazione. Questi risultati rivelano se la modernizzazione riduce il lavoro oppure lo sposta semplicemente altrove.

Una modifica che rimanga stabile e semplifichi la manutenzione futura sosterrebbe la premessa del progetto. Una modifica che richieda un ampio intervento ricorrente la indebolirebbe. Nessuna delle due conclusioni dovrebbe basarsi soltanto sulla rapidità con cui è apparsa la prima sostituzione.

Questi segnali offrono inoltre un quadro migliore per gli acquirenti aziendali che valutano le affermazioni sulla modernizzazione con IA. Chiedete ai fornitori di separare le modifiche proposte da quelle distribuite, e le modifiche distribuite dai miglioramenti duraturi. Richiedete dettagli sufficienti per comprendere quali carichi di lavoro abbiano prodotto il risultato riportato.

Per i responsabili dell’ingegneria, l’azione immediata consiste nell’esaminare un problema di manutenzione circoscritto nella propria organizzazione. Stabilite lo standard di accettazione esistente, identificate le persone che ne comprendono i vincoli e misurate l’intero percorso fino alla distribuzione. Confrontate l’impegno di revisione e correzione insieme alla velocità di generazione. Registrate le assunzioni che limiterebbero la ripetizione del risultato altrove. La riscrittura del codice con IA di Cisco merita attenzione perché mette alla prova fino a che punto il sostegno dei dirigenti e una sperimentazione senza restrizioni possano estendere la modernizzazione del software. La sua importanza finale dipenderà da ciò che resterà affidabile dopo l’entusiasmo iniziale. Quando arriverà il prossimo aggiornamento, ponete una domanda concreta: quale modifica accettata ha reso il software più facile da mantenere, e quali evidenze sostengono tale giudizio?