Em 11 de junho de 2026, a Anthropic anunciou uma aliança de vários anos com a DXC Technology que coloca Claude dentro daquele tipo de sistema em que “ir rápido” normalmente significa “escreva primeiro um plano de rollback”. A DXC diz que Claude já é o modelo-base padrão dos workflows agênticos do DXC OASIS, que Claude ajudou a acelerar a entrega de software do OASIS em cerca de 10x, e que mais de 95% do código do OASIS foi gerado por Claude antes da revisão de engenheiros (Anthropic, PRNewswire).
Essa é a parte interessante. Não “AI escreve código”. Todo mundo já viu essa demo. A história de verdade é que a DXC está levando geração agêntica de código para bancos, companhias aéreas, seguradoras, fabricantes e órgãos públicos, onde os problemas difíceis são arqueologia de dependências, governança de release, auditabilidade, segurança e não quebrar um processo batch de 30 anos que liquida dinheiro de verdade às 2 da manhã.

O sinal: AI entra na camada de serviços gerenciados
A DXC lançou o OASIS em 28 de abril de 2026 como uma plataforma de orquestração inteligente para serviços gerenciados. A função declarada dela é atuar como uma camada governada e segura sobre o parque de TI existente de uma organização, levando as operações de um suporte reativo para execução em tempo real (DXC).
Isso importa porque a modernização em setores regulados raramente começa com um repo limpinho e um destino greenfield. Ela começa com:
- jobs batch que ninguém domina por completo
- servidores de aplicação fora das janelas normais de suporte
- COBOL, Java EE, PL/SQL, shell e cola de workflow de fornecedores
- controles de compliance que estão em parte no código e em parte em runbooks
- integrações frágeis com sistemas de pagamentos, sinistros, reservas, estoque, identidade ou gestão de casos
Colocar Claude dentro do OASIS significa que a DXC não está tratando o modelo como um chatbot ao lado do trabalho. Ela está colocando o modelo dentro de workflows de orquestração que já conhecem incidentes, janelas de mudança, contexto de tickets, runbooks, ambientes e restrições do cliente. Essa é a diferença entre “gere um refactor” e “gere um refactor que sobreviva à análise do CAB”.
A Anthropic diz que a DXC treinará dezenas de milhares de engenheiros forward-deployed certificados em Claude por meio da Anthropic Academy, com a DXC adicionando seu próprio currículo para sistemas mission-critical (Anthropic). Esse é o formato certo. Modernização regulada precisa de gente que saiba ler o sistema, não turistas de prompt.
O que desenvolvedores deveriam copiar
O padrão da DXC é útil mesmo que você não trabalhe na escala da DXC. A lição não é “deixe o modelo ser dono do repo”. A lição é: envolva o trabalho do modelo em um workflow em que contexto, restrições, revisão e evidências sejam objetos de primeira classe.
Um agente prático de modernização de legado não deveria começar com “reescreva este serviço em Go”. Ele deveria começar com um plano restrito:
1. Inventory modules, entry points, data stores, and external contracts.
2. Identify dead code and risk hotspots.
3. Propose the smallest behavior-preserving refactor.
4. Generate tests around current behavior before changing code.
5. Open a reviewable patch with traceable rationale.
6. Attach evidence: tests, static analysis, dependency impact, rollback notes.
Isso soa entediante. Ótimo. É assim, com tédio, que sistemas regulados são alterados.
Os números públicos da DXC são agressivos: entrega de software estimada em 10x mais rápida e mais de 95% de código gerado por Claude para o OASIS, revisado por engenheiros (Anthropic). Trate isso como afirmações específicas de implantação, não como uma constante universal de produtividade. O ponto para desenvolvedores é o modelo operacional: alta contribuição do modelo, revisão humana obrigatória e uma plataforma que registra o trabalho.
Para uma migração de core bancário, isso pode significar agentes mapeando fluxos de transação e gerando testes de caracterização. Para uma companhia aérea, agentes podem destrinchar workflows de reserva ou manutenção preservando formatos externos de mensagens. Para uma seguradora, eles podem comparar regras de administração de apólices com o comportamento de sinistros. Para fabricantes, podem rastrear dependências de ERP, MES e cadeia de suprimentos antes de tocar no código.

A escolha do modelo está virando uma decisão de arquitetura
Dois dias antes do anúncio da DXC, a Anthropic lançou Claude Fable 5 e Claude Mythos 5 em 9 de junho de 2026. Fable 5 é o modelo de classe Mythos da Anthropic com disponibilidade geral, enquanto Mythos 5 é restrito ao Project Glasswing e a programas de acesso confiável. A Anthropic lista o Fable 5 a US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída, com janela de contexto de 1 milhão de tokens e saída máxima de 128k na documentação atual da API (Anthropic, Claude Docs).
Um retrato compacto de preços da visão geral de modelos da Anthropic:
| Modelo | Entrada | Saída | Contexto | Saída máx. |
|---|---|---|---|---|
| Claude Fable 5 | $10 / MTok | $50 / MTok | 1M tokens | 128k |
| Claude Opus 4.8 | $5 / MTok | $25 / MTok | 1M tokens | 128k |
| Claude Sonnet 4.6 | $3 / MTok | $15 / MTok | 1M tokens | 64k |
| Claude Haiku 4.5 | $1 / MTok | $5 / MTok | 200k tokens | 64k |
A conclusão errada é “use sempre o modelo mais forte”. A arquitetura melhor é roteamento de modelos.
Use o modelo mais forte para raciocínio em nível de sistema: descoberta de dependências, planejamento de migração, frameworks desconhecidos, refactors entre repositórios e análise de falhas. Use modelos mais baratos para sumarização, geração simples de testes, limpeza de documentação e edições mecânicas. Coloque ferramentas determinísticas ao redor dos dois: compiladores, executores de teste, ferramentas de diff de schema, SAST, geração de SBOM e checagens de política.
A Anthropic também diz que o Fable 5 tem salvaguardas que fazem fallback para Claude Opus 4.8 em certas solicitações relacionadas a cibersegurança, biologia, química ou destilação, e que dados iniciais mostram que mais de 95% das sessões do Fable não têm fallback (Anthropic). Para desenvolvedores em setores regulados, isso não é uma nota de rodapé. Se um workflow toca em remediação de segurança, análise de vulnerabilidades ou pesquisa sensível, seu runtime de agentes precisa detectar fallback de modelo, registrar isso e decidir se a saída resultante ainda atende ao seu nível de garantia.

