Anti-Patrones de Prompts — Qué NO Hacer
Aprendiendo de los Errores
La forma más rápida de mejorar tu prompting es reconocer lo que no funciona. Cada anti-patrón en esta lección es algo que los desarrolladores hacen regularmente, y cada uno desperdicia tiempo de forma predecible. Al identificar estos patrones en tus propios hábitos de prompting, puedes eliminar las fuentes más comunes de frustración con herramientas de IA.
Cada anti-patrón sigue la misma estructura: cómo se ve, por qué falla y la corrección.
Anti-Patrón 1: "Hazlo Mejor"
Cómo se ve:
Haz este codigo mejor
Mejora el rendimiento
Limpia esto
Por qué falla: "Mejor" es subjetivo y dependiente del contexto. ¿Mejor para quién? ¿Con qué métrica? La IA no tiene forma de saber si quieres que sea más rápido, más legible, más mantenible, más seguro, más pequeño, más testeable o más alineado con las convenciones de tu equipo. Elegirá una interpretación al azar y producirá salida que podría ser peor según los criterios que realmente te importan.
La corrección: Reemplaza adjetivos subjetivos con objetivos específicos 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-Patrón 2: "Sigue las Mejores Prácticas"
Cómo se ve:
Reescribe esto siguiendo las mejores practicas
Asegúrate de que siga los estandares de la industria
Por qué falla: "Mejores prácticas" es una de las frases más vagas en el desarrollo de software. Las mejores prácticas de React son diferentes a las de Express. Las mejores prácticas de Google difieren de las de Airbnb. Las "mejores prácticas" de 2020 podrían ser anti-patrones en 2026. Cuando dices "mejores prácticas," la IA usa el promedio de sus datos de entrenamiento, que podría no coincidir con tu proyecto, tu equipo o tu contexto.
La corrección: Referencia estándares específicos 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 estándar de la industria, nómbralos específicamente: "Usa el patrón Repository," "Aplica el patrón Circuit Breaker," "Sigue la metodología 12-factor app para configuración."
Anti-Patrón 3: Micro-Prompting
Cómo 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 qué falla: Cada prompt es un viaje de ida y vuelta. Cuatro prompts diminutos que podrían haber sido uno toman cuatro veces más tiempo y consumen cuatro veces más tokens. Peor aún, la IA podría tomar decisiones ligeramente diferentes en cada ronda (diferente formato, diferente estilo de imports) porque trata cada uno como una tarea independiente.
La corrección: 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-Patrón 4: Sobre-Prompting
Cómo se ve:
Un prompt de 10 párrafos para una tarea que podría describirse en 2 oraciones. Incluyendo toda la historia del proyecto, contexto irrelevante, múltiples 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 qué falla: La relación señal-ruido es terrible. La IA tiene que extraer la tarea real de párrafos de contexto irrelevante. Peor aún, parte del contexto irrelevante podría accidentalmente influir la salida de formas que no pretendías. La IA podría fijarse en la mención de MongoDB y producir una solución que considere una migración que ya pasó.
La corrección: 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 decisión.
Anti-Patrón 5: Restricciones Contradictorias
Cómo 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 qué falla: Estas restricciones van en direcciones opuestas. El código no puede ser a la vez mínimo y completo. El manejo de errores no puede ser a la vez extenso y conciso. La IA intenta satisfacer todas las restricciones simultáneamente y produce un compromiso que no satisface ninguna bien.
La corrección: Prioriza tus restricciones. Declara cuáles importan más 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 implementación rápida primero, luego agrega documentación como un paso separado.
Anti-Patrón 6: Asumir Contexto
Cómo se ve:
Arregla el problema con el formato de fecha
Actualízalo para usar el nuevo enfoque
Lo que mencione antes necesita manejar ese caso extremo
Por qué falla: La IA no sabe lo que estabas pensando antes de escribir el prompt. Incluso en una conversación donde discutiste formato de fechas antes, la IA podría haber perdido ese contexto por límites de ventana de contexto, o la conversación podría haber cambiado de tema. Pronombres como "lo," "esto," "eso" y "la cosa" son ambiguos sin referencias explícitas.
La corrección: Siempre sé explícito, 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-Patrón 7: Encadenamiento Sin Verificación
Cómo 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 qué 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 corrección: 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.
Después 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 mínimo comparado con el costo de reconstruir desde una base defectuosa.
Anti-Patrón 8: Copiar y Pegar Sin Adaptar
Cómo 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 qué falla: Prompts genéricos producen código genérico. Este prompt no le dice nada a la IA sobre tu proyecto, tu stack, tus patrones o tu tarea específica. Es el equivalente en prompts de decirle a un contratista "constrúyeme un buen edificio" sin proporcionar planos, ubicación ni presupuesto.
La corrección: Comienza con plantillas pero adáptalas a tu contexto específico 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 (patrón repository, tests) pero los ancla en tu proyecto específico.
Auto-Diagnóstico: Reconociendo Anti-Patrones en Tus Propios Prompts
Aquí hay una lista de verificación rápida para ejecutar antes de enviar cualquier prompt a una herramienta de IA:
-
¿Mi prompt contiene adjetivos subjetivos? (mejor, más limpio, mejorado, optimizado) -- Reemplázalos con criterios específicos.
-
¿Estoy usando pronombres sin antecedentes claros? (lo, esto, eso, la cosa) -- Reemplázalos con referencias explícitas.
-
¿Mi prompt tiene restricciones en competencia? -- Priorízalas o divide la tarea.
-
¿Hay contexto en mi cabeza que no está en el prompt? -- Agrégalo.
-
¿Podría esto ser un solo prompt en lugar de múltiples viajes de ida y vuelta? -- Agrúpalo.
-
¿Estoy enviando demasiado contexto irrelevante? -- Recorta a lo que afecta la tarea.
-
¿Estoy construyendo sobre salida no verificada de un paso anterior? -- Verifica primero.
-
¿Copié este prompt de algún lugar sin adaptarlo? -- Personalízalo para tu proyecto.
Ejecutar esta lista de verificación toma 15 segundos y consistentemente previene las fuentes más comunes de interacciones desperdiciadas con IA. Con el tiempo, estas verificaciones se vuelven automáticas y la calidad de tu prompt al primer intento mejora dramáticamente.