En pocas palabras
Combina automatización determinista y agentes de IA para ejecutar migraciones pequeñas y verificables.
Qué problema resuelve
Actualizaciones extensas con numerosos errores de compilación, cambios repetitivos y excepciones difíciles de automatizar.
Cuándo utilizarlo
Cambios de framework, lenguaje o dependencias. Ejemplo: actualizar servicios Java por módulos.
De la idea a la práctica
Funcionamiento, ejemplos y decisiones para pasar al siguiente nivel.
En el Radar compartido: Trial (valoración de la edición aportada).
Cómo funciona
Las recetas realizan transformaciones conocidas; el agente analiza incompatibilidades restantes y propone ajustes. Compilador, pruebas y revisión cierran cada iteración.
Ejemplo de uso
Actualizar primero dependencias con una receta de OpenRewrite; después pedir al agente resolver un error de API en un módulo. Ejecutar pruebas de contrato y comparar consultas, serialización y resultados antes de avanzar.
Reparto del trabajo
| Parte de la migración | Mejor herramienta |
|---|---|
| Cambios mecánicos y repetibles (imports, renombrados, APIs con equivalente directo) | Recetas deterministas (OpenRewrite, codemods) |
| Casos con contexto (APIs eliminadas, patrones propios, configuraciones) | Agente de IA con pruebas |
| Decisiones de diseño (nueva arquitectura, cambio de modelo de datos) | Personas, con apoyo de la IA para explorar |
| Verificación | Compilador, pruebas, comparación de comportamiento |
Proceso por oleadas
- Línea base: suite verde, métricas de rendimiento y una muestra de respuestas o salidas.
- Inventario: localizar todos los usos a migrar (búsqueda, análisis estático, el propio agente).
- Piloto: migrar un módulo pequeño, revisar en detalle y convertir lo aprendido en instrucciones o una skill.
- Escalar: lotes pequeños (un módulo o un servicio por PR), cada uno verificado de forma independiente.
- Limpieza: retirar adaptadores, flags y código antiguo.
Verificar que el comportamiento no cambia
| Técnica | Qué detecta |
|---|---|
| Pruebas existentes | Regresiones cubiertas |
| Pruebas de caracterización | Comportamiento actual capturado antes de migrar (golden master) |
| Pruebas de contrato (Pact) | Cambios en la API hacia consumidores |
| Ejecución en paralelo (shadow) | Diferencias de resultados con tráfico real |
| Mutation testing | Si las pruebas son capaces de detectar cambios |
Pedir al agente que primero escriba pruebas de caracterización sobre el código antiguo y después migre es una de las prácticas más efectivas.
Experiencia publicada
Google ha descrito migraciones a gran escala asistidas por LLM (por ejemplo, cambiar tipos de identificadores en millones de líneas), donde la mayoría de los cambios se generaban automáticamente y los ingenieros revisaban y ajustaban. Los factores de éxito señalados: tareas bien delimitadas, verificación automática y revisión humana de cada cambio. La métrica relevante fue el tiempo total de la migración, no la proporción de código generado.
Riesgos
- Cambios plausibles que compilan pero alteran el comportamiento (redondeos, zonas horarias, codificaciones).
- PR enormes imposibles de revisar.
- Pruebas modificadas por el agente para que pasen: protege los archivos de prueba o revisa sus cambios por separado.
Criterios de implementación
Guardar una línea base y cambios revisables. Medir tiempo total, defectos y retrabajo; evitar delegar una reescritura completa sin puntos de control.
Continúa en las fuentes
Documentación oficial para verificar detalles y explorar más.