Presidente da Cisco tirou o teto de tokens de uma reescrita legada. O orçamento real é verificação.

TV
Thiago Victorino
6 min de leitura
Presidente da Cisco tirou o teto de tokens de uma reescrita legada. O orçamento real é verificação.

“Dei a ele tokens ilimitados porque ele vai refatorar código. Então eu falei: pode ir, pode enlouquecer.”

Quem disse foi Jeetu Patel, presidente e diretor de produto da Cisco, à Fortune, num pequeno jantar em formato de mesa-redonda. O “ele” é Padmanabhan “Paddy” Krishnamurthy, 27 anos, que entrou na Cisco em 2025 quando a empresa comprou a EzDubs, startup de tradução em tempo real que ele cofundou em 2023. Patel contou que o encontrou “enterrado na organização fazendo algo sem importância estratégica”, cinco níveis abaixo dele. A meta, segundo Fortune e Tom’s Hardware: refatorar 98% do código legado da Cisco em 24 meses, depois de uma prova de conceito de quatro semanas.

Krishnamurthy calculou que faria a reescrita com uma equipe de duas pessoas. Patel disse à Fortune que nem as pessoas mais avançadas em IA do próprio time dele pensavam assim.

A Fortune conta a história como um caso de talento e de conflito de gerações. Nosso recorte é mais estreito. Quando um executivo tira o limite de tokens de uma reescrita legada, ele remove a restrição que costuma obrigar o time a escolher o que reescrever e com quanto cuidado. Alguma coisa precisa ocupar esse lugar. A reportagem traz uma meta de geração e nenhuma meta de verificação, e é nessa assimetria que uma reescrita desse tamanho dá certo ou falha em silêncio.

O que os tokens ilimitados de fato removem

Refatorações grandes costumam ter orçamento, e na nossa experiência ele faz um trabalho de governança que raramente fica escrito. Quando gerar código custa dinheiro, o time prioriza. Escolhe os módulos em que a reescrita se paga. Para quando o próximo módulo deixa de valer o custo. O custo funciona como um filtro tosco de escopo.

Sem custo, o filtro some junto. A velocidade com que código novo aparece passa a depender só de quanto os modelos, e as pessoas que os conduzem, conseguem produzir. Numa base de código do tamanho de uma empresa que a Fortune descreve como uma gigante de tecnologia de US$ 429 bilhões, essa velocidade pode ser muito alta.

A velocidade com que uma pessoa dona do comportamento consegue confirmar que o código novo faz o que o antigo fazia não acompanha o medidor de tokens. Máquinas podem gerar testes e comparar saídas, e tokens ilimitados também barateiam isso. Alguém ainda precisa ler os diffs que importam e decidir quais diferenças são bugs e quais são correções.

A restrição que manda mudou de lugar. Antes era gasto. Agora é prova.

Uma meta que mede o lado errado

“Refatorar 98% do código legado” é uma métrica de geração. Conta quanto código foi reescrito. Nada diz sobre quanto código reescrito já mostrou se comportar como aquilo que substituiu.

Nem a matéria da Fortune nem a versão da Tom’s Hardware relatam como o código reescrito será testado, revisado ou comparado com o comportamento legado. Nenhuma das duas traz valor de gasto com tokens. Disso não se conclui que a Cisco esteja sem plano. As informações vêm de uma entrevista num jantar, a Tom’s Hardware reescreve a Fortune e nada aqui é anúncio da Cisco. Mas a única meta na reportagem é a que mede produção.

Um placar de percentual refatorado tem um modo de falha previsível. Ele sobe na velocidade da geração de código, e com prazo fixo a pressão é para que continue subindo. A verificação sobe na velocidade dos testes, dos revisores e da evidência de produção. Se o painel mostra o primeiro número, o programa vai relatar progresso muito antes de alguém saber se esse progresso é real. Numa base de código desse tamanho, a distância entre os dois números é onde moram os incidentes.

Já olhamos para parentes desse problema. O uso de tokens tratado como métrica de vaidade é o tema do nosso texto sobre o placar de tokens da Meta. Se o código de IA entregue sobrevive é o tema do nosso texto sobre churn de código. Uma reescrita legada sem teto de gasto é um caso mais agudo, porque volume é a meta declarada e o custo deixou de segurá-lo.

O contexto que a Tom’s Hardware acrescentou

A Tom’s Hardware colocou a história da Cisco ao lado de reportagens anteriores dela mesma. Lembrou que o GitHub precisou colocar em operação 4 milhões de núcleos de CPU extras e 160 petabytes de armazenamento para dar conta da atividade de programação com IA, e que há relatos de agentes de código de IA apagando bancos de dados e ambientes de produção de empresas.

Nenhum desses fatos é sobre a Cisco. Juntos, eles descrevem o ambiente em que qualquer reescrita com tokens ilimitados acontece: geração numa escala que pressiona a infraestrutura e agentes capazes de causar estrago real quando nada os confere. Uma base de código legada grande é exatamente o tipo de sistema em que uma mudança sem verificação pode sair cara.

