Por qué está escrito así
La conversión de código suele parecer la tarea más fácil para la IA, por lo que es tentador copiar y pegar el resultado sin revisar. Sin embargo, un código con sintaxis válida no siempre es un código seguro en ese lenguaje. Un patrón común en Python puede truncar valores o lanzar excepciones inesperadas en Java, y al compilar sin errores, el fallo suele descubrirse mucho tiempo después.
Por eso, en la sección de tarea se especifica claramente no hacer una traducción literal línea por línea. Sin esta instrucción, el modelo suele generar un mapeo mecánico que, aunque funcione, resulta poco idiomático y difícil de mantener. Pedir que señale los patrones peligrosos persigue el mismo objetivo.
El núcleo del formato de salida son los puntos ② y ③. Recibir únicamente el código migrado no aporta aprendizaje porque no se entienden los motivos de los cambios. La tabla de modificaciones permite ver las diferencias de un vistazo, y la sección de posibles discrepancias anticipa errores típicos (como división de enteros o valores nulos).
En las restricciones, indicar "[Verificación requerida]" evita que la IA alucine nombres de métodos o librerías inexistentes. Además, delimitar el código con """ evita que comentarios internos (como # borrar esto) sean interpretados accidentalmente como instrucciones del prompt.
¿Términos desconocidos? Consulta Aha AI: hallucination, output-format
Comparado con un mal ejemplo
Pásame esto a Java def parse_orders(rows): ... (código pegado)
Genera código traducido línea por línea que conserva estructuras poco naturales en Java. Al no incluir explicaciones ni advertencias sobre discrepancias sutiles (como la división entera o librerías desactualizadas), obliga a revisar todo desde cero, consumiendo el mismo tiempo que una migración manual.
Variaciones
Para detectar riesgos antes de migrar
Tengo previsto migrar el siguiente código de {{idioma original}} a {{idioma de destino}}. Aún no traduzcas el código; solo identifica los posibles puntos críticos o problemáticos durante la migración. Crea una lista ordenada por nivel de riesgo indicando para cada punto: fragmento original afectado · por qué es un problema · posibles alternativas de solución. No menciones las partes que no presenten riesgos.
""" {{código fuente}} """
Útil para analizar bases de código extensas antes de empezar a programar. Permite saber exactamente en qué partes concentrar la revisión.
Para validar un código ya migrado
A continuación comparto un código que migré de {{idioma original}} a {{idioma de destino}}. Encuentra valores de entrada donde el resultado de ambos códigos pueda diferir. Organiza la respuesta en una tabla con: Caso de prueba/Entrada · Resultado en original · Resultado en migrado · Motivo de la diferencia. Si consideras que una sección no tiene diferencias, justifica por qué en una línea.
""" {{código fuente}} """
Ideal para revisar una migración hecha por uno mismo. Proporciona casos de prueba concretos para ejecutar y comparar resultados.
Notas por modelo
Ejecuta y prueba siempre el código migrado en tu entorno. Es habitual que los modelos recuerden bien los nombres de librerías estándar pero confundan nombres de funciones o el orden de los parámetros.
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos