A reescrita de código com IA da Cisco coloca uma meta de 98% por trás de tokens ilimitados
A Cisco teria dado a um engenheiro de 27 anos tokens de IA ilimitados para buscar a reescrita de 98% de seu código legado em 24 meses. A reescrita de código com IA da Cisco combina uma meta excepcionalmente ampla com uma pequena equipe proposta. Sua importância depende do que a Cisco pretende mudar e de como estabelecerá que as alterações funcionam.
Segundo a Tom’s Hardware, repercutindo uma reportagem da Fortune, o presidente e diretor de produtos Jeetu Patel apoiou o ex-fundador de startup Padmanabhan Krishnamurthy após uma conversa em San Francisco. A missão supostamente inclui um período inicial de prova de quatro semanas. Esses detalhes descrevem um experimento e uma ambição, e não resultados de modernização verificados de forma independente.
A tensão central é entre a geração irrestrita de código e a entrega responsável de software. A Amazon já descreveu atualizações de aplicações assistidas por IA, oferecendo uma comparação útil. A ambição atribuída à Cisco levanta uma questão mais ampla: quanta responsabilidade organizacional uma pequena equipe de engenharia pode absorver quando gerar alterações se torna mais fácil?
A reescrita de código com IA da Cisco começa com uma meta, não com uma migração concluída
A missão relatada estabelece apoio executivo; não estabelece que a Cisco tenha modernizado seu software.
O relato da Tom’s Hardware sobre a missão de código legado identifica Krishnamurthy, conhecido como Paddy, como o engenheiro por trás da proposta. Ele teria sugerido uma equipe de duas pessoas. Patel forneceu o apoio, incluindo tokens irrestritos, as unidades de texto que os modelos de IA processam ao receber instruções e gerar respostas.
A reportagem diz que Krishnamurthy trabalhava anteriormente cinco níveis organizacionais abaixo de Patel. Seu relato apresenta o projeto tanto como uma mudança de responsabilidade quanto de ferramentas. Um ex-fundador receberia espaço para questionar pressupostos consolidados de engenharia.
Há um histórico de aquisição verificável de forma independente por trás dessa conexão. O aviso de aquisição da EzDubs da Cisco afirma que a transação foi concluída em 25 de novembro de 2025. A Cisco descreveu a EzDubs como uma empresa de software de IA especializada em tradução de fala em tempo real. A justificativa declarada incluía expandir talentos de engenharia de colaboração.
Esse histórico sustenta o relato de uma startup adquirida juntando-se à Cisco. Ele não valida de forma independente a proposta de reescrita nem sua viabilidade. O anúncio da aquisição trata de capacidades de colaboração, e não de um plano publicado para transformar o software legado da Cisco.
A redação da missão relatada também exige cautela. Refatoração significa alterar a estrutura interna do software preservando seu comportamento observável externamente. Reescrita pode envolver substituir uma implementação, potencialmente introduzindo escolhas de design e riscos de compatibilidade diferentes.
Esses termos podem descrever trabalhos sobrepostos, mas não são medidas intercambiáveis de progresso. Uma limpeza interna automatizada difere substancialmente da substituição de um componente do qual os clientes dependem. Um programa de modernização precisa identificar a qual categoria cada alteração pertence.
A cobertura pública não fornece um inventário detalhado por trás do número de 98%. Também não explica se a conclusão significa alterações geradas, alterações aceitas, implantação em produção ou aposentadoria de implementações antigas. Sem essas definições, o percentual comunica ambição com mais clareza do que escopo operacional.
A mesma cautela se aplica ao cronograma. Uma reportagem publicada em 30 de outubro de 2026 não estabelece que o cronômetro do projeto tenha começado naquele dia. Os leitores devem evitar calcular uma data exata de conclusão apenas a partir da data de publicação.
O ponto de partida útil é, portanto, limitado. O presidente da Cisco teria autorizado um experimento agressivo de engenharia com uma meta principal definida. Se esse experimento se tornará um programa de modernização repetível continua sendo uma questão separada.
Tokens ilimitados deslocam a pressão para revisão e responsabilidade
Remover um limite de geração altera onde o trabalho de engenharia se acumula; não elimina o trabalho necessário para aceitar uma alteração.
Tokens de IA ilimitados soam como capacidade de engenharia ilimitada porque a saída visível é código. Ainda assim, um patch gerado, uma alteração proposta em arquivos-fonte, precisa ter um motivo para existir. Alguém precisa estabelecer o que ele altera, por que é seguro e quem fará sua manutenção.
Considere uma modernização hipotética de um componente compartilhado de autenticação. Uma ferramenta de IA poderia sugerir código mais claro, dependências mais recentes e testes adicionais. Essa proposta ainda precisaria ser avaliada em relação às regras de permissão existentes e às configurações de clientes compatíveis.
Este exemplo é ilustrativo, e não uma descrição do projeto da Cisco. Ele mostra por que gerar software plausível e aceitar responsabilidade pelo comportamento implantado são atividades distintas. Uma redação mais rápida pode expor uma escassez de revisores, em vez de eliminar uma escassez de programadores.
Gerentes de engenharia enfrentam a pressão imediata. Se as alterações propostas chegam mais rápido do que as equipes conseguem avaliá-las, a fila de revisão cresce. Os gerentes precisam então decidir se restringem o trabalho, aumentam a capacidade de revisão ou mudam como as evidências acompanham cada proposta.
Especialistas em segurança enfrentam um problema relacionado. Eles precisam entender se o processo preserva limites de acesso e trata informações sensíveis de maneira apropriada. Um patch que parece mais limpo ainda pode mudar pressupostos antes aplicados indiretamente.
Responsáveis pelo produto devem distinguir melhorias internas de alterações que afetam os clientes. Substituir uma dependência, um componente externo de software, pode introduzir comportamentos além dos arquivos que uma ferramenta de IA edita diretamente. A aceitação, portanto, depende do sistema ao redor, não simplesmente da atratividade da substituição.
O patrocínio executivo importa porque essas responsabilidades atravessam linhas de reporte. Uma pequena equipe central pode desenvolver uma abordagem, mas as equipes afetadas ainda precisam de uma forma de aprovar as alterações. Autoridade pouco clara transformaria cada demonstração bem-sucedida em uma negociação sobre quem aceita as consequências.
Esse é o significado organizacional das ambições de reescrita de código com IA da Cisco. O experimento testa se uma pequena equipe consegue criar um processo no qual outras equipes confiem. Sua produção precisaria incluir evidências reproduzíveis, limites de mudança compreensíveis e caminhos claros para lidar com falhas.
Os mantenedores estabelecidos permanecem centrais nesse processo. Eles frequentemente sabem por que uma implementação complicada existe ou qual requisito de cliente explica uma ramificação incomum. Esse conhecimento é uma evidência útil, mesmo quando sugere que a implementação atual deveria mudar.
A documentação torna-se parte da questão da capacidade de engenharia. As equipes precisam ter acesso a decisões de design, históricos de incidentes e requisitos de compatibilidade antes de avaliar uma substituição proposta. Uma base de conhecimento de engenharia pesquisável aborda esse problema de informação junto ao fluxo de trabalho de programação.
A pressão resultante recai sobre ambos os lados do experimento. A pequena equipe precisa tornar seu trabalho revisável, enquanto as equipes estabelecidas precisam explicar objeções de forma concreta. Nem a geração irrestrita nem a experiência institucional fornecem uma resposta automática.
As atualizações de aplicações da Amazon oferecem uma comparação mais limitada
Uma migração delimitada fornece evidências mais claras do que um percentual que abrange um patrimônio de software indefinido.
A Amazon fornece um precedente do setor para a modernização assistida por IA. Em seu anúncio de transformação de aplicações de dezembro de 2024, a empresa descreveu a atualização de aplicações internas para Java 17. Java é uma linguagem de programação e ambiente de execução usado para software empresarial.
A Amazon afirmou que o esforço abrangeu dezenas de milhares de aplicações de produção e economizou mais de 4.500 anos de trabalho de desenvolvedores. Esses são resultados relatados pela empresa, e não uma avaliação independente. Ainda assim, eles descrevem uma transformação mais específica do que uma promessa geral de reescrever código legado.
Essa especificidade importa. Uma atualização de versão fornece um estado inicial e um estado-alvo identificáveis. Revisores podem examinar se uma aplicação compila, se o comportamento esperado permanece intacto e se o novo ambiente de execução atende aos seus requisitos.
Uma reescrita mais ampla pode combinar muitos objetivos diferentes. Ela pode envolver simplificar a arquitetura, substituir dependências, melhorar a capacidade de manutenção ou remover funcionalidades obsoletas. Cada objetivo exige seus próprios critérios de aceitação, mesmo quando as mesmas ferramentas de IA ajudam a produzir as alterações.
O fluxo de trabalho de atualização de Java da AWS também preserva uma etapa explícita de aceitação humana. Sua documentação descreve compilar o código original, realizar uma transformação e pedir ao desenvolvedor que verifique e aceite os resultados. Ela distingue alterações de compatibilidade da linguagem de atualizações adicionais de dependências.
Essa distinção é útil porque a modernização raramente é uma única operação. Uma atualização bem-sucedida da linguagem não estabelece que todas as bibliotecas estejam atualizadas. Uma compilação aprovada não estabelece que todos os fluxos de trabalho dos clientes se comportem corretamente.
O exemplo da Amazon, portanto, sustenta uma conclusão limitada: a transformação assistida por IA tem aplicações empresariais concretas com limites descritíveis. Ele não estabelece que a meta relatada da Cisco seja alcançável. Tampouco mostra que uma equipe de implementação minúscula possa realizar de forma independente todas as tarefas de aceitação associadas.
Há também uma lição sobre medição. O tempo estimado de desenvolvedores economizado depende de um processo alternativo presumido. Essa estimativa se torna mais informativa quando acompanhada por aplicações implantadas, alterações aceitas e desempenho operacional contínuo.
O experimento da Cisco se beneficiaria de uma divulgação igualmente concreta. Uma descrição da carga de trabalho inicial revelaria se a equipe está testando uma transformação repetível ou explorando um redesenho mais amplo. Ambos podem valer a pena, mas carregam incertezas diferentes.
Para compradores empresariais, essa distinção afeta como interpretar alegações de fornecedores. Uma demonstração interna é evidência sobre um processo específico em um ambiente específico. Uma capacidade de cliente com suporte exige compromissos adicionais em torno de manutenção, documentação e tratamento de falhas.
A pressão competitiva envolve evidências tanto quanto velocidade. Empresas que discutem modernização com IA precisam explicar cada vez mais o que foi transformado e como a aceitação funcionou. Um percentual dramático em uma manchete fornece menos informações úteis do que um resultado claramente delimitado.
A comparação também mantém a história da Cisco ancorada. Sua importância vem de testar se um patrocínio executivo agressivo pode expandir o alcance da engenharia assistida por IA. A experiência da Amazon fornece contexto sem resolver esse experimento antecipadamente.
O número de 98% precisa de uma definição antes de se tornar uma métrica útil
Uma porcentagem de modernização só se torna significativa quando os leitores sabem o que conta para a conclusão.
Uma porcentagem precisa de um denominador, a quantidade total em relação à qual o progresso é medido. Nesta iniciativa, essa quantidade pode ser linhas de código-fonte, repositórios, aplicações ou componentes selecionados. A reportagem não estabelece qual interpretação se aplica.
Essas escolhas podem produzir retratos muito diferentes do progresso. Reformatar arquivos pode afetar muitas linhas de código-fonte sem alterar a manutenibilidade. Substituir um componente pequeno, mas central, pode exigir validação extensa enquanto afeta relativamente pouco código.
A regra de conclusão importa tanto quanto. Gerar uma alteração proposta é uma etapa intermediária. Aceitá-la no repositório de código-fonte é outra etapa, enquanto implantá-la e desativar a implementação antiga exigem trabalho adicional.
Isso não torna a ambição de 98% inerentemente desarrazoada. Torna a ambição difícil de avaliar a partir da descrição pública. Os leitores precisam de definições de escopo e aceitação antes de interpretá-la como uma previsão de engenharia.
A linguagem de refatoração cria outro desafio de medição. A preservação de comportamento é central à refatoração, mas os testes existentes examinam apenas o comportamento que cobrem. Uma execução bem-sucedida de testes não pode estabelecer que toda condição não testada permaneceu inalterada.
Essa lacuna explica por que a revisão e a observação operacional importam. Uma regressão, uma perda não intencional de comportamento existente, pode surgir fora dos cenários representados em testes automatizados. A confiança vem da combinação de evidências, e não de tratar qualquer verificação individual como conclusiva.
Pesquisas também alertam contra equiparar a sensação de velocidade à produtividade medida. O experimento de produtividade de desenvolvedores da METR examinou 16 desenvolvedores experientes concluindo 246 tarefas em projetos open source que já conheciam. Permitir o uso de ferramentas de IA do início de 2025 aumentou o tempo de conclusão em 19%.
Ainda assim, os participantes acreditavam que as ferramentas os tinham ajudado a terminar mais rápido. A descoberta ilustra por que conveniência percebida e velocidade de entrega medida exigem avaliação separada. Ela não prevê os resultados da Cisco nem estabelece que ferramentas de IA posteriores tenham as mesmas limitações.
A METR posteriormente enfatizou essa distinção. Sua atualização do desenho experimental de fevereiro de 2026 descreveu dificuldades para interpretar medições mais recentes porque a participação e a seleção de tarefas haviam mudado. Os pesquisadores consideraram plausível uma maior velocidade, ao mesmo tempo em que alertaram que as evidências disponíveis não podiam estabelecer com precisão o ganho.
Em conjunto, essas descobertas sustentam uma medição cuidadosa, em vez de um veredito universal sobre programação com IA. As capacidades das ferramentas mudam, e diferentes tarefas expõem diferentes restrições. Resultados de manutenção familiar de projetos open source não podem simplesmente ser transferidos para o programa de modernização de uma grande empresa.
Para a Cisco, a questão relevante é se o processo completo melhora. Uma geração mais rápida teria valor limitado se a revisão e a correção consumissem o tempo economizado. Por outro lado, um processo confiável poderia gerar valor mesmo que deliberadamente deixasse uma quantidade substancial de código intocada.
Uma avaliação crível, portanto, distinguiria atividade de resultados. Patches propostos mostram atividade; transformações aceitas mostram progresso após a revisão. Implantação estável e menor carga de manutenção fornecem evidências mais fortes de que o trabalho cumpriu seu objetivo.
Tokens ilimitados removem uma possível restrição à experimentação. Eles não resolvem essas questões de medição. A meta divulgada se torna mais informativa quando a Cisco explica como distinguirá uma demonstração impressionante de uma melhoria sustentada de engenharia.
Uma equipe pequena ainda precisa de acesso ao conhecimento institucional
A versão mais sólida deste experimento combina liberdade para redesenhar com acesso às razões pelas quais o software existente se comporta como se comporta.
A história sobre a equipe convida a uma interpretação geracional simples. Um fundador jovem desafia premissas que uma grande organização aceitou. Esse enquadramento capta a mudança de oportunidade relatada, mas não pode estabelecer quais julgamentos de engenharia estão corretos.
A juventude não produz automaticamente uma arquitetura sólida, assim como tempo de casa não justifica automaticamente a preservação de uma implementação. A distinção útil é se uma proposta resiste ao escrutínio. Uma equipe pequena precisa de liberdade suficiente para testar ideias e de contexto suficiente para interpretar os resultados.
A experiência relatada de Krishnamurthy como fundador é relevante para essa questão organizacional. A vivência em startups pode incentivar atenção ao problema como um todo, em vez de a uma tarefa atribuída de forma restrita. Ainda assim, ela não substitui a compreensão dos sistemas afetados por uma mudança.
O conhecimento institucional pode explicar ineficiências aparentes. Uma sequência incomum de tentativas pode acomodar uma condição operacional específica. Uma verificação redundante pode proteger uma integração mais antiga. Estes são exemplos hipotéticos, não recursos identificados do software da Cisco.
Sempre que possível, essas explicações devem se tornar requisitos testáveis. Caso contrário, a modernização depende de encontrar a pessoa que se lembra de uma decisão antiga. Registrar o motivo permite que uma nova implementação preserve o comportamento necessário enquanto questiona o projeto original.
A obrigação inversa também importa. Equipes estabelecidas devem distinguir requisitos documentados de hábitos que sobreviveram sem exame. Uma objeção se torna acionável quando identifica uma condição de falha ou um critério de aceitação.
É aqui que o apoio executivo pode ajudar sem substituir o julgamento de engenharia. A liderança pode autorizar o acesso, resolver disputas de responsabilidade e proteger tempo para avaliação. Ela não pode estabelecer correção por meio de entusiasmo nem fazer de um prazo um substituto para evidências.
A contribuição mais valiosa de uma equipe pequena pode, portanto, ser um processo repetível, e não uma grande quantidade de código substituto. Esse processo conectaria transformações propostas a requisitos relevantes e a um caminho claro de aprovação. Outras equipes poderiam então avaliar trabalhos semelhantes sem reconstruir o procedimento.
Essa possibilidade muda a forma de interpretar o nível de pessoal proposto. Uma equipe compacta pode desenvolver métodos de transformação e coordenar a adoção. Isso é diferente de afirmar que essas pessoas, sozinhas, podem assumir toda responsabilidade por testes, segurança, suporte e manutenção.
Também limita o que a história diz sobre emprego de nível inicial. Dar responsabilidade incomum a um fundador adquirido não estabelece um padrão geral de contratação. O caso oferece evidências sobre uma decisão gerencial específica, e não sobre um resultado do mercado de trabalho.
Para desenvolvedores, a implicação prática diz respeito ao trabalho que circunda o código gerado. Entender requisitos, explicar trade-offs e estabelecer evidências continuam necessários quando a redação se torna mais fácil. Essas responsabilidades ficam mais visíveis quando um projeto tenta realizar mudanças além das fronteiras organizacionais.
Para trabalhadores do conhecimento de forma mais ampla, o paralelo é o acesso ao contexto. Um sistema de IA pode produzir uma resposta plausível enquanto ignora o motivo pelo qual uma decisão anterior importava. A automação útil precisa de uma forma de recuperar esse motivo e expor a incerteza.
O experimento da Cisco é, portanto, também um teste de aprendizado organizacional. Suas perspectivas melhoram se uma equipe pequena puder transformar conhecimento disperso em evidências de aceitação reutilizáveis. Elas enfraquecem se o projeto tratar mantenedores experientes apenas como obstáculos a uma produção mais rápida.
Observe as evidências do piloto, a aceitação em produção e a carga de manutenção
A próxima atualização útil explicaria o que passou pela avaliação, quem o aceitou e o que aconteceu depois.
A reescrita de código com IA da Cisco se tornará mais fácil de avaliar por meio de evidências concretas nos próximos meses. O período de prova de quatro semanas relatado dá aos leitores um ponto de referência de curto prazo. No entanto, a reportagem não estabelece sua data exata de início nem promete uma divulgação pública.
O primeiro sinal é uma descrição do escopo e dos resultados do piloto. Os leitores devem procurar uma carga de trabalho identificável, um objetivo de transformação declarado e critérios de aceitação. Esses detalhes mostrariam se a equipe testou algo representativo da ambição mais ampla.
Uma demonstração bem-sucedida fortaleceria o argumento se expusesse tanto conquistas quanto limitações. Por exemplo, informar quais mudanças exigiram correção humana ajudaria a estabelecer as exigências reais do processo. Este é um padrão de evidência, e não uma previsão sobre o que a Cisco divulgará.
Uma demonstração que mostre apenas código recém-gerado ofereceria um suporte mais fraco. Ela demonstraria produção sem explicar compatibilidade ou aceitação. A diferença importa porque a meta de longo prazo diz respeito a mudar software existente, e não a produzir um exemplo independente.
O segundo sinal é a aceitação em um processo de entrega de produção. Os leitores devem procurar confirmação de que equipes responsáveis aprovaram uma transformação delimitada e a implantaram. Um procedimento de reversão, uma forma definida de restaurar uma versão anterior, esclareceria ainda mais como o programa lida com falhas.
Esse sinal fortaleceria o caso da modernização porque conecta o experimento às responsabilidades operacionais. Mostraria que as equipes afetadas podem avaliar o trabalho, em vez de apenas admirá-lo. A aprovação ainda precisaria ser interpretada dentro do escopo dessa implantação.
Por outro lado, demonstrações repetidas sem implantação deixariam uma questão central sem resposta. O processo poderia gerar propostas úteis enquanto enfrenta dificuldades para satisfazer requisitos de aceitação. Esse resultado identificaria uma restrição de entrega, em vez de provar que toda transformação carece de valor.
O terceiro sinal é a carga de manutenção após a implantação. Os leitores devem observar evidências sobre correções subsequentes, demandas de suporte e se a implementação antiga pode ser desativada. Esses resultados revelam se a modernização reduz trabalho ou simplesmente o transfere para outro lugar.
Uma mudança que permaneça estável e simplifique a manutenção futura apoiaria a premissa do projeto. Uma mudança que exija intervenção recorrente extensa a enfraqueceria. Nenhuma conclusão deve se basear apenas na rapidez com que a primeira substituição surgiu.
Esses sinais também oferecem uma estrutura melhor para compradores corporativos que avaliam alegações sobre modernização com IA. Peça aos fornecedores que separem mudanças propostas de mudanças implantadas e mudanças implantadas de melhorias duradouras. Solicite detalhes suficientes para entender quais cargas de trabalho produziram o resultado relatado.
Para líderes de engenharia, a ação imediata é examinar um problema de manutenção delimitado em sua própria organização. Estabeleça o padrão de aceitação existente, identifique as pessoas que entendem suas restrições e meça o caminho completo até a implantação. Compare o esforço de revisão e correção com a velocidade de geração. Registre as premissas que limitariam a repetição do resultado em outro contexto. A reescrita de código com IA da Cisco merece atenção porque testa até onde o apoio executivo e a experimentação irrestrita podem levar a modernização de software. Sua importância final dependerá do que permanecer confiável após a empolgação inicial. Quando chegar a próxima atualização, faça uma pergunta concreta: qual mudança aceita tornou o software mais fácil de manter, e que evidência sustenta esse julgamento?
