La forma correcta de escribir prompts para agentes de código con IA
Así es como la mayoría de los desarrolladores usa un agente de código con IA. Abren la ventana de chat y escriben algo como "agrega un interruptor de modo oscuro a la página de configuración". El agente produce algo. Más o menos funciona. Quedan detalles por pulir. El desarrollador pasa los siguientes veinte minutos yendo y viniendo para remendar las cosas.
Luego decide que el modelo no es tan bueno.
El modelo es bueno. El problema es el prompt.
Cada ambigüedad en tu prompt es una decisión que el modelo toma sin ti. ¿La preferencia de modo oscuro debería mantenerse entre sesiones? ¿Tiene que respetar la configuración del sistema operativo? ¿Dónde se guarda la preferencia, en localStorage, en un perfil de usuario en la base de datos o en una cookie? ¿Qué biblioteca de componentes se usa y cómo funciona el tema dentro de ella?
No lo dijiste. Entonces el modelo adivina. A veces acierta. Con frecuencia no. Y ahí tienes código que funciona en un entorno y se rompe en otro, o un componente que ignora la preferencia que el usuario ya había configurado.
Esto es un problema de información.
Esto es lo que descubrieron los equipos serios que arman flujos de desarrollo asistido por IA. El modelo sabe qué necesita para hacer bien una tarea mejor de lo que la mayoría de los desarrolladores sabe cómo pedirlo.
Ha procesado una cantidad enorme de tareas de ingeniería bien especificadas, así que sabe cómo se ve una solicitud de funcionalidad completa y qué suele faltar en un reporte de bug vago. El truco es hacer que te diga qué falta antes de pedirle que haga algo.
El flujo se ve así:
Ese último paso es opcional pero vale la pena. Puedes pedirle al agente: "Con base en mis respuestas, reescribe mi solicitud original como una especificación completa de la tarea." Lo que recibes es un prompt que el propio modelo considera lo bastante completo para ejecutarlo bien. Entonces envías ese prompt como la tarea real.
Algunos ya llaman a esto ingeniería inversa de prompts para ejecutar tareas. El modelo muestra qué contendría un prompt perfecto, y tú trabajas a partir de eso.
Digamos que quieres agregar un interruptor de modo oscuro a una página de configuración. Así se ven los dos enfoques.
El enfoque ingenuo:
"Agrega un interruptor de modo oscuro a la página de configuración."
El agente produce un componente con un interruptor escrito a mano, guarda la preferencia en el estado del componente para que se reinicie al actualizar, ignora el sistema de temas existente y usa estilos en línea en lugar de tus variables de CSS o tokens de tema.
Pasas la siguiente hora arreglándolo.
El enfoque de prompt inverso:
Empiezas con la misma frase y luego preguntas: "Antes de empezar, ¿qué necesitarías saber para implementarlo bien? ¿Qué debería aclarar?"
El agente responde algo así:
- ¿Dónde debería persistir la preferencia (localStorage, base de datos, cookie)?
- ¿Existe un sistema de temas (next-themes, variables de CSS, variante dark de Tailwind)?
- ¿El interruptor debería respetar el modo oscuro del sistema operativo como valor por defecto?
- ¿Dónde debería ir en la página de configuración? ¿Hay una sección "Apariencia"?
- ¿La preferencia debería sincronizarse entre sesiones si el usuario tiene la sesión iniciada?
Respondes esas preguntas. Le dices que la app usa next-themes, que las preferencias se guardan en el perfil del usuario mediante un endpoint PATCH /users/me existente y que ya hay una sección "Apariencia" en la página de configuración con otros interruptores que siguen un patrón de componente específico.
Ahora el agente tiene lo que necesita. La implementación que produce se conecta al proveedor de temas correcto, usa la API existente, respeta el patrón de interfaz actual y maneja el respaldo del modo oscuro del sistema. No tienes que arreglar nada.
Los reportes de bugs son donde el prompt vago causa el mayor daño. Un modelo sin contexto produce código seguro de sí mismo pero equivocado.
Imagina que alguien reporta un bug: "El botón de inicio de sesión a veces no funciona."
El enfoque ingenuo: Pegas eso en tu agente. Empieza a revisar el código de autenticación, encuentra un patrón async/await sospechoso, decide que probablemente sea eso, reescribe la función y abre un PR. El bug sigue ahí. La función que cambió no tenía relación.
El enfoque de prompt inverso:
Le das al agente el reporte del bug y preguntas: "¿Qué necesitarías saber para diagnosticar esto con eficacia? ¿Qué preguntas haría un ingeniero senior antes de tocar código?"
Responde:
- ¿Qué significa "no funciona"? ¿El botón no responde a los clics, el clic ocurre pero no pasa nada, o aparece un error?
- ¿Se reproduce siempre o es intermitente? ¿Hay algún patrón (navegador específico, condiciones de red, estado del usuario)?
- ¿Hay errores de consola o solicitudes de red que fallen cuando ocurre?
- ¿Qué componente maneja el clic del botón y qué servicio maneja la autenticación?
- ¿Siempre estuvo roto o se rompió hace poco? Si es una regresión, ¿qué cambió?
Vuelves con la persona que reportó el bug y consigues las respuestas. Es intermitente y solo aparece después de que el usuario lleva más de diez minutos en la página. No hay errores de consola, pero la solicitud de red nunca se dispara. Eso es un bug completamente distinto. La causa probable es un problema de expiración de token o un cierre léxico desactualizado en un manejador de eventos.
Le das esa información al agente, y ahora va al lugar correcto. Encuentra un useCallback con una dependencia desactualizada que captura un token de autenticación del render inicial. El arreglo es un solo cambio puntual.
La razón por la que la mayor parte del desarrollo asistido por IA se siente como una negociación es que el prompt inicial deja demasiadas decisiones al modelo. Vas y vienes refinando el resultado durante varias rondas. Cada ronda de revisión es corregir una suposición que el modelo hizo porque no la especificaste.
El prompt inverso condensa casi todas esas rondas en una sola conversación al inicio. Las preguntas del modelo te dicen exactamente qué decisiones habría tomado por su cuenta. Las tomas tú. El resultado sale bien a la primera porque tuvo información completa.
Hay además un beneficio secundario. Las preguntas que hace el modelo son una lista de control. Si usas la misma técnica de forma consistente para tareas similares, como agregar nuevas configuraciones o corregir bugs de autenticación, las preguntas empiezan a resultarte familiares. Con el tiempo aprendes a incluir esos detalles en tus prompts sin que te los pidan, y la calidad base de tus prompts mejora.
Esta técnica funciona mejor con agentes que tienen acceso a herramientas y a archivos, como Cursor o GitHub Copilot en modo agente. Un agente que puede leer tu código hace preguntas mucho más específicas que uno que trabaja a ciegas.
El flujo de dos pasos (qué necesitas -> aquí está -> ahora haz la tarea) agrega un paso. Para tareas pequeñas y bien definidas es excesivo. Pero para cualquier cosa que toque varios archivos o se integre con sistemas existentes, produce mejores resultados que ir directo a la implementación.
La especificación generada en el paso 3 vale la pena guardarla. Es una plantilla reutilizable. La próxima vez que alguien necesite agregar una configuración que se guarde en el perfil del usuario, ya tienes un prompt bien especificado.
La forma en que la mayoría de los desarrolladores escribe prompts para agentes de código está optimizada para la velocidad a costa de la calidad. Una frase rápida de entrada, un resultado mediocre de salida y diez minutos de limpieza. Esto se repite decenas de veces al día.
El enfoque del prompt inverso invierte ese equilibrio. Inviertes un poco más de tiempo al inicio para asegurarte de que el modelo tiene lo que necesita. A cambio, el resultado se acerca más a lo que querías y pasas menos tiempo corrigiéndolo.
El mejor prompt para una tarea es el que el modelo te dice que necesita.
© Melvin Laplanche - All rights reserved.