El 11 de junio de 2026, Anthropic anunció una alianza plurianual con DXC Technology que lleva Claude a ese tipo de sistemas donde “moverse rápido” suele significar “primero escribe un plan de rollback”. DXC dice que Claude ya es el modelo fundacional por defecto para los flujos de trabajo agénticos de DXC OASIS, que Claude ayudó a acelerar la entrega de software de OASIS en un 10x estimado, y que más del 95% del código de OASIS fue generado por Claude antes de la revisión de ingeniería (Anthropic, PRNewswire).
Esa es la parte interesante. No “la IA escribe código”. Todo el mundo ha visto esa demo. La verdadera historia es que DXC está llevando la generación agéntica de código a bancos, aerolíneas, aseguradoras, fabricantes y agencias gubernamentales, donde los problemas difíciles son la arqueología de dependencias, la gobernanza de releases, la auditabilidad, la seguridad y no romper un proceso batch de hace 30 años que liquida dinero real a las 2 de la mañana.
La señal: la IA entra en la capa de servicios gestionados
DXC lanzó OASIS el 28 de abril de 2026 como una plataforma de orquestación inteligente para servicios gestionados. Su trabajo declarado es colocarse como una capa gobernada y segura sobre el parque de TI existente de una organización, pasando las operaciones del soporte reactivo a la ejecución en tiempo real (DXC).
Eso importa porque la modernización en industrias reguladas rara vez empieza con un repo limpio y un destino greenfield. Empieza con:
- jobs batch que nadie posee del todo
- servidores de aplicaciones fuera de las ventanas normales de soporte
- COBOL, Java EE, PL/SQL, shell y pegamento de workflows de proveedores
- controles de cumplimiento que están en parte en el código y en parte en runbooks
- integraciones frágiles con pagos, siniestros, reservas, inventario, identidad o sistemas de gestión de casos
Poner Claude dentro de OASIS significa que DXC no está tratando al modelo como un chatbot al lado del trabajo. Está colocando el modelo dentro de flujos de orquestación que ya conocen incidentes, ventanas de cambio, contexto de tickets, runbooks, entornos y restricciones del cliente. Esa es la diferencia entre “genera un refactor” y “genera un refactor que pueda sobrevivir a una revisión del CAB”.
Anthropic dice que DXC formará a decenas de miles de ingenieros desplegados en campo certificados en Claude a través de Anthropic Academy, con DXC añadiendo su propio currículo para sistemas de misión crítica (Anthropic). Esa es la forma correcta. La modernización regulada necesita gente capaz de leer el sistema, no turistas de prompts.
Qué deberían copiar los desarrolladores
El patrón de DXC es útil aunque no trabajes a escala DXC. La lección no es “deja que el modelo sea dueño del repo”. La lección es: envuelve el trabajo del modelo en un workflow donde el contexto, las restricciones, la revisión y la evidencia sean objetos de primera clase.
Un agente práctico de modernización legacy no debería empezar con “reescribe este servicio en Go”. Debería empezar con un plan acotado:
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.Suena aburrido. Bien. Lo aburrido es como se cambian los sistemas regulados.
Las cifras públicas de DXC son agresivas: entrega de software 10x más rápida estimada y más del 95% de código generado por Claude para OASIS, revisado por ingenieros (Anthropic). Tómalas como afirmaciones específicas de ese despliegue, no como una constante universal de productividad. Lo importante para los desarrolladores es el modelo operativo: alta contribución del modelo, revisión humana obligatoria y una plataforma que registra el trabajo.
Para una migración del core de un banco, eso podría significar agentes que mapean flujos de transacciones y generan pruebas de caracterización. Para una aerolínea, los agentes podrían desenredar workflows de reservas o mantenimiento preservando los formatos de mensajes externos. Para una aseguradora, pueden comparar reglas de administración de pólizas con el comportamiento de siniestros. Para fabricantes, pueden rastrear dependencias de ERP, MES y cadena de suministro antes de tocar código.
La elección del modelo se está convirtiendo en una decisión de arquitectura
Dos días antes del anuncio de DXC, Anthropic lanzó Claude Fable 5 y Claude Mythos 5 el 9 de junio de 2026. Fable 5 es el modelo de clase Mythos generalmente disponible de Anthropic, mientras que Mythos 5 está restringido mediante Project Glasswing y programas de acceso confiable. Anthropic lista Fable 5 a $10 por millón de tokens de entrada y $50 por millón de tokens de salida, con una ventana de contexto de 1M de tokens y una salida máxima de 128k en la documentación actual de la API (Anthropic, Claude Docs).
Una foto compacta de precios tomada del resumen de modelos de Anthropic:
| Model | Input | Output | Context | Max output |
|---|---|---|---|---|
| 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 |
La conclusión equivocada es “usa siempre el modelo más potente”. La mejor arquitectura es el enrutamiento de modelos.
Usa el modelo más potente para razonamiento a nivel de sistema: descubrimiento de dependencias, planificación de migraciones, frameworks desconocidos, refactors entre repos y análisis de fallos. Usa modelos más baratos para resumir, generar pruebas simples, limpiar documentación y hacer ediciones mecánicas. Pon herramientas deterministas alrededor de ambos: compiladores, test runners, herramientas de diff de esquemas, SAST, generación de SBOM y checks de políticas.
Anthropic también dice que Fable 5 tiene salvaguardas que derivan a Claude Opus 4.8 ciertas solicitudes relacionadas con ciberseguridad, biología, química o destilación, y que los datos iniciales muestran que más del 95% de las sesiones de Fable no tienen fallback (Anthropic). Para desarrolladores en entornos regulados, eso no es una nota al pie. Si un workflow toca remediación de seguridad, análisis de vulnerabilidades o investigación sensible, tu runtime de agentes tiene que detectar el fallback de modelo, registrarlo y decidir si la salida resultante sigue cumpliendo tu listón de aseguramiento.
La revisión humana es el producto, no el impuesto
La frase “más del 95% de código generado por Claude” se llevará los titulares. La frase “luego revisado por ingenieros de software” es la parte que lo hace desplegable.
En la modernización regulada, la revisión no es una aprobación ceremonial de pull request. Tiene que responder preguntas concretas:
- ¿Cambió el comportamiento, y dónde está la evidencia de pruebas?
- ¿Qué contratos de datos, esquemas, APIs y archivos batch se tocaron?
- ¿El parche altera autorización, retención, logging o pistas de auditoría?
- ¿Hay una ruta de rollback?
- ¿Puede alguien que no sea el autor entender por qué existe el cambio dentro de seis meses?
Aquí es donde los workflows agénticos superan al chat suelto. Un buen workflow puede obligar a que cada parche generado lleve su propia explicación, plan de pruebas, clasificación de riesgo y mapa de sistemas afectados. También puede bloquear merges cuando el modelo no inspeccionó un servicio dependiente o cuando las pruebas generadas solo demuestran el happy path.
La habilidad del desarrollador pasa de teclear cada línea a diseñar paquetes de trabajo revisables. Eso sigue siendo ingeniería. En muchos parques legacy, era justo la ingeniería que faltaba.
Un patrón pequeño para la modernización agéntica
Si yo estuviera construyendo esto dentro de un equipo de software regulado, haría que cada tarea de modernización produjera cuatro artefactos antes de la revisión de código:
inventory.md: puntos de entrada, dependencias, configs, almacenes de datos, contratos externos.risk.md: proceso de negocio afectado, controles de cumplimiento tocados, notas de rollback.tests/: pruebas de caracterización que fijan el comportamiento actual.patch.diff: el cambio más pequeño que preserve el comportamiento.
El modelo puede generar los cuatro. Los ingenieros deberían revisar los cuatro. CI debería hacer cumplir las partes aburridas.
Para experimentos locales, Claude Fable 5 también está disponible como endpoint Anthropic Messages compatible directamente a través de OneHop. La página de Fable 5 de OneHop actualmente lista el endpoint como https://api.onehop.ai/anthropic, el nombre del modelo como anthropic/claude-fable-5 y un crédito de $10 para cuentas nuevas sin tarjeta; el precio promocional mostrado es de $5 de entrada y $25 de salida por millón de tokens, más de un 30% por debajo del precio de lista de Anthropic de $10/$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."}],
)Usa ese tipo de endpoint para prototipos y arneses de evaluación. Para cargas de trabajo reguladas en producción, la parte difícil sigue siendo tus controles: manejo de datos, retención, acceso, evidencia, enrutamiento de modelos y aprobación humana.
La apuesta real: la modernización se vuelve continua
La mayoría de las empresas tratan la modernización legacy como un programa de una vez por década. Gran presupuesto. Gran integrador. Gran riesgo. Luego la nueva plataforma empieza a envejecer desde el primer día.
La historia de OASIS de DXC apunta a un modelo mejor: modernización como workflow continuo de servicio gestionado. Los agentes inspeccionan, proponen, prueban, refactorizan, documentan y enrutan trabajo a ingenieros. Los ingenieros revisan, acotan y aprueban. La plataforma conserva la evidencia. El sistema mejora en incrementos más pequeños y más seguros.
Por eso vale la pena seguir esta alianza. La pregunta útil no es si Claude puede escribir código. Puede. La pregunta útil es si una organización puede convertir código generado en cambios gobernados, revisables y seguros para producción en sistemas que no pueden caerse.
DXC afirma tener evidencia temprana de que esto puede funcionar a escala seria: 115.000 empleados en 70 países, OASIS en producción con más de 50 clientes, decenas de miles de ingenieros desplegados en campo certificados en Claude planificados, y Claude como modelo por defecto en los workflows agénticos de OASIS (Anthropic, PRNewswire).
Para los desarrolladores, el movimiento está claro: deja de pensar en la IA como autocomplete. Empieza a diseñar workflows de agentes que dejen atrás pruebas, diffs, explicaciones y pistas de auditoría. Eso es lo que la modernización legacy siempre ha necesitado. El modelo por fin abarata lo suficiente el papeleo y el movimiento de código como para hacerlo de forma continua.
Si quieres probar el lado de enrutamiento de modelos sin montar un stack empresarial completo, empieza con un repo acotado, una tarea de pruebas de caracterización y un endpoint de Fable 5 como Claude Fable 5 en OneHop. Mantén la compuerta de revisión humana. Mide diffs aceptados, pruebas fallidas, tiempo de revisión, calidad del rollback y coste por cambio mergeado. Luego decide si el workflow se ganó un sistema más grande.
