Convierte una idea en un proyecto pequeño y comprobable

Empieza por una salida, no por una tecnología

Un buen primer proyecto no es “hacer una aplicación con IA”. Es algo que una persona pueda abrir, usar y comprobar: una página de servicio, una lista de tareas local, un script que ordena archivos de ejemplo o una pequeña herramienta que transforma texto ficticio.

Si necesitas elegir entre distintos resultados —incluidos web, automatización, RAG o agentes— consulta la biblioteca de proyectos guiados. Esta lección se centra en el método para construir cualquiera de ellos con Claude Code.

Antes de abrir Claude Code: escribe un briefing de seis líneas

No necesitas saber programar para preparar bien el trabajo. Crea una carpeta de práctica y guarda dentro un archivo BRIEF.md con estas respuestas. Evita nombres, documentos, claves o datos de clientes: usa siempre ejemplos públicos, ficticios o autorizados.

Objetivo: una página que explique mi servicio y permita pedir información.
Persona que la usará: una persona interesada que llega desde móvil.
Primera versión: portada, servicios, preguntas frecuentes y formulario simulado.
No incluir todavía: pagos, cuentas, datos reales ni integraciones externas.
Cómo sabré que funciona: la abro en el navegador, pruebo los enlaces y la lee otra persona.

Este documento hace dos cosas: evita que el alcance cambie cada cinco minutos y te permite comprobar si el resultado responde al encargo inicial. Si no puedes escribirlo todavía, el proyecto es demasiado grande o aún no está claro.

Una iteración segura: mirar, planificar, construir, comprobar

1. Mira. Pide a Claude Code que lea el BRIEF.md y describa qué archivos necesitaría crear. No le pidas código todavía.
2. Planifica. Pide un plan de tres a cinco pasos, con una pregunta cuando tenga que elegir algo que te corresponda decidir a ti.
3. Construye una parte. Autoriza el primer paso pequeño: por ejemplo, una página estática sin formularios ni servicios externos.
4. Comprueba. Abre el resultado, sigue el flujo como si fueras la persona usuaria y anota lo que no entiendas o no funcione.
5. Guarda. Haz un commit o al menos escribe en el README qué funciona, qué falta y qué probarás después.

Un encargo que deja espacio para pensar

Después de escribir el briefing, puedes usar un encargo de este estilo:

Lee BRIEF.md. No modifiques archivos aún.
1. Resume el resultado que debemos conseguir.
2. Propón el árbol mínimo de archivos y un plan de 4 pasos.
3. Señala riesgos de privacidad, seguridad o alcance.
4. Espera mi confirmación antes de crear nada.

Cuando apruebes el plan, cambia una única cosa cada vez. Es más lento que pedir “hazme toda la app”, pero permite detectar decisiones erróneas cuando todavía son baratas de corregir.

La evidencia mínima al terminar una sesión

Antes de cerrar, deja estas cuatro huellas. Son más valiosas que una captura bonita sin contexto:

• una frase sobre el resultado que ya funciona;
• una prueba hecha por ti —por ejemplo, el enlace que abriste o el caso que ejecutaste—;
• la lista de límites que siguen pendientes;
• el siguiente cambio pequeño que harás, o el punto al que volverías atrás.

Tu práctica

Elige una tarea de menos de una tarde. Escribe tu BRIEF.md, pide el plan sin cambios y construye únicamente el primer paso. Al terminar, documenta una prueba y un límite. Esa es ya una forma profesional de trabajar: resultado, evidencia y control.