GPT Diffusion

Construir una app completa con Claude desde cero: lo que aprendió un ingeniero de Google Cloud

2026-08-20 · Tutoriales #claude#agentes#vibe#tutorial#coding-agents

TL;DR

Un ingeniero de Google Cloud publicó en r/vibecoding el proceso completo para construir una aplicación funcional con Claude partiendo de un repositorio vacío. El hilo alcanzó 879 upvotes y 203 comentarios en sus primeros días, sobre todo por una razón: no es un demo curado, es un registro de lo que funcionó y lo que se rompió por el camino. Esta guía resume el flujo que siguió y cómo adaptarlo sin caer en los errores típicos del vibecoding.

(Nota de contexto: la fuente es un hilo de Reddit del 15 de agosto de 2026 — https://old.reddit.com/r/vibecoding/comments/1voz78n/ — con los datos de interacción tomados de la base de reddit-research.db el 20 de agosto.)

Qué necesitas

  • Una cuenta de Claude (Claude Code o el SDK, según prefieras terminal o API).
  • Un objetivo acotado: una app con entidad de datos, CRUD y una vista. Nada de “un clon de Notion”.
  • Git inicializado desde el minuto uno. Vas a hacer rollback más de una vez.
  • Familiaridad básica con el stack que elijas: el agente escribe código, pero tú validas.

Paso 1: define el contrato antes de escribir la primera línea

El error más común al trabajar con un agente de código es empezar con “hazme una app de X”. El ingeniero del hilo hizo lo contrario: escribió primero una especificación corta (entidades, endpoints, pantallas) y se la dio a Claude como contexto.

Por qué importa: un prompt ambiguo produce una arquitectura ambigua, y corregir arquitectura cuesta mucho más que corregir una función. Con el contrato por escrito, cada iteración del agente se puede comparar contra algo concreto.

Paso 2: iteraciones cortas con commit tras cada una

El flujo que documentó es un bucle: pedir un incremento pequeño, revisar el diff, probar, commitear. Increments de 15-30 minutos de trabajo, no de horas. Los comentarios del hilo coinciden en que este es el punto que la mayoría se salta — y el que explica por qué sus proyectos con agentes acaban en un repositorio inservible.

Regla práctica: si un cambio no se puede describir en una frase (“añade validación al formulario de login”), es demasiado grande para una iteración.

Paso 3: deja que el agente lea sus propios errores

Cuando algo falla, pega el traceback completo en lugar de describir el síntoma. El patrón que salió mejor en el hilo fue tratar al agente como un par de programación: le das la evidencia cruda y le preguntas por el diagnóstico antes de pedir el fix. Reduce los parches en cadena, que es como los proyectos vibecoded acumulan deuda invisible.

Paso 4: testing y límites del enfoque

Varios comentaristas (de los 203) señalaron el límite real: Claude genera código que compila y pasa el chatarrero de pruebas happy-path, pero el diseño a largo plazo — migraciones, permisos, concurrencia — sigue siendo responsabilidad tuya. Si no tienes tests, no puedes distinguir un refactor correcto de uno que rompe silenciosamente algo en otra parte.

Resultado esperado

Siguiendo este flujo, el autor del hilo terminó con una aplicación desplegada construida en sesiones cortas, y el repositorio quedó en un estado donde otro humano puede seguir el historial de decisiones. Ese es el criterio de éxito real: no la velocidad, sino si el código es sostenible cuando el agente ya no está en la conversación.

Problemas comunes

  • El agente reescribe demasiado. Pide diffs mínimos explícitamente y revisa con git diff antes de aceptar.
  • Contexto que se degrada en sesiones largas. Sesionas cortas y un CLAUDE.md / archivo de contexto actualizado hacen más que cualquier truco de prompt.
  • Dependencia de versiones alucinadas. Verifica package.json tras cada iteración que toque dependencias.

Siguientes pasos

Fuentes

Cargando comentarios...