As quatro semanas são o momento da governança

A prova de conceito é a parte mais útil do plano, porque pode ser nela que as regras de pontuação são definidas. O que as quatro semanas medirem vira, na prática, o que o resto do programa vai otimizar.

Uma prova de conceito pontuada por volume vai mostrar que o time reescreve muito código depressa. A pergunta em aberto é outra: se a equipe de duas pessoas que Krishnamurthy diz bastar, com geração ilimitada, consegue produzir código reescrito comprovadamente equivalente ao comportamento legado, num ritmo que acompanhe a geração.

Uma prova de conceito montada para responder a isso mediria algumas coisas específicas.

Equivalência de comportamento numa fatia. Escolha uma parte delimitada do código legado, com entradas e saídas conhecidas. Reescreva. Depois mostre, com testes e tráfego de produção gravado quando possível, que a versão nova se comporta como a antiga nos casos que importam. O produto das quatro semanas é uma fatia com equivalência comprovada e uma lista de cada diferença intencional, aprovada por quem é dono daquele comportamento.

Capacidade de revisão. Conte quantas linhas de código reescrito um revisor qualificado consegue de fato confirmar por semana e compare com quanto o lado da geração produz. Se um time hipotético gera dez vezes o que consegue verificar, a meta de 98% é um cronograma de código não verificado, e a prova de conceito deveria dizer isso na quarta semana.

Rollback. Na fatia, demonstre que o time consegue recolocar a versão legada no ar com rapidez e sem sujeira. Uma reescrita que não pode ser revertida transforma cada comportamento perdido em incidente.

Um número de progresso ponderado pela verificação. Reporte o percentual do código legado substituído por código reescrito que passou nas checagens de equivalência. Esse número será menor que o percentual refatorado, e é ele que diz à liderança o que ela de fato tem.

Nada disso exige frear a geração. Muda o que significa “pronto”. Provar equivalência também exige gente que ainda entenda para que serve o código legado. Nosso texto Verificação Nunca Foi o Gargalo. Compreensão É argumenta que entender, e não conferir, é o recurso mais escasso.

Atrito no lugar certo

Patel disse à Fortune que cria tensão de propósito: “você quer ter atrito suficiente nas ideias. Você não quer ter atrito com pessoas e personalidades.” Ele descreveu o próprio time como cerca de um terço de operadores experientes “que entendem como o motor da Cisco funciona”, um terço de pensadores sistêmicos vindos do mercado e um terço de fundadores e engenheiros nativos de IA “que operam em modo fundador”.

Essa estrutura contém a resposta para a questão da verificação, se for usada assim. Na nossa leitura, os operadores que sabem como o motor funciona são as pessoas mais bem posicionadas para dizer o que o código legado deveria fazer. O atrito deles pertence à evidência de equivalência: as fatias, as diferenças intencionais, os ensaios de rollback. Uma reescrita rápida, puxada pela geração, combinada com verificação sob responsabilidade dos operadores é um desenho forte. Uma reescrita rápida, puxada pela geração, pontuada apenas por percentual refatorado deixa para os operadores a tarefa de descobrir as diferenças em produção.

Faça isto agora

Se você financia uma reescrita legada conduzida por IA, ou pensa em tirar o teto de tokens de uma, defina as regras de pontuação antes de começar a primeira prova de conceito.

  1. Escreva a meta de verificação ao lado da meta de geração. “Percentual refatorado” sempre aparece com “percentual com equivalência comprovada” ao lado.
  2. Defina de antemão a fatia da prova de conceito e a evidência de equivalência: quais entradas, qual tráfego gravado, quem aprova as diferenças intencionais.
  3. Meça a vazão de revisão durante a prova de conceito e compare com a vazão de geração. Use essa razão para definir o cronograma real.
  4. Exija uma demonstração de rollback na fatia antes de o programa crescer além dela.

Tirar o limite de tokens pode ser uma boa decisão. Só funciona se o orçamento que ocupa o lugar dele for medido em prova.


Fontes

A Victorino ajuda líderes de engenharia a desenhar metas de verificação, checagens de equivalência e portões de rollback que tornam seguras as reescritas legadas conduzidas por IA: contato@victorino.com.br | www.victorino.com.br

Todos os artigos do The Thinking Wire são escritos com o auxílio do modelo LLM Opus da Anthropic. Cada publicação passa por pesquisa multi-agente para verificar fatos e identificar contradições, seguida de revisão e aprovação humana antes da publicação. Se você encontrar alguma informação imprecisa ou deseja entrar em contato com o editorial, escreva para editorial@victorino.com.br . Sobre o The Thinking Wire →

Se isso faz sentido, vamos conversar

Ajudamos empresas a implementar IA sem perder o controle.

Agendar uma Conversa