Por qué está escrito así
Si pides optimizar código diciendo solo "hazlo más rápido", la IA empezará por lo cosmético: convertirá bucles en list comprehensions o fusionará variables. Sin embargo, el verdadero culpable suele ser una consulta a base de datos dentro del bucle (problema N+1). Optimizar sin medir genera cambios inútiles.
Al definir el rol como "ingeniero experto en diagnosticar lentitud", la perspectiva cambia: un revisor de código busca estilo y nombres de variables, mientras que alguien enfocado en rendimiento busca por dónde se escapa el tiempo.
Estructurar la respuesta en cuatro pasos es la clave: al forzar una lista priorizada, la IA debe justificar sus elecciones; al pedir un método de validación empírica, se separa la conjetura de la realidad (paso 3: medir antes de desplegar a ciegas).
En las restricciones, pedir que se omitan microoptimizaciones irrelevantes para esa escala y que se liste la información faltante evita que sugiera añadir índices sin saber si ya existen. Delimitar el código con """ previene confusiones con las instrucciones.
¿Términos desconocidos? Consulta Aha AI: chain-of-thought, hallucination
Comparado con un mal ejemplo
Este código va muy lento, optimízalo por favor for order in orders: ... (código)
Sin conocer el volumen de datos, la IA ofrece consejos genéricos. Sustituye listas por sets o reescribe bucles, pero el tiempo de ejecución sigue igual. Si el problema real es una consulta repetitiva a la base de datos, queda enterrado entre sugerencias menores sin justificación ni método para medirlo.
Variaciones
Cuando la lentitud está en la vista/pantalla
Nuestros usuarios reportan lentitud en una vista específica del servicio. El entorno de ejecución es {{entorno de ejecución}} y la escala de datos es {{escala de datos}}. Antes de mirar el código, elabora una lista de posibles orígenes divididos por servidor, base de datos, red y navegador. Indica el orden y la forma en que debo comprobar cada uno, empezando por los más fáciles de verificar.
Útil cuando no se sabe exactamente qué parte del código falla. Permite acotar el embudo de diagnóstico antes de perder tiempo revisando código al azar.
Verificar efectos secundarios tras optimizar
A continuación adjunto un código que he modificado por motivos de rendimiento. No evalúes si es más rápido, sino únicamente si la lógica o el comportamiento han cambiado con respecto al original. Revisa el orden de resultados, duplicados, manejo de errores y concurrencia. Proporciona ejemplos de entradas que puedan romper el código.
""" {{código fuente}} """
Las optimizaciones de rendimiento a menudo introducen bugs sutiles. Es más seguro separar la revisión de velocidad de la revisión de corrección lógica.
Notas por modelo
Si tienes métricas reales de tiempo de ejecución o profiling, inclúyelas. Sin números, la IA solo puede hacer conjeturas basadas en la forma del código.
Prompts relacionados
Última actualización 2026-09-02 · ¿Has visto un error? Avísanos