Cómo hablarle a Claude cuando construyes algo

Hay una frase que se repite constantemente entre la gente que empieza a construir cosas con IA: "Le pedí que me hiciera una app y el resultado fue una basura."

Y casi siempre, cuando preguntas qué le escribieron exactamente, la respuesta es algo así: "Hazme una app para gestionar mis clientes."

Eso no es un prompt. Es un deseo.

Cuando construyes algo con Claude — una herramienta interna, una app sencilla, un sistema de seguimiento, lo que sea — la calidad del resultado depende casi por completo de la calidad de las instrucciones que das antes de pedir ni una sola línea de código. Y eso no significa escribir más. Significa pensar antes de escribir.

Este artículo va de exactamente eso: cómo convertirte en alguien que dirige a Claude con precisión, no alguien que espera que la IA adivine lo que tiene en la cabeza.

---

1. El problema de "hazme una app"

Imagina que contratas a un desarrollador freelance que acaba de llegar de otro país. Es brillante, aprende rápido y trabaja a una velocidad increíble. Pero no conoce tu negocio, no sabe quiénes son tus clientes, no tiene ni idea de qué problemas estás intentando resolver.

El primer día le dices: "Hazme una app para gestionar mis clientes."

¿Qué pasa? Hace algo. Probablemente algo funcional. Pero no es lo que tú tenías en la cabeza, porque lo que tú tenías en la cabeza nunca salió de tu cabeza.

Con Claude pasa exactamente lo mismo, con una diferencia: Claude no va a pedirte aclaraciones a menos que se lo pidas explícitamente. Va a asumir, rellenar los huecos con sus mejores suposiciones y devolverte algo que técnicamente responde a tu pregunta pero no resuelve tu problema real.

"Dar instrucciones vagas a Claude es como dar instrucciones vagas a cualquier persona. Obtienes respuestas vagas. El resultado no es culpa de la herramienta, es consecuencia del input."

El problema no es que Claude sea malo construyendo cosas. El problema es que "hazme una app" no contiene información suficiente para construir nada útil. No hay contexto, no hay requisitos, no hay límites, no hay casos de uso. No hay nada.

1.1 Lo que Claude asume cuando no le dices nada

Cuando el prompt es vago, Claude toma decisiones por ti. Y las toma razonablemente bien... para alguien que no te conoce y no conoce tu negocio.

Asume un usuario genérico. Asume funcionalidades estándar. Asume un diseño que "parece una app". El resultado es algo que podría servirle a cualquiera, lo cual significa que probablemente no le sirve perfectamente a nadie, y mucho menos a ti.

Lo que necesitas es exactamente lo contrario: un resultado tan específico a tu situación que casi no podría servirle a nadie más.

1.2 Por qué iterar sobre una base mala no funciona

Un error que comete mucha gente es intentar arreglar con iteraciones lo que debería haberse resuelto con planificación. "Hazme una app" → resultado malo → "mejóralo" → resultado ligeramente menos malo → "más profesional" → más de lo mismo.

Cuando la base es vaga, las iteraciones también lo son. Estás intentando llegar a un destino sin saber cuál es ese destino.

Antes de pedir código, necesitas saber qué estás construyendo. Y para eso hay tres preguntas que tienes que responder.

---

2. Las tres preguntas que tienes que responder antes de pedir código

No hace falta un documento de 40 páginas. Pero sí hace falta pensar en estas tres cosas antes de abrir Claude y escribir el primer mensaje.

2.1 ¿Qué hace exactamente esto?

No "gestionar clientes". Eso no significa nada. ¿Qué significa gestionar en tu caso?

• ¿Guardar nombre, teléfono y email?
• ¿Registrar cada vez que alguien te compra algo?
• ¿Llevar un historial de conversaciones?
• ¿Enviar recordatorios automáticos?
• ¿Ver cuánto ha gastado cada cliente en total?

Cada una de esas cosas es una funcionalidad diferente. Si no las defines, Claude elegirá por ti cuáles incluir y cuáles ignorar.

La pregunta que tienes que hacerte es: ¿qué tareas específicas va a poder hacer alguien que use esto? Escríbelas en una lista. No importa si son cinco o quince. Lo importante es que sean concretas.

2.2 ¿Quién lo usa y en qué situación?

