Domina Claude Code: El Secreto de la Herramienta Ask User Question

Por Qué Tus Planes de Claude Code Te Están Costando Dinero

Greg Isenberg trae al "Profesor" Ross Mike para lo que llaman el curso intensivo definitivo de Claude Code. Mientras existen miles de tutoriales, este corta el ruido con una opinión controvertida: la mayoría de usuarios están donando dinero a Anthropic porque sus planes son terribles.

El principio entrada-salida: "However good your inputs are will dictate how good your output is. We're getting to a point where the models are so freakishly good that if you are producing quote unquote slop, it's because you've given it slop." (La calidad de tus entradas dictará la calidad de tus salidas. Estamos llegando a un punto donde los modelos son tan increíblemente buenos que si estás produciendo lo que se llama basura, es porque le diste basura.) Esto ya no se trata de limitaciones del modelo—Opus 4.5 y modelos similares han cruzado un umbral donde los problemas de calidad se remontan a las instrucciones humanas.

La herramienta oculta que nadie usa: Ross revela la herramienta ask_user_question de Claude Code, que te entrevista sobre los detalles específicos de tu plan. "When you use this ask user question tool, the questions become more granular. It asks about core workflow, technical foundation, UI/UX, and script generation." (Cuando usas esta herramienta ask_user_question, las preguntas se vuelven más granulares. Pregunta sobre flujo de trabajo principal, fundación técnica, UI/UX y generación de scripts.) En lugar de aceptar las preguntas de planificación genéricas de Claude, esta herramienta te obliga a considerar compensaciones que nunca considerarías.

Piensa en funcionalidades, no en productos: "A lot of times people will describe a product, not describe features, and will be frustrated with AI. Like AI is supposed to magically know what you're thinking about." (Muchas veces las personas describen un producto, no describen funcionalidades, y se frustran con la IA. Como si la IA fuera supuesta a saber mágicamente qué estás pensando.) La idea clave: si no puedes desglosar tu idea en funcionalidades concretas con criterios de prueba, te estás preparando para bucles de iteración costosos.

La advertencia de RALPH: A pesar del bombo alrededor de bucles autónomos, Ross argumenta que los principiantes deberían evitarlos completamente. "If you haven't built anything, deployed anything, there isn't a URL that I myself or Greg can click on that you've built, you have no business using RALPH." (Si no has construido nada, desplegado nada, no hay una URL que yo o Greg podamos hacer clic que hayas construido, no tienes negocios usando RALPH.) Construye repeticiones manuales primero para desarrollar intuición de producto.

5 Conclusiones Clave para el Dominio de Claude Code

• Usa ask_user_question religiosamente - La herramienta te entrevista sobre detalles minuciosos (opciones de base de datos, diseños de UI, manejo de costos) que la planificación genérica omite completamente
• Nunca excedas el 50% de contexto - Una vez que alcanzas ~100K tokens en una sesión, la calidad del modelo se deteriora; inicia sesiones nuevas de manera proactiva
• Prueba cada funcionalidad antes de continuar - Escribe una prueba para la funcionalidad uno antes de construir la funcionalidad dos; las fundaciones rotas se componen exponencialmente
• Salta RALPH hasta que hayas lanzado - Los bucles autónomos amplifican planes malos; primero aprende a iterar manualmente bien
• Invierte tiempo en planificación, no en depuración - El enfoque ask_user_question puede parecer tedioso, pero previene ciclos de reelaboración costosos

Qué Significa Esto para el Desarrollo Impulsado por IA

La meta-lección aquí se extiende más allá de Claude Code. Conforme las herramientas de codificación de IA maduran, el cuello de botella se desplaza de "¿puede el modelo hacer esto?" a "¿especifiqué esto correctamente?" La técnica ask_user_question—obligarte a responder preguntas granulares antes de generar código—se aplica a cualquier flujo de trabajo agentic. La construcción de software se está haciendo fácil; la ingeniería de software (arquitectura, UX, gusto) sigue siendo difícil. Los ganadores no serán aquellos con las mejores herramientas, sino aquellos que inviertan en crear entradas precisas.