Pasar código de un lenguaje a otro con IA resulta convincente hasta que hay que comprobar que calcula lo mismo y sigue siendo rápido. NVIDIA publicó el 16 de septiembre un caso concreto: la conversión de operadores de TileGym a cuTile Rust mediante agentes, acompañada de verificaciones técnicas.
24 operadores y un rendimiento cercano al original
Según la publicación técnica de NVIDIA, el equipo convirtió los 24 operadores públicos de TileGym, que reúnen unos 40 kernels de GPU. Un kernel es una pequeña función de cálculo ejecutada en la tarjeta gráfica. La empresa comunica un rendimiento medio equivalente al 99,5 % de cuTile Python y publica el recurso de conversión en el repositorio de TileGym.
La cifra pertenece al experimento del fabricante; Texploto no lo ha reproducido. No significa que cualquier programa en Python pueda convertirse a Rust manteniendo ese resultado. Tampoco describe una aceleración del 99,5 %. Nuestra lectura es que interesa la cercanía a la referencia dentro de ese conjunto de operadores, no una promesa universal de velocidad.
El agente necesita una forma de saber si se equivoca
El procedimiento descrito compara la representación intermedia Tile IR del código original y del convertido, además de realizar pruebas funcionales y de rendimiento. En términos sencillos, intenta verificar la estructura del cálculo antes de aceptar únicamente que algunos resultados coinciden.
La lección aplicable a otros proyectos es decidir el criterio de aceptación antes de encargar la transformación. Si solo pides «convierte esto», el resultado puede parecer razonable sin cubrir los casos que te importan. Una lista pequeña de condiciones comprobables convierte la revisión en algo menos dependiente de la confianza en una explicación.
Una ficha para una migración pequeña
Proponemos esta ficha de trabajo original para quien evalúe una conversión de código. No son instrucciones de instalación de TileGym ni resultados medidos por nuestra redacción. Elige una sola función y conserva una referencia que puedas ejecutar antes de empezar.
- Entrada: fija tamaños, tipos de datos y casos especiales que la función debe admitir.
- Salida: determina qué comparación aceptarás y, si procede, qué tolerancia numérica tiene sentido.
- Entorno: apunta versiones de herramientas, hardware y opciones de ejecución.
- Tiempo: separa el primer arranque de las ejecuciones posteriores y repite las medidas.
- Decisión: escribe de antemano qué error o regresión hará que conserves la versión original.
Añade una entrada vacía, una pequeña y otra cercana al tamaño máximo previsto, siempre que el contrato de la función las permita. Si un caso queda fuera de ese contrato, anótalo como no admitido. Pedir al agente que improvise su comportamiento puede ocultar precisamente la ambigüedad que intentas resolver.
Útil para evaluar migraciones, no para prometerlas
Antes de cambiar un proyecto por esta noticia, pregunta qué problema resolvería la conversión: integración con código existente, mantenimiento o una necesidad concreta del equipo. Si no puedes señalarlo, conservar una implementación que funciona también es una decisión técnica válida.
Y si haces un piloto, guarda los fallos junto a los éxitos. Un informe que incluya entradas rechazadas y trabajo de revisión ayuda más a decidir que una única cifra favorable. Para aplicar la misma disciplina a otros agentes de programación, puedes consultar nuestra guía sobre cómo leer costes y benchmarks de SWE-2 y el enfoque de reutilizar antes de escribir código nuevo.