Revisão humana é o produto, não o imposto
A frase “mais de 95% de código gerado por Claude” vai virar manchete. A frase “depois revisado por engenheiros de software” é a parte que torna isso implantável.
Em modernização regulada, revisão não é uma aprovação cerimonial de pull request. Ela precisa responder a perguntas concretas:
- O comportamento mudou, e onde está a evidência de teste?
- Quais contratos de dados, schemas, APIs e arquivos batch foram tocados?
- O patch altera autorização, retenção, logging ou trilhas de auditoria?
- Existe um caminho de rollback?
- Alguém que não é o autor consegue entender por que a mudança existe seis meses depois?
É aqui que workflows de agentes vencem chat solto. Um bom workflow consegue obrigar todo patch gerado a carregar sua própria explicação, plano de teste, classificação de risco e mapa de sistemas afetados. Ele também consegue bloquear merges quando o modelo não inspecionou um serviço dependente ou quando os testes gerados só comprovam o happy path.
A habilidade do desenvolvedor muda de digitar cada linha para desenhar pacotes de trabalho revisáveis. Isso ainda é engenharia. Em muitos parques legados, era justamente a engenharia que estava faltando.
Um pequeno padrão para modernização agêntica
Se eu estivesse construindo isso dentro de uma equipe de software regulada, faria cada tarefa de modernização produzir quatro artefatos antes da revisão de código:
inventory.md: pontos de entrada, dependências, configs, armazenamentos de dados, contratos externos.risk.md: processo de negócio afetado, controles de compliance tocados, notas de rollback.tests/: testes de caracterização que travam o comportamento atual.patch.diff: a menor mudança que preserve comportamento.
O modelo consegue gerar os quatro. Engenheiros deveriam revisar os quatro. O CI deveria impor as partes entediantes.
Para experimentos locais, Claude Fable 5 também está disponível como um endpoint Anthropic Messages drop-in pela OneHop. A página do Fable 5 da OneHop atualmente lista o endpoint como https://api.onehop.ai/anthropic, o nome do modelo como anthropic/claude-fable-5 e um crédito de US$ 10 para novas contas sem exigir cartão; o preço promocional exibido é de US$ 5 para entrada e US$ 25 para saída por milhão de tokens, mais de 30% abaixo do preço de tabela da Anthropic de US$ 10/US$ 50 (OneHop).
from anthropic import Anthropic
client = Anthropic(
base_url="https://api.onehop.ai/anthropic",
api_key="<ONEHOP_KEY>",
)
message = client.messages.create(
model="anthropic/claude-fable-5",
max_tokens=1024,
messages=[{"role": "user", "content": "Map risks in this legacy migration plan."}],
)
Use esse tipo de endpoint para protótipos e harnesses de avaliação. Para workloads regulados em produção, a parte difícil continua sendo seus controles: tratamento de dados, retenção, acesso, evidências, roteamento de modelos e aprovação humana.

A aposta real: modernização vira contínua
A maioria das empresas trata modernização de legado como um programa que acontece uma vez por década. Orçamento grande. Grande integradora. Grande risco. Aí a nova plataforma começa a envelhecer no primeiro dia.
A história do OASIS da DXC aponta para um modelo melhor: modernização como workflow contínuo de serviço gerenciado. Agentes inspecionam, propõem, testam, refatoram, documentam e roteiam trabalho para engenheiros. Engenheiros revisam, restringem e aprovam. A plataforma preserva evidências. O sistema melhora em incrementos menores e mais seguros.
É por isso que vale acompanhar essa aliança. A pergunta útil não é se Claude consegue escrever código. Consegue. A pergunta útil é se uma organização consegue transformar código gerado em mudança governada, revisável e segura para produção em sistemas que não podem cair.
A DXC afirma ter evidências iniciais de que isso pode funcionar em escala séria: 115.000 funcionários em 70 países, OASIS em produção com mais de 50 clientes, dezenas de milhares de engenheiros forward-deployed certificados em Claude planejados, e Claude como o modelo padrão nos workflows agênticos do OASIS (Anthropic, PRNewswire).
Para desenvolvedores, o movimento é claro: pare de pensar em AI como autocomplete. Comece a desenhar workflows de agentes que deixem para trás testes, diffs, explicações e trilhas de auditoria. É disso que a modernização de legado sempre precisou. O modelo finalmente torna a papelada e o movimento de código baratos o bastante para fazer isso continuamente.
Se você quer testar o lado de roteamento de modelos sem montar uma stack enterprise completa, comece com um repo pequeno, uma tarefa de teste de caracterização e um endpoint Fable 5 como Claude Fable 5 on OneHop. Mantenha o gate de revisão humana. Meça diffs aceitos, testes com falha, tempo de revisão, qualidade de rollback e custo por mudança mergeada. Depois decida se o workflow mereceu um sistema maior.