Diez errores de prompt engineering que cometen los desarrolladores, con soluciones

Los malos resultados de Copilot, ChatGPT y asistentes parecidos suelen tener menos que ver con el modelo que con la petición que le escribes. Muchos desarrolladores esperan que la herramienta adivine lo que quieren decir, reciben algo erróneo o a medias y culpan a la IA. Trátala como a un compañero junior brillante pero muy literal. Si le das requisitos vagos, te devolverá código vago. Si le das detalle, contexto, restricciones y expectativas, los resultados mejoran mucho. Hay diez errores que aparecen una y otra vez, y cada uno tiene un arreglo rápido.

Muy poco contexto

La versión clásica es una petición de una línea:

Create a login API.

Eso deja al modelo adivinando el lenguaje, el framework, los requisitos de seguridad, la base de datos y el método de autenticación. Mejor explícitalos:

Create a Spring Boot REST API for user login using JWT authentication.
Use MySQL as the database.
Follow industry security practices and include exception handling.

La calidad del resultado sigue a la calidad del contexto que aportas.

Dar por hecho que el modelo conoce tu proyecto

Muchas preguntas llegan a mitad de sesión sin ninguna descripción del código existente:

Add caching to this application.

¿Dónde va la caché? ¿En la capa de servicio, en la de base de datos, en las respuestas de la API? ¿Redis o algo local? El modelo no te lee la mente, así que describe cómo están las cosas antes de pedir un cambio:

I have a Spring Boot microservice that retrieves customer information from MySQL.
The customer records rarely change.
Suggest a Redis caching implementation to reduce database calls.

Meterlo todo en una sola petición

Una larga lista de deseos en un único mensaje suele recibir un tratamiento superficial:

Create APIs, add authentication, optimize performance,
write unit tests, review security, and deploy to AWS.

Divídela en fases y abórdalas una a una:

Step 1: Design the API architecture.

Step 2: Implement authentication.

Step 3: Generate unit tests.

Step 4: Review security concerns.

Lleva la conversación como un proceso de ingeniería, no como un conjuro.

Omitir las restricciones

Si no das límites, el modelo los rellena con sus propias suposiciones. Mira esta petición:

Optimize this code.

¿Optimizar velocidad, memoria, legibilidad o coste? Di cuál y di qué queda descartado:

Optimize this Java code for readability while maintaining the same functionality.
Avoid introducing additional libraries.

Define qué significa el éxito antes de preguntar.

Saltarse el rol

Asignar un rol es una técnica potente que mucha gente nunca usa. Compara una petición sin más:

Review this code.

con una que dice quién revisa y qué debe buscar:

Act as a Senior Software Architect.

Review the following code for:
- Performance issues
- Security vulnerabilities
- Scalability concerns
- Maintainability

Di qué papel debe asumir el modelo antes de hacer la pregunta.

Tomar la primera respuesta como definitiva

Los ingenieros con experiencia iteran, y con los prompts pasa lo mismo. Repreguntas como estas llevan un borrador hacia algo utilizable:

Can you simplify this solution?

What are the drawbacks?

Can you improve performance?

Show a production-ready version.

El valor real sale del ciclo de refinamiento. Considera la primera respuesta un borrador.

No mostrar un ejemplo

Los modelos rinden mucho mejor cuando incluyes una muestra. Sin ella, obtienes una suposición sobre el formato:

Generate a JSON response.

Con una estructura objetivo en la petición, el modelo sabe exactamente qué forma quieres:

Generate a JSON response matching this structure:

{
  "userId": 101,
  "name": "John Doe",
  "status": "Active"
}

Los ejemplos reducen la ambigüedad y hacen los resultados más consistentes.

Confiar ciegamente en el resultado

Quizá sea el error más peligroso. El código generado puede estar desactualizado, inventarse APIs, malinterpretar los requisitos y ser inseguro. Nunca des por hecho que está listo para producción. Acostúmbrate a revisar el código, ejecutar tests, comprobar la seguridad, verificar las dependencias y contrastarlo con la documentación. El asistente apoya tu criterio, no lo sustituye.

Pedir solo código

Si solo pides una solución, no aprendes nada de ella. Pide también el razonamiento:

Generate the solution and explain:

1. Why you chose this approach.
2. Alternative approaches.
3. Potential limitations.

Así un generador de código se convierte en una herramienta de aprendizaje, y ganas conocimiento además de velocidad.

Rendirse tras un prompt flojo

Un primer prompt malo da un resultado malo, y lo correcto es mejorarlo. Así puede evolucionar una petición. Versión 1:

Build a dashboard.

Versión 2:

Build an Angular dashboard.

Versión 3:

Build an Angular dashboard for monitoring application health.
Include charts, KPI cards, dark mode support, and responsive design.
Use ApexCharts.

Cada pasada acota el objetivo y mejora lo que vuelve.

Una plantilla reutilizable

Una estructura sencilla cubre la mayoría de los casos:

Role:
Who should the AI act as?

Context:
What project/problem are you working on?

Task:
What exactly needs to be done?

Constraints:
What rules must be followed?

Output Format:
What should the final response look like?

Rellenada para una tarea real, queda así:

Act as a Senior Angular Developer.

I am building an enterprise dashboard application.

Create a reusable KPI card component.

Use Angular 19 and TypeScript.

Follow clean coding practices.

Return code with explanations.

El prompt engineering se está convirtiendo en una habilidad básica para los ingenieros de software, y no se trata de trucos ingeniosos ni de fórmulas elaboradas. Se trata de expresar los requisitos con claridad, aportar contexto e iterar con sensatez. Quienes más sacan de la IA no suelen ser los que tienen las herramientas más sofisticadas. Son los que hacen las mejores preguntas.