Prompting para Velocidad — De Lento a 5.7x
La Anatomia de un Prompt de Alta Velocidad
Un prompt no es solo una pregunta -- es una especificacion. La calidad de tu prompt determina directamente cuantos ciclos de iteracion necesitas. Un prompt vago requiere 5-6 rondas de refinamiento. Un prompt preciso lo logra en 1-2. Al nivel 5.7x, la mayoria de los prompts producen output utilizable en el primer intento.
Cada prompt de alta velocidad contiene cuatro elementos:
Resultado — Como debe ser el resultado final
Restricciones — Limites tecnicos y requisitos
Contexto — Patrones especificos del proyecto a seguir
Formato — Como debe estructurarse el output
Aqui esta la diferencia en la practica:
Prompt lento (sin los cuatro elementos):
"Agrega una pagina de login"
Prompt rapido (los cuatro elementos presentes):
"Crea una pagina de login en /login con campos de email y password.
Usa el patron existente del componente AuthForm de /signup.
Valida con zod: email debe ser formato valido, password min 8 caracteres.
En exito, redirige a /dashboard. En fallo, muestra mensajes de error
en linea debajo de cada campo. Usa server actions para el envio del
formulario. Sigue el mismo estilo Tailwind de la pagina de signup."
El prompt lento requerira multiples mensajes de seguimiento: "usa zod para validacion," "sigue el patron de la pagina de signup," "agrega manejo de errores," "usa server actions." Cada seguimiento cuesta tiempo y contexto. El prompt rapido adelanta todas las decisiones y obtiene una implementacion completa en una pasada.
La Especificidad Elimina el Ida y Vuelta
La causa numero uno de interacciones lentas con IA es la ambiguedad. Cada elemento ambiguo en tu prompt obliga a la IA a adivinar, y las adivinanzas requieren correcciones. Aqui estan los patrones de ambiguedad mas comunes y como corregirlos:
Elecciones de tecnologia ambiguas:
Lento: "Agrega autenticacion"
Rapido: "Agrega autenticacion con NextAuth.js usando el proveedor Credentials,
almacenando sesiones en la base de datos con adaptador Prisma"
Estilos ambiguos:
Lento: "Haz que se vea bien"
Rapido: "Usa el mismo patron de componente card que el dashboard, con rounded-xl
border border-slate-200 dark:border-slate-700 p-6 shadow-sm"
Comportamiento ambiguo:
Lento: "Maneja errores"
Rapido: "Captura todos los errores en try-catch. Registra el error completo
en consola. Devuelve un mensaje amigable al usuario en la UI.
Para errores 401, redirige a /login. Para errores 429, muestra
un mensaje de limite de tasa con tiempo de reintento."
Alcance ambiguo:
Lento: "Actualiza la API"
Rapido: "Agrega un endpoint PATCH a /api/users/[id] que acepte actualizaciones
parciales para los campos name, email y avatar solamente. Valida
la entrada con zod. Devuelve el objeto de usuario actualizado.
Agrega un test para cada actualizacion de campo."
Cada especificidad que agregas elimina un ciclo potencial de iteracion. Cinco detalles especificos en un prompt pueden ahorrar cinco rondas de correcciones.
El Patron Planificar-Luego-Ejecutar
Para funcionalidades complejas, divide el trabajo en dos fases: planificacion y ejecucion. Esto captura problemas arquitectonicos antes de que se escriba cualquier codigo.
# Fase 1: Planificar
claude "/plan Agrega un sistema de notificaciones con:
- Tabla de base de datos para notificaciones (user_id, type, message, read, created_at)
- Endpoints de API: GET /api/notifications, PATCH /api/notifications/[id]/read
- Actualizaciones en tiempo real con Server-Sent Events
- Icono de campana en navbar con badge de conteo no leido
- Panel desplegable mostrando notificaciones recientes
- Marcar como leido al hacer clic, boton de marcar todos como leidos"
Revisa el plan cuidadosamente. Tiene sentido la estructura de archivos? Son apropiadas las elecciones de base de datos? Es el enfoque SSE correcto para tu infraestructura? Haz ajustes:
# Fase 1b: Ajustar el plan
"Buen plan, pero usa WebSocket en lugar de SSE ya que tenemos una
conexion WS existente para la funcionalidad de chat. Tambien coloca
el dropdown de notificaciones en el componente HeaderActions existente
en lugar de crear uno nuevo."
# Fase 2: Ejecutar
"Ejecuta el plan aprobado. Crea todos los archivos, ejecuta la migracion
y asegurate de que los tests existentes sigan pasando."
Este enfoque de dos fases agrega 2-3 minutos para el paso de planificacion pero frecuentemente ahorra 15-20 minutos de retrabajo que ocurriria si la IA tomara suposiciones arquitectonicas incorrectas durante la ejecucion directa.
Batch Prompting: Multiples Cambios en Un Mensaje
Uno de los mayores sumideros de tiempo es hacer una solicitud pequena a la vez. Cada mensaje tiene sobrecarga: la IA lee contexto, genera una respuesta, tu revisas, envias el siguiente mensaje. Agrupa cambios relacionados en prompts unicos:
# Lento: 5 mensajes separados
"Agrega un spinner de carga al dashboard"
"Cambia el color primario a indigo-600"
"Agrega aria-labels a todos los enlaces de navegacion"
"Corrige el z-index del menu movil"
"Agrega un enlace saltar-al-contenido para accesibilidad"
# Rapido: 1 mensaje agrupado
"Haz estos 5 cambios en la UI:
1. Agrega un spinner de carga a la pagina del dashboard (usa el componente Spinner)
2. Cambia el color primario de blue-600 a indigo-600 en todos los componentes
3. Agrega aria-labels descriptivos a todos los enlaces de navegacion en Navbar.tsx
4. Corrige el z-index del menu movil — establece z-50 para que renderice sobre el contenido
5. Agrega un enlace saltar-al-contenido como primer elemento enfocable en el layout"
La version agrupada se completa en un ciclo de ejecucion de IA en lugar de cinco. Para un conjunto de cambios independientes, esto solo puede ser una mejora de velocidad de 3-4x en esa tarea.
Cuando agrupar:
- Cambios que son independientes entre si
- Cambios pequenos a medianos que no requieren decisiones arquitectonicas profundas
- Correcciones de bugs de una lista de issues
- Mejoras de estilo o accesibilidad
Cuando NO agrupar:
- Cambios que dependen entre si (hazlos secuencialmente)
- Funcionalidades grandes que necesitan revision individual
- Cambios donde necesitas verificar cada uno antes de continuar
El Anti-Patron: Micro-Prompting
El micro-prompting es el habito de hacer una solicitud diminuta a la vez:
# El anti-patron de micro-prompting
"Agrega un nuevo archivo llamado utils.ts"
"Agrega una funcion llamada formatDate a utils.ts"
"Haz que formatDate acepte un parametro Date"
"Haz que formatDate devuelva un string en formato YYYY-MM-DD"
"Exporta formatDate"
"Importa formatDate en el componente Dashboard"
"Usa formatDate para el display de created_at"
Estos son siete mensajes para lo que deberia ser uno:
# El enfoque 5.7x
"Crea una funcion utilitaria formatDate en src/lib/utils.ts que tome un
Date y devuelva formato YYYY-MM-DD. Exportala y usala en el componente
Dashboard para el display de created_at."
El micro-prompting ocurre cuando los desarrolladores aun estan en una mentalidad de "escribir codigo", dictando linea por linea. La mentalidad 5.7x piensa al nivel de funcionalidad y confia en que la IA manejara los detalles de implementacion.
Plantillas de Prompts para Tareas Comunes
Construye una biblioteca de plantillas de prompts para tareas que haces frecuentemente. Aqui hay plantillas que funcionan bien:
Plantilla de Nueva Funcionalidad
"Agrega [funcionalidad] a [ubicacion].
Requisitos: [lista de requisitos especificos]
Sigue el mismo patron que [funcionalidad similar existente].
Incluye: [componente/ruta/test/migracion segun sea necesario].
Usa [bibliotecas o enfoques especificos]."
Plantilla de Correccion de Bug
"Corrige: [describe el bug y como reproducirlo].
Comportamiento esperado: [que deberia pasar].
El problema probablemente esta en [archivo o area].
Despues de corregir, verifica con [test o verificacion manual]."
Plantilla de Refactorizacion
"Refactoriza [objetivo] a [nuevo enfoque].
Motivacion: [por que es necesario el cambio].
Mantén la misma API publica / comportamiento.
Actualiza todos los sitios de llamada.
Ejecuta tests despues para verificar que nada se rompio."
Plantilla de Creacion de Contenido
"Crea [tipo de contenido] para [tema].
Estructura: [esquema o secciones].
Tono: [describe el tono deseado].
Longitud: [conteo aproximado de palabras].
Formato: [MDX/markdown/etc] con [campos de frontmatter].
Incluye: [ejemplos de codigo, diagramas, etc]."
Metricas de Velocidad
Para poner numeros al impacto del buen prompting:
| Estilo de Prompting | Mensajes Promedio por Feature | Tiempo por Feature | |---------------------|-------------------------------|---------------------| | Micro-prompting | 12-20 mensajes | 45-60 minutos | | Prompting basico | 5-8 mensajes | 20-30 minutos | | Prompting especifico | 2-3 mensajes | 8-15 minutos | | Prompting con plantillas | 1-2 mensajes | 5-10 minutos |
La diferencia entre micro-prompting y prompting con plantillas es una mejora de velocidad de 4-6x en tareas individuales. A lo largo de un dia completo de desarrollo, esto se acumula en el multiplicador general de 5.7x.
Construyendo el Habito
Hacer buenos prompts es una habilidad que mejora con la practica. Comienza con estos habitos:
- Pausa antes de hacer el prompt. Toma 30 segundos para pensar en lo que realmente necesitas antes de escribir. Esos 30 segundos ahorran 10 minutos de iteracion.
- Incluye la referencia del patron. Casi cada cambio sigue un patron existente en tu base de codigo. Nombralo explicitamente.
- Declara las condiciones limite. Que deberia pasar en caso de error? En estado vacio? En casos extremos?
- Agrupa cambios relacionados. Antes de enviar un mensaje, preguntate: "Hay algo mas que necesite en la misma area?"
- Guarda plantillas que funcionen. Cuando un prompt produce excelentes resultados en el primer intento, guardalo como plantilla para uso futuro.
El objetivo no es escribir prompts largos. Es escribir prompts precisos. Un prompt de 3 lineas con los cuatro elementos (resultado, restricciones, contexto, formato) supera a una descripcion vaga de 20 lineas cada vez.