Los casos de uso son las situaciones reales en las que alguien va a interactuar con lo que estás construyendo. Son los momentos concretos del día a día donde tu herramienta entra en acción.

Por ejemplo, si construyes un sistema de seguimiento de pedidos para una tienda pequeña:

• Caso de uso 1: El dueño de la tienda llega por la mañana y quiere ver los pedidos pendientes del día.
• Caso de uso 2: Un cliente llama para saber cuándo llega su pedido. El dueño necesita buscarlo por nombre rápidamente.
• Caso de uso 3: El mes ha terminado y el dueño quiere saber cuántos pedidos se han completado y cuánto dinero han supuesto.

Estos casos de uso no son opcionales. Son la razón de existir de lo que estás construyendo. Si Claude los conoce, puede diseñar la herramienta alrededor de ellos. Si no los conoce, diseña algo genérico que probablemente no encaje en ninguno de esos momentos.

2.3 ¿Qué puede salir mal?

Esta es la pregunta que casi nadie se hace, y es la que más diferencia hace.

Los errores esperados son las situaciones problemáticas que sabes que van a ocurrir. No son bugs técnicos — esos los gestiona Claude. Son los casos límite de tu negocio:

• ¿Qué pasa si alguien intenta añadir un cliente que ya existe?
• ¿Qué pasa si el campo de teléfono se deja vacío?
• ¿Qué ocurre si se borra un pedido por error?
• ¿Puede un pedido tener varios productos o solo uno?
• ¿Qué pasa si dos personas usan la herramienta a la vez?

Si no defines estos casos, Claude tomará decisiones por defecto que pueden o no coincidir con lo que tú necesitas. Algunos serán aceptables. Otros no. Y el problema es que no lo sabrás hasta que ocurran en el mundo real.

---

3. La diferencia entre "hazme una app" y dirigir a Claude con precisión

Vamos a ver esto en concreto. Mismo objetivo, dos formas completamente distintas de formularlo.

3.1 El prompt vago

Hazme una app para gestionar los pedidos de mi tienda online.

Esto es lo que Claude tiene para trabajar:

• Una app (¿web? ¿escritorio? ¿base de datos?)
• Gestionar pedidos (¿qué significa gestionar?)
• Tienda online (¿qué tipo? ¿qué escala?)

Claude hará suposiciones razonables y te dará algo. Pero ese algo estará diseñado para una tienda genérica imaginaria, no para la tuya.

3.2 El prompt preciso

Quiero construir una herramienta sencilla para gestionar los pedidos
de mi tienda de ropa personalizada. Trabajo sola desde casa y tengo
entre 10 y 30 pedidos al mes.

Lo que necesito:
- Añadir pedidos nuevos con: nombre del cliente, producto pedido,
  talla, color, fecha de entrega acordada y precio
- Ver todos los pedidos en una tabla, ordenados por fecha de entrega
- Marcar un pedido como "en proceso", "listo para enviar" o "enviado"
- Buscar un pedido por nombre de cliente

Casos de uso principales:
1. Cada vez que alguien me encarga algo, lo añado con todos los datos
2. Cada mañana entro a ver qué pedidos tienen que salir esa semana
3. Cuando envío un pedido, lo marco como enviado para saber que está listo

Errores que necesito evitar:
- Si intento añadir un pedido sin nombre o sin fecha, debe avisarme
- Si marco un pedido como enviado, quiero que me pida confirmación
  antes de hacerlo (por si es un error)

No necesito que sea bonito, solo que sea claro y fácil de usar
desde el móvil. Sin login, sin sistema de usuarios, solo la herramienta.

"La diferencia entre los dos prompts no es la longitud. Es la información. El segundo le dice a Claude exactamente qué construir, para quién, en qué situaciones y qué debe evitar. El primero deja todo eso a la imaginación."

El segundo prompt lleva quizás cinco minutos escribirlo. Pero esos cinco minutos de reflexión evitan horas de iteraciones inútiles.

---

4. Cómo estructurar tu prompt de construcción

No necesitas ningún formato especial. Pero si quieres una estructura que funcione siempre, esta es la que uso:

4.1 El contexto del proyecto

Empieza con una frase que resuma qué es lo que vas a construir y para quién:

Quiero construir [qué cosa] para [quién la va a usar] que [problema
que resuelve o situación en la que se usa].

No hace falta ser elaborado. Solo dar contexto para que Claude no tenga que inventárselo.

