English

Haz que pregunte primero: el prompt de confianza del 95%

La mayoría de las malas salidas de la IA no son culpa del modelo. Empezó a construir antes de entenderte. Escribes un prompt rápido y poco especificado; el agente llena los vacíos con su mejor conjetura; y terminas tres archivos adentro de un código que resuelve el problema equivocado. La solución no es un mejor prompt, es un orden de operaciones distinto: haz que el agente pregunte antes de actuar.

Prompt vago que entra, salida vaga que sale

Los agentes de programación son ansiosos. Ante una tarea como "agrega rate limiting a la API", Claude Code elegirá un algoritmo, un backend de almacenamiento y un conjunto de rutas a proteger, todo en silencio, todo como suposiciones. Si esas suposiciones no coinciden con lo que tenías en mente, no te enteras hasta que estás revisando un diff que tienes que descartar en parte. Ese es el camino caro: el agente quema tokens y tiempo produciendo algo, tú quemas tiempo leyéndolo, y luego los dos empiezan de nuevo con las partes que estaban mal.

El camino barato es resolver la ambigüedad en la conversación, antes de que se escriba una sola línea. Una pregunta de aclaración cuesta unos segundos de responder. Una implementación equivocada cuesta un ciclo de revisión, un revert y un nuevo prompt, y si el agente corre de forma semiautónoma a lo largo de varios pasos, una suposición equivocada hecha temprano se acumula en todo lo que se construye encima.

Por qué funciona preguntar primero

La falta de especificación es el estado por defecto de cualquier solicitud real: "agrega rate limiting", "arregla el test inestable", "haz el dashboard más rápido" a todas les falta contexto: qué rutas, qué entorno, qué tiene que significar "más rápido". Existen dos formas de cerrar ese vacío. Puedes intentar agregar más contexto por adelantado, pero rara vez piensas en todo, y por eso estaba poco especificada la solicitud en primer lugar. O puedes dejar que el agente saque a la luz los vacíos específicos que está a punto de adivinar, que son exactamente los lugares donde su conocimiento se acaba.

El segundo enfoque es más eficiente porque es dirigido. El agente no hace preguntas genéricas de descubrimiento; pregunta por los puntos de decisión que está a punto de enfrentar. "¿El rate limit debe ser por usuario o por IP?" es una pregunta que solo se vuelve obvia una vez que estás mirando la implementación. Forzar al agente a hacerla antes de implementar, en lugar de elegir una en silencio, convierte una conjetura en una decisión que tomaste a propósito.

El patrón de prompt

Una línea lo logra:

Ask me questions until you're 95% confident you understand what I want, then proceed.

Dilo una vez al inicio de una tarea, o incorpóralo en un archivo de instrucciones del proyecto (CLAUDE.md) para que aplique por defecto a cada sesión. El número específico importa menos que el mecanismo: "95% de confianza" le da al agente un umbral sobre el cual puede razonar, en lugar de una invitación abierta a hacer una pregunta y seguir adelante. Las instrucciones vagas como "pregúntame si algo no está claro" tienden a saltarse; una barra de confianza concreta es más difícil de ignorar.

Dos refinamientos lo afilan aún más:

• "¿Qué no estoy considerando? ¿Qué tendría en cuenta un experto?" — Esto empuja más allá de las preguntas que habrías generado tú mismo, hacia la clase de caso límite que un experto del dominio marcaría por reflejo: límites de autenticación, comportamiento de rollback, concurrencia. Agrégalo como seguimiento una vez que el agente haya hecho su primera ronda de preguntas obvias.
• Acota las preguntas a la decisión, no a todo el codebase. Si solo quieres alineación sobre la arquitectura, dilo: "pregúntame sobre decisiones de diseño, no sobre detalles de implementación", para que el ida y vuelta se mantenga corto.

Un ejemplo concreto

Compara dos formas de arrancar la misma tarea.

Sin el patrón: "Agrega caching al endpoint de búsqueda." El agente elige caching en memoria, un TTL de 60 segundos y cachea por query string en bruto, nada de lo cual especificaste, y todo lo cual podría estar mal para tu patrón de tráfico.

Con el patrón: "Agrega caching al endpoint de búsqueda. Hazme preguntas hasta estar 95% seguro de que entiendes lo que quiero." El agente vuelve con: ¿Es de instancia única, o necesita funcionar en múltiples servidores (lo que descarta la memoria)? ¿Las claves de caché deben incluir al usuario autenticado, o la búsqueda es pública? ¿Cuál es una ventana de obsolescencia aceptable? Tres preguntas, treinta segundos para responder, y la implementación que sigue coincide con tus restricciones reales al primer intento.

Errores comunes

• No te saltes el seguimiento. La primera ronda de preguntas suele ser la de las obvias. "¿Qué no estoy considerando?" es lo que saca a la luz los casos límite que de otro modo aparecerían como un reporte de bug la semana que viene.
• No dejes que pregunte para siempre. Un umbral del 95% es un objetivo, no una táctica de estancamiento. Si el agente sigue preguntando después de cinco o seis preguntas en una tarea pequeña, responde lo que quede pendiente y dile que proceda; sobre-aclarar una tarea simple desperdicia el tiempo que intentabas ahorrar.
• Responde con precisión. Una respuesta vaga a una pregunta precisa solo reubica la ambigüedad. Si no sabes la respuesta tú mismo, dilo: eso también es información útil, y es mejor resolverlo ahora que asumirlo en silencio después.

Trucos avanzados

• Ponlo en tu CLAUDE.md. En lugar de repetir la línea en cada sesión, agrega una regla como "para cualquier tarea no trivial, haz preguntas de aclaración hasta estar 95% seguro antes de escribir código." Aplica automáticamente en todo el proyecto.
• Combínalo con un paso explícito de plan. Después de la ronda de preguntas, pídele al agente que reformule su entendimiento como un plan breve antes de tocar archivos: un segundo checkpoint barato antes de que empiece la parte cara.
• Úsalo para revisar, no solo para construir. El mismo patrón funciona al pedirle a un agente que revise un PR o diagnostique un bug: "hazme preguntas hasta estar seguro de que entiendes la falla" saca a la luz los pasos de reproducción faltantes antes de que tome el camino equivocado.

Recursos

• Claude Code docs — Manage Claude's memory (CLAUDE.md)
• Anthropic — Be clear, direct, and detailed (prompt engineering)
• Claude Code docs — Common workflows