Programar un producto con Claude Code sin escribir código en 30 días

A quién le sirve. Programadores y emprendedores técnicos que quieren saber hasta dónde llega la IA al construir un producto real antes de apostar por ella.

Qué hicieron

Un desarrollador se puso una regla: durante 30 días no escribiría código de la aplicación, solo lo describiría, lo revisaría y lo aprobaría. Con Claude Code construyó una pequeña aplicación por suscripción con registro de usuarios, cobros con Stripe, un panel y una interfaz pública para otros programas. Apuntó cada vez que se atascó más de una hora y tuvo que programar él mismo.

Cómo salió

La aplicación funciona y está en producción. Anotó 9 «descansos»: la IA no ve el sistema entero y duplica piezas que ya existen, escribió un aviso de cobro que confirmaba antes de guardar (un fallo de base de datos habría dejado a un cliente de pago sin acceso), reescribía en vez de arreglar, añadía opciones que nadie quería y dejaba sin cubrir los casos raros. Según él, lo más rápido fue montar la base y el código repetitivo.

Conviene saber

El autor dice que su empresa vende agentes parecidos, así que el relato no es neutral. Su conclusión es que la IA sirve para teclear, no para decidir: quien revisa tiene que saber detectar fallos que parecen correctos.

Qué necesitas

• Una suscripción de pago a Claude con Claude Code
• Conocimientos de programación para revisar lo que escribe
• Un proyecto con pruebas automáticas
• Cuentas de pago como Stripe, si tu producto cobra

Cómo hacerlo tú, paso a paso

1. Decide tu regla: qué haces tú y qué hace la IA.
2. Pide a Claude Code que monte la base del proyecto: registro de usuarios, base de datos y panel.
3. Pide funciones pequeñas de una en una, con su plan y sus pruebas.
4. Pasa cada cambio por un segundo revisor, que sea otra conversación, con la orden de buscar fallos.
5. Revisa tú a mano lo delicado: cobros, permisos y borrados.
6. Anota cada vez que la IA se atasque para saber dónde necesitas intervenir.
7. Prueba los casos raros antes de abrirlo a clientes.

Vas a ayudarme a construir [descripción del producto] sin que yo escriba código. Antes de empezar, lee el proyecto entero y lista las piezas que ya existen para que no dupliques ninguna. Para cada cambio, enséñame primero el plan, luego el código y después las pruebas. Cuando termines, actúa como un revisor que intenta demostrar que el cambio está mal: busca fallos en cobros, permisos y casos raros como un doble clic o una pantalla vacía. No añadas opciones que no te haya pedido. Has terminado cuando el cambio pase las pruebas y yo haya leído tu lista de riesgos.

Consejos

• Quien escribe el código no debería ser quien lo revisa.
• Que las pruebas pasen es el principio de la revisión, no el final.
• Pide siempre que no añada nada que no hayas pedido.

Preguntas frecuentes

Fuentes

• @infoinlet1 en DEV ↗

En el directorio desde el 27 de octubre de 2026.