4.2 La lista de funcionalidades

Escribe una lista concreta de lo que tiene que poder hacer. No "gestionar X", sino verbos concretos:

• Añadir, editar, eliminar...
• Ver, buscar, filtrar, ordenar...
• Marcar, cambiar de estado, archivar...
• Calcular, resumir, exportar...

Cada punto de la lista es algo que alguien va a poder hacer con la herramienta. Si no está en la lista, probablemente no aparecerá en el resultado.

4.3 Los casos de uso

Describe entre dos y cinco situaciones reales en las que se va a usar la herramienta. No tienes que ser literario — basta con "cuando X pasa, el usuario necesita poder hacer Y":

Casos de uso:
- Cuando llega un cliente nuevo, necesito poder añadirlo con sus datos
  en menos de un minuto
- Cuando preparo las facturas del mes, necesito ver todos los servicios
  de ese mes ordenados por cliente
- Cuando un cliente me pregunta si le he enviado algo, necesito
  encontrarlo rápido por nombre

4.4 Los errores esperados

Lista los casos problemáticos que sabes que van a ocurrir:

Errores y casos especiales:
- No debería poder guardar un registro sin los campos obligatorios
- Si se borra algo, que pida confirmación
- Si busco algo que no existe, que diga "no encontrado" en vez de
  mostrar una pantalla vacía

4.5 Las restricciones

Todo lo que no quieres, lo que no necesitas, o las limitaciones del contexto:

Restricciones:
- No necesito login ni usuarios
- Tiene que funcionar bien en móvil
- Sin base de datos compleja, que los datos se guarden localmente
- Sin funcionalidades que no he pedido — prefiero empezar simple

Esta última parte es especialmente importante. Claude tiende a añadir funcionalidades que no pediste porque "parecen útiles". Si no quieres eso, dilo explícitamente.

---

5. El momento de pedir el código

Una vez que tienes claro todo lo anterior, hay una técnica que mejora significativamente los resultados: pide primero el plan, no el código.

5.1 Primero, valida que Claude ha entendido bien

Antes de pedir que escriba código, pide que te explique lo que va a construir:

Antes de escribir nada, explícame en lenguaje llano cómo planteas
construir esto: qué partes va a tener, cómo fluye la información
y qué decisiones has tomado en los puntos donde no he sido
completamente específico.

Este paso evita que descubras a mitad del proceso que Claude interpretó algo de forma distinta a como tú lo pensabas. Es mucho más fácil corregir un plan que deshacer código.

5.2 Aprueba antes de construir

Cuando Claude te explique el plan, lee con atención:

• ¿Tiene todas las funcionalidades que pediste?
• ¿Los casos de uso tienen sentido tal como los describe?
• ¿Ha tomado alguna decisión con la que no estás de acuerdo?

Si algo no cuadra, corrígelo ahora. Un mensaje de "En el punto 2 yo preferiría que X en vez de Y" en este momento ahorra mucho más tiempo que pedirlo cuando el código ya está escrito.

Solo cuando el plan te convence, dices: "Perfecto, construye esto."

5.3 Construye por partes si el proyecto es grande

Si lo que estás construyendo tiene varias partes diferenciadas, no intentes construir todo de golpe. Hazlo por piezas:

• Primero la estructura básica (la interfaz vacía, la base de datos)
• Luego las funcionalidades principales una a una
• Después las funcionalidades secundarias
• Por último los detalles y ajustes visuales

Construir por partes te permite validar que cada pieza funciona antes de añadir la siguiente. Y cuando algo falla, sabes exactamente qué parte es porque acabas de construirla.

---

6. Qué hacer cuando el resultado no es lo que esperabas

Incluso con un prompt excelente, a veces el primer resultado no es exactamente lo que tenías en mente. Eso es normal. Lo importante es saber cómo ajustar.

6.1 Describe el problema, no la solución

El error más común al corregir es decir cómo arreglarlo en vez de explicar qué está mal:

Ineficaz: "Cambia el botón de añadir para que esté arriba a la derecha y sea azul con texto blanco."

Eficaz: "El botón de añadir es difícil de encontrar en móvil. Está demasiado escondido y necesito acceder a él constantemente."

Cuando describes el problema, Claude puede encontrar la mejor solución técnica. Cuando describes la solución, puede que la implemente aunque haya una forma mejor.

6.2 Una cosa a la vez

No acumules correcciones en un solo mensaje. "Cambia esto, añade aquello, quita lo otro, y por cierto también..." es otra forma de prompt vago — demasiadas instrucciones sin prioridad ni contexto.

Hazlo de una en una. El resultado es más predecible y más fácil de revisar.

6.3 Si después de tres iteraciones sigue sin funcionar, replantea

Hay un punto en el que iterar deja de ser útil. Si después de tres intentos de corrección el resultado sigue lejos de lo que necesitas, el problema probablemente no es la ejecución: es el planteamiento inicial.

Para. Vuelve al principio. Lee tu prompt original con ojos críticos. ¿Qué asumiste que era obvio y no lo dijiste? ¿Qué caso de uso se te olvidó incluir? ¿Qué restricción dejaste implícita?

Reescribe el prompt con lo que ahora sabes que necesitabas haber dicho desde el principio. El resultado va a ser notablemente mejor.

---

7. Un ejemplo completo de principio a fin

Para que todo lo anterior tenga sentido en la práctica, aquí tienes un ejemplo completo de cómo preparar y lanzar un proyecto de construcción con Claude.

Situación: Soy nutricionista y llevo el control de mis pacientes en una hoja de Excel que ya no me vale. Quiero algo más cómodo para hacer un seguimiento básico.

7.1 El proceso de reflexión previo

Antes de escribir nada, respondo las tres preguntas:

¿Qué hace exactamente esto?

• Guarda datos básicos de cada paciente: nombre, edad, peso inicial, objetivo
• Registra el peso en cada visita con la fecha
• Muestra un gráfico sencillo de evolución del peso
• Permite añadir notas libres en cada visita

¿Quién lo usa y cuándo?

• Yo sola, desde el ordenador de la consulta
• Al inicio de cada visita, para ver el historial del paciente antes de empezar
• Al final de cada visita, para registrar el peso y añadir notas
• Una vez al mes, para revisar qué pacientes no han venido en más de 30 días

¿Qué puede salir mal?

• Si intento guardar una visita sin peso, que me avise
• Si busco un paciente que no existe, que me lo diga claramente
• Si borro un paciente por error, necesito poder recuperarlo

7.2 El prompt que escribo

Quiero construir una herramienta de seguimiento de pacientes
para mi consulta de nutrición. La uso yo sola desde el ordenador.
Tengo entre 20 y 40 pacientes activos.

Funcionalidades:
- Añadir pacientes nuevos con: nombre, edad, peso inicial, objetivo
  de peso y notas iniciales
- Ver la lista de todos los pacientes ordenada por apellido
- Buscar pacientes por nombre
- En el perfil de cada paciente: ver sus datos, el historial de visitas
  y un gráfico de evolución del peso
- Registrar una visita nueva: fecha (hoy por defecto), peso y notas libres
- Ver qué pacientes no han tenido visita en más de 30 días

Casos de uso principales:
1. Al llegar a la consulta, busco al paciente del día y repaso su historial
2. Al terminar la visita, registro el peso y añado notas de lo que hablamos
3. Una vez al mes reviso quién no ha venido para hacer seguimiento

Errores y casos especiales:
- No debería poder registrar una visita sin ingresar el peso
- Si borro un paciente, que pida doble confirmación
- Los datos de los pacientes son confidenciales — aunque no hay login,
  no quiero que ningún dato sea visible sin abrir la app específicamente

Restricciones:
- Sin login, sin usuarios, solo la herramienta para uso personal
- Que funcione bien en pantalla de ordenador (no necesito móvil)
- Diseño funcional y limpio — no necesito que sea bonito, que sea usable
- Sin funcionalidades extra que no haya pedido

Ese prompt tiene todo lo que Claude necesita para construir algo que realmente encaje en el día a día de la consulta. No porque sea largo, sino porque es preciso.

---

Construir con IA no es difícil. Lo que sí requiere práctica es el momento anterior: el de pensar con claridad qué estás construyendo, para quién y en qué situaciones. Esa claridad es la que determina si el resultado vale desde el primer intento o si vas a pasarte horas intentando arreglar algo que nació mal planteado.

Si quieres aprender a construir herramientas útiles con Claude desde cero, en Claudio Academy tienes lecciones prácticas diseñadas específicamente para personas sin perfil técnico que quieren usar la IA para crear cosas reales.