Ejemplos de ingeniería de prompts para ingenieros de software
Ejemplos concretos de ingeniería de prompts para depuración, refactorización, pruebas, arquitectura, revisión de código y documentación.
Un prompt de ingeniería útil hace que el asistente razone a partir del problema, la evidencia, las restricciones y los criterios de aceptación, no de una orden aislada. Los ejemplos siguientes muestran cómo esto cambia el trabajo de depuración, refactorización, pruebas, arquitectura, revisión de código y documentación.
Cada prompt mejorado es deliberadamente específico sobre la decisión que debe tomar el asistente. Puedes acortarlo cuando la tarea sea pequeña, pero conserva la información que evita un cambio equivocado para el producto.
Depurar un proceso de pago intermitente
Problema
Una solicitud de pago a veces tiene éxito tras un reintento, pero la interfaz sigue mostrando el primer error.
Prompt débil
Corrige el error intermitente del proceso de pago.
Prompt mejorado
Síntoma: Una solicitud de pago puede fallar una vez por un tiempo de espera y,
después, tener éxito en el reintento automático. La pantalla de éxito no aparece
después del reintento.
Esperado: Un reintento correcto debe reemplazar el estado de error y habilitar
el siguiente paso del proceso de pago.
Observado: Los registros de red muestran una respuesta 200, pero el primer
banner de error permanece.
Alcance: Inspecciona únicamente la mutación del proceso de pago, el callback de
reintento y el estado de la pantalla.
Restricciones: Conserva la integración existente con el proveedor de pagos y el
texto de error. No ocultes los errores antes de que una solicitud haya tenido
éxito realmente.
Primero presenta dos o tres hipótesis basadas en evidencia y la reproducción o
señal de registro más pequeña que las distinguiría. Después propone una
corrección mínima y una prueba de regresión.
Por qué funciona
El prompt separa la evidencia del supuesto. Pide un diagnóstico de las transiciones de estado antes de una reescritura y protege la integración de pagos frente a un cambio no relacionado.
Refactorizar lógica repetida de formularios
Problema
Tres formularios de configuración repiten el mismo código de carga, error y estado de guardado.
Prompt débil
Refactoriza estos formularios para eliminar la duplicación.
Prompt mejorado
Los formularios de cuenta, notificaciones y perfil duplican el renderizado del
estado de guardado. Identifica el comportamiento exacto que se repite y los
lugares en los que los formularios son distintos.
Resultado: Reduce el renderizado duplicado sin cambiar los props públicos de los
formularios, el momento de la validación, los errores localizados, los eventos de
analítica ni el comportamiento del teclado.
Alcance: Los tres formularios de configuración y sus pruebas directas.
No objetivo: No crees un framework de formularios general ni traslades la
propiedad de las solicitudes fuera de los hooks existentes de la funcionalidad.
Recomienda la extracción más pequeña, muestra el contrato que se conserva y
añade o actualiza pruebas de carga, fallo y éxito para cada formulario.
Por qué funciona
“Eliminar la duplicación” es un objetivo, no un diseño. El prompt mejorado pide al asistente que encuentre el punto de integración común real y evita una abstracción sobredimensionada.
Escribir una prueba de condición de carrera
Problema
Los resultados de búsqueda de una consulta antigua y lenta pueden sobrescribir una consulta más reciente.
Prompt débil
Añade pruebas para la búsqueda.
Prompt mejorado
Añade cobertura de regresión para una condición de carrera en la búsqueda.
Escenario: Una persona busca "network", cambia inmediatamente la consulta a
"terminal" y la respuesta de network llega al final.
Esperado: La interfaz muestra únicamente los resultados de "terminal". La
respuesta anterior no debe reemplazarlos.
Usa la infraestructura de pruebas existente y aserciones accesibles. Evita
afirmar nombres de estado internos. Si el código de producción no puede expresar
claramente la cancelación o la vigencia, explica el cambio más pequeño necesario
antes de escribir la prueba.
Por qué funciona
El prompt de prueba define el tiempo, la acción del usuario y el comportamiento visible. No permite que un detalle de implementación conveniente se convierta en el contrato de la prueba.
Evaluar un cambio de arquitectura
Problema
Un equipo está decidiendo si añadir una segunda capa de caché para la configuración.
Prompt débil
Añade caché para la configuración y haz que la aplicación sea más rápida.
Prompt mejorado
Evalúa si una caché de configuración del lado del cliente mejoraría la pantalla
lenta sin crear decisiones obsoletas sobre derechos o preferencias.
Contexto: La aplicación ya tiene un proveedor de configuración y la pantalla
espera a un usuario autenticado. No hemos medido si la obtención de datos o el
renderizado es el cuello de botella.
Compara: sin caché, una caché acotada en memoria y la caché persistente propuesta.
Evalúa la vigencia, la invalidación, la privacidad, el comportamiento sin conexión
y la medición necesaria para justificar el cambio.
No implementes nada hasta indicar qué opción recomiendas y por qué.
Por qué funciona
El prompt hace que “más rápida” sea medible y pide al asistente que cuestione la premisa. Una caché no es automáticamente una mejora de rendimiento.
Revisar un diff arriesgado
Problema
Un pull request cambia permisos y navegación visible para las personas usuarias en la misma funcionalidad.
Prompt débil
Revisa este pull request.
Prompt mejorado
Revisa este diff en busca de regresiones de autorización, navegación que rompa
la configuración regional y cambios de comportamiento ocultos por la
refactorización.
Sigue cada decisión de permisos modificada hasta quien la llama. Verifica que
los enlaces internos conservan la configuración regional activa y que los estados
denegados no revelan datos protegidos.
Informa solo de hallazgos con evidencia del diff o de sus sitios de llamada
directos. Prioriza la corrección y la seguridad antes que las sugerencias de
estilo. Enumera las pruebas que faltan por separado de los defectos confirmados.
Por qué funciona
La revisión tiene un modelo de amenazas y un alcance. Eso produce un resultado más pequeño y práctico que pedir comentarios genéricos.
Actualizar documentación tras cambiar una herramienta
Problema
El comando de configuración local cambió y la guía de primeros pasos ya está desactualizada.
Prompt débil
Actualiza la documentación de configuración.
Prompt mejorado
Actualiza la guía de configuración local para los scripts actuales del paquete.
Verifica cada comando documentado frente a package.json y las instrucciones de
configuración del repositorio. Explica los requisitos previos, la salida esperada
cuando todo está listo, las señales habituales de fallo y una ruta de recuperación
segura.
No documentes secretos, valores copiados de un entorno local ni comandos que el
proyecto no ejecute realmente. Añade una lista breve de comprobación de validación
para una persona que contribuya por primera vez.
Por qué funciona
El asistente tiene que fundamentar el texto en el repositorio en lugar de producir una guía pulida pero ficticia.
Usa el ejemplo que corresponda a tu tarea
El patrón repetido es sencillo: nombra el problema, acota el alcance, protege el comportamiento importante, solicita evidencia y define la validación. Empieza con el marco reutilizable de cómo escribir mejores prompts para IA y después consulta ingeniería de prompts para desarrolladores para ver un flujo de trabajo organizado por rol de ingeniería.
Los problemas de producción necesitan un rastro de evidencia aún más estricto. Continúa con plantillas de prompts para depurar problemas de producción antes de pedir a un asistente que proponga una corrección para un sistema en producción. Cuando un error implique salida de shell o un script, reproduce el flujo de trabajo de línea de comandos en el navegador antes de automatizar una solución.
Referencias
Estos enlaces de documentación aportan detalles confiables sobre los comandos usados en este artículo.