Anti-Patrones de Prompts — Que NO Hacer
Aprendiendo de los Errores
La forma mas rapida de mejorar tu prompting es reconocer lo que no funciona. Cada anti-patron en esta leccion es algo que los desarrolladores hacen regularmente, y cada uno desperdicia tiempo de forma predecible. Al identificar estos patrones en tus propios habitos de prompting, puedes eliminar las fuentes mas comunes de frustracion con herramientas de IA.
Cada anti-patron sigue la misma estructura: como se ve, por que falla y la correccion.
Anti-Patron 1: "Hazlo Mejor"
Como se ve:
Haz este codigo mejor
Mejora el rendimiento
Limpia esto
Por que falla: "Mejor" es subjetivo y dependiente del contexto. Mejor para quien? Con que metrica? La IA no tiene forma de saber si quieres que sea mas rapido, mas legible, mas mantenible, mas seguro, mas pequeno, mas testeable o mas alineado con las convenciones de tu equipo. Elegira una interpretacion al azar y producira salida que podria ser peor segun los criterios que realmente te importan.
La correccion: Reemplaza adjetivos subjetivos con objetivos especificos y medibles.
Reduce el numero de consultas a la base de datos en esta funcion de 5 a 1
usando una sola consulta con JOIN en lugar de consultas secuenciales.
Divide esta funcion de 150 lineas en funciones mas pequenas de 30 lineas o
menos, cada una con una sola responsabilidad. Mantener la misma API publica.
Reemplaza la cadena de if/else anidados (lineas 20-55) con retornos tempranos
para reducir el nivel de indentacion a un maximo de 2.
Anti-Patron 2: "Sigue las Mejores Practicas"
Como se ve:
Reescribe esto siguiendo las mejores practicas
Asegurate de que siga los estandares de la industria
Por que falla: "Mejores practicas" es una de las frases mas vagas en el desarrollo de software. Las mejores practicas de React son diferentes a las de Express. Las mejores practicas de Google difieren de las de Airbnb. Las "mejores practicas" de 2020 podrian ser anti-patrones en 2026. Cuando dices "mejores practicas," la IA usa el promedio de sus datos de entrenamiento, que podria no coincidir con tu proyecto, tu equipo o tu contexto.
La correccion: Referencia estandares especificos y concretos.
Reescribe esto siguiendo las convenciones de nuestro proyecto:
- Usar async/await (sin callbacks ni cadenas .then)
- Manejo de errores con subclases de AppError
- Zod para validacion de entrada
- Retornos tempranos en lugar de condicionales anidados
- Seguir el patron en src/services/UserService.ts
Si quieres patrones estandar de la industria, nombralos especificamente: "Usa el patron Repository," "Aplica el patron Circuit Breaker," "Sigue la metodologia 12-factor app para configuracion."
Anti-Patron 3: Micro-Prompting
Como se ve:
Agrega un campo name a la interfaz User
(esperar respuesta)
Ahora agrega un campo email
(esperar respuesta)
Ahora agrega un campo createdAt
(esperar respuesta)
Ahora haz todos los campos requeridos excepto bio
Por que falla: Cada prompt es un viaje de ida y vuelta. Cuatro prompts diminutos que podrian haber sido uno toman cuatro veces mas tiempo y consumen cuatro veces mas tokens. Peor aun, la IA podria tomar decisiones ligeramente diferentes en cada ronda (diferente formato, diferente estilo de imports) porque trata cada uno como una tarea independiente.
La correccion: Agrupa cambios relacionados en un solo prompt completo.
Actualiza la interfaz User en src/types/user.ts:
interface User {
id: string; // UUID, requerido
name: string; // requerido, 1-100 chars
email: string; // requerido, unico
bio?: string; // opcional
avatarUrl?: string; // opcional, URL valida
createdAt: Date; // requerido, establecido al crear
updatedAt: Date; // requerido, actualizado en cada cambio
}
Exporta esta interfaz y agrega comentarios JSDoc a cada campo.
Un prompt, una respuesta, todos los cambios consistentes.
Anti-Patron 4: Sobre-Prompting
Como se ve:
Un prompt de 10 parrafos para una tarea que podria describirse en 2 oraciones. Incluyendo toda la historia del proyecto, contexto irrelevante, multiples aclaraciones y instrucciones repetitivas.
He estado trabajando en este proyecto por 6 meses y originalmente usabamos
MongoDB pero luego cambiamos a PostgreSQL por el soporte de transacciones
y tambien tuvimos una reunion de equipo donde decidimos usar TypeScript
en lugar de JavaScript y la razon es que la seguridad de tipos es importante
para nuestros clientes enterprise que requieren certificacion ISO y por
cierto tambien usamos Docker...
[8 parrafos mas de contexto]
...asi que basicamente solo agrega un campo createdAt al modelo User.
Por que falla: La relacion senal-ruido es terrible. La IA tiene que extraer la tarea real de parrafos de contexto irrelevante. Peor aun, parte del contexto irrelevante podria accidentalmente influir la salida de formas que no pretendias. La IA podria fijarse en la mencion de MongoDB y producir una solucion que considere una migracion que ya paso.
La correccion: Incluye solo el contexto que afecta directamente la tarea actual.
Agrega un campo createdAt al modelo User en prisma/schema.prisma.
Tipo: DateTime, valor por defecto now(). Genera la migracion.
Si el contexto es necesario, ponlo en orden de relevancia: tarea primero, luego restricciones relevantes, luego contexto de fondo solo si afecta la decision.
Anti-Patron 5: Restricciones Contradictorias
Como se ve:
Hazlo rapido y completamente documentado y minimo y completo y simple
pero que maneje cada caso extremo.
Escribe una implementacion concisa que cubra todos los escenarios posibles
con mensajes de error extensos pero manten el codigo corto.
Por que falla: Estas restricciones van en direcciones opuestas. El codigo no puede ser a la vez minimo y completo. El manejo de errores no puede ser a la vez extenso y conciso. La IA intenta satisfacer todas las restricciones simultaneamente y produce un compromiso que no satisface ninguna bien.
La correccion: Prioriza tus restricciones. Declara cuales importan mas y acepta los tradeoffs.
Prioridad: correctitud y manejo de casos extremos. Este es codigo de
procesamiento de pagos.
Secundario: legibilidad y mantenibilidad.
Tradeoffs aceptables: El codigo puede ser mas largo si es mas explicito.
Mensajes de error verbosos son mejores que tersos para este caso de uso.
Si realmente necesitas cualidades en competencia, divide la tarea: genera una implementacion rapida primero, luego agrega documentacion como un paso separado.
Anti-Patron 6: Asumir Contexto
Como se ve:
Arregla el problema con el formato de fecha
Actualizalo para usar el nuevo enfoque
Lo que mencione antes necesita manejar ese caso extremo
Por que falla: La IA no sabe lo que estabas pensando antes de escribir el prompt. Incluso en una conversacion donde discutiste formato de fechas antes, la IA podria haber perdido ese contexto por limites de ventana de contexto, o la conversacion podria haber cambiado de tema. Pronombres como "lo," "esto," "eso" y "la cosa" son ambiguos sin referencias explicitas.
La correccion: Siempre se explicito, incluso si se siente redundante.
Corrige el formato de fecha en src/utils/formatDate.ts: la funcion devuelve
"3/26/2026" pero deberia devolver "26 de marzo de 2026" (formato largo con
nombre completo del mes).
Actualiza el metodo UserService.createUser() para usar validacion con Zod
en lugar de las verificaciones manuales if/else en las lineas 15-30.
Incluso en conversaciones largas, reafirma el contexto clave. Te cuesta 10 segundos de escritura y ahorra minutos de ida y vuelta pidiendo aclaraciones.
Anti-Patron 7: Encadenamiento Sin Verificacion
Como se ve:
Paso 1: Crear el esquema de base de datos
Paso 2: Crear la capa de servicio
Paso 3: Crear las rutas de API
Paso 4: Crear los componentes frontend
Paso 5: Escribir todos los tests
(Enviando todos los pasos a la vez sin revisar resultados intermedios)
Por que falla: Si el Paso 1 tiene un error de esquema, cada paso subsiguiente construye sobre ese error. Para el Paso 5, tienes un sistema completo construido sobre una base defectuosa. Encontrar y corregir el error original requiere rehacer todo.
La correccion: Ejecuta un paso a la vez. Revisa la salida. Verifica la correctitud. Luego procede al siguiente paso.
Paso 1: Crea el esquema de base de datos para la funcionalidad de
notificaciones. Aqui estan los requisitos: [requisitos]. Revisare esto
antes de pasar al Paso 2.
Despues de revisar el Paso 1:
El esquema se ve bien. Un cambio: agrega un indice en (userId, createdAt)
para la consulta de lista de notificaciones. Luego procede al Paso 2: la
capa de servicio.
El overhead de revisar cada paso es minimo comparado con el costo de reconstruir desde una base defectuosa.
Anti-Patron 8: Copiar y Pegar Sin Adaptar
Como se ve: Copiar un prompt de una "biblioteca de prompts" u otro proyecto y usarlo sin modificarlo para el contexto actual.
[Copiado de una plantilla de prompt generica]
Eres un ingeniero de software experto. Por favor escribe codigo limpio,
mantenible y bien documentado siguiendo principios SOLID y patrones de
diseno. Usa inyeccion de dependencias y sigue el patron repository.
Escribe tests unitarios completos con 90% de cobertura de codigo.
Por que falla: Prompts genericos producen codigo generico. Este prompt no le dice nada a la IA sobre tu proyecto, tu stack, tus patrones o tu tarea especifica. Es el equivalente en prompts de decirle a un contratista "construyeme un buen edificio" sin proporcionar planos, ubicacion ni presupuesto.
La correccion: Comienza con plantillas pero adaptalas a tu contexto especifico cada vez.
En nuestro proyecto Express + Prisma + TypeScript, crea un OrderRepository
en src/repositories/OrderRepository.ts.
Metodos necesarios: findById, findByCustomer (con paginacion por cursor),
create, updateStatus.
Sigue el mismo patron que UserRepository en src/repositories/UserRepository.ts.
Incluye validacion de entrada con Zod para los metodos create y updateStatus.
Escribe tests en src/repositories/__tests__/OrderRepository.test.ts igualando
los patrones de test del UserRepository.
Este prompt usa los mismos conceptos (patron repository, tests) pero los ancla en tu proyecto especifico.
Auto-Diagnostico: Reconociendo Anti-Patrones en Tus Propios Prompts
Aqui hay una lista de verificacion rapida para ejecutar antes de enviar cualquier prompt a una herramienta de IA:
-
Mi prompt contiene adjetivos subjetivos? (mejor, mas limpio, mejorado, optimizado) -- Reemplazalos con criterios especificos.
-
Estoy usando pronombres sin antecedentes claros? (lo, esto, eso, la cosa) -- Reemplazalos con referencias explicitas.
-
Mi prompt tiene restricciones en competencia? -- Priorizalas o divide la tarea.
-
Hay contexto en mi cabeza que no esta en el prompt? -- Agregalo.
-
Podria esto ser un solo prompt en lugar de multiples viajes de ida y vuelta? -- Agrupalo.
-
Estoy enviando demasiado contexto irrelevante? -- Recorta a lo que afecta la tarea.
-
Estoy construyendo sobre salida no verificada de un paso anterior? -- Verifica primero.
-
Copie este prompt de algun lugar sin adaptarlo? -- Personalizalo para tu proyecto.
Ejecutar esta lista de verificacion toma 15 segundos y consistentemente previene las fuentes mas comunes de interacciones desperdiciadas con IA. Con el tiempo, estas verificaciones se vuelven automaticas y la calidad de tu prompt al primer intento mejora dramaticamente.