Sistemas que se autoreplican: mi idea obsesiva con Claude

Llevo semanas obsesionado con una idea. Que no es mía, que no he inventado yo, pero que desde que la pillé no paro de darle vueltas.

Sistemas que se autoreplican.

O sea. Construyes algo una vez. Lo dejas funcionando. Y luego, cuando necesitas algo parecido para otro proyecto, no empiezas de cero. La IA lee cómo está montado lo tuyo y lo replica. Automatizar la automatización. Lo meta que te cagas.

¿Por qué esto me parece la hostia?

Porque rompe la trampa de siempre. Tú currabas, montabas un sistema, y cuando tenías que hacer uno parecido, volvías a currar desde cero. Otra vez. Con tus apuntes dispersos, tus "a ver cómo hice esto la última vez", tu "ostras, esto lo configuré hace seis meses y no me acuerdo de nada".

Y cada proyecto era un reinicio. Tiempo tirado.

Con Claude Code y la documentación bien hecha, la cosa cambia. El sistema que ya tienes se puede explicar a sí mismo. Y una vez que se explica, se replica. No exactamente igual, que cada proyecto es diferente, pero la base, la estructura, las decisiones de seguridad, los parches, todo eso se transporta.

Lo he probado en carne propia esta semana. Y cuando lo ves funcionando, te pone los pelos de punta.

El ejemplo real: la web de mi hermano

Mi hermano tiene un proyecto que se llama El Encantador de Padres. Si tienes hijos, ya estás tardando en seguirlo, pero esto es otra historia.

El caso es que me dijo Rubén necesito una web. Y yo ya tengo mi web montada en un servidor propio, con PM2, Caddy, auto-deploy por webhook, firewall, WAF, backups diarios, monitorización. Todo el pack. Tardé meses en dejarlo fino.

Cogí Claude Code. Le dije oye, vamos a replicar mi setup de servidor para otra web. Pero agnóstico a mi proyecto, sin datos sensibles, que lo pueda usar otra persona. Crea un tutorial completo.

Y Claude se puso. Lanzó subagentes. Leyó toda la documentación que yo tenía sobre mi infraestructura. Entendió cómo está montado el PM2, cómo funciona el auto-deploy, cómo están los balanceos de carga, dónde están las claves SSH, cómo se configura el Caddy. Todo.

Y me generó un archivo Markdown explicándolo todo. Para alguien no técnico, con instrucciones claras. O para otra IA, con el contexto suficiente para que lo montara ella.

Le di el servidor a mi hermano. Conectamos. Y en un día de trabajo tenía su web funcionando. Con la misma base que la mía, las mismas configuraciones de seguridad, el mismo flujo. Un día.

¿Por qué un día y no tres meses?

Porque el trabajo duro ya estaba hecho. Y documentado.

Aquí está la clave que la gente no pilla cuando habla de IA. Todos hablan de prompts, de modelos, de cuál es mejor, de qué plan tienen contratado. Y se saltan la única cosa que importa de verdad.

La gestión documental.

Sin documentación, Claude es un becario con memoria corta. Con documentación, Claude entiende el contexto completo de lo que has montado y puede replicarlo. Es la diferencia entre que te ayude a escribir un post y que te clone media infraestructura.

Lo decía en por qué tus prompts nunca funcionan. Contexto por encima de prompts. Hasta que no lo interiorizas, la IA te parece un juguete. Cuando lo entiendes, se convierte en un trabajador serio.

La trampa de documentar a mano

Esto a mí me ha pasado toda la vida como programador.

Tú empiezas un proyecto. Le metes caña. Vas tomando decisiones. "Esto lo hago así porque tal", "esto lo dejo pendiente porque lo otro", "esta librería la uso porque la versión vieja me dio problemas". Decisiones.

¿Cuántas de esas decisiones documentas?

Ninguna. Cero. O pones un comentario en el código en plan "TODO: revisar esto" que nunca revisas. Y a los seis meses vuelves al proyecto y no tienes ni idea de por qué algo está hecho de una forma concreta.

Documentar a mano cada decisión, cada funcionalidad, cada parche, a qué afecta, qué implica cambiarlo, eso es una locura. Una locura absoluta. No lo hace nadie. Ni los equipos grandes con tiempo.

Pero cuando delegas esa tarea a la IA, la cosa cambia. Cada cambio que haces, cada deploy, cada decisión, la IA lo puede documentar al vuelo. Y lo deja en un archivo .md separado del código, en su propio repositorio si quieres.

¿Por qué en un repo aparte? Porque los comentarios en código son migajas. Sirven para entender una línea, no para entender por qué un sistema completo está montado de cierta forma. La documentación de verdad vive fuera. En su sitio.

Esto es justo lo que cuento en cómo creé un CRM completo hablando con una IA. El código es lo de menos. La documentación es lo que permite que el sistema evolucione sin romperse cada vez que tocas algo.

¿Qué significa exactamente "autorreplicable"?

Que el sistema sabe explicarse a sí mismo.

Tú le dices a Claude "explica cómo está montado esto" y él lee su propia documentación, entiende la estructura, y genera un tutorial. Tutorial que luego sirve:

Para ti, cuando quieres hacer un proyecto parecido y no quieres empezar de cero.

Para otra persona, si le vendes el setup o le ayudas a montar algo similar.

Para otra IA, si el sistema crece y necesitas delegar trozos a agentes nuevos.

La clave es que el tutorial no es genérico ni falso. Es fiel a cómo está montado lo tuyo. Porque sale de la documentación real del sistema, no de una plantilla sacada de un blog de internet.

Y ojo. Esto no es solo para webs ni para programación. Esto aplica a cualquier sistema complejo que hayas montado. Un funnel de ventas. Un flujo de emails. Un CRM. Un sistema de gestión de clientes. Una operativa de tu agencia. Todo lo que tenga suficiente complejidad para que replicar desde cero sea lento, se beneficia de esto.

¿Cualquiera puede hacerlo?

Aquí no te voy a mentir.

Cualquiera puede empezar, sí. Pero montar un sistema autoreplicable decente el primer día, sin ningún conocimiento técnico, no es realista. Hay que entender qué merece la pena documentar y qué no. Qué abstraer. Qué decisiones son clave y cuáles son irrelevantes.

Eso requiere algo de recorrido. Cada vez menos. Las barreras están cayendo. Pero cero, no.

Lo que sí es cierto es que, una vez que tienes la base montada, la velocidad de desarrollo que te da esto es bestial. Yo hago literalmente cientos de deploys a la semana en mi web. Y la cantidad de errores que me salen es ridícula. Porque Claude entiende a qué afecta cada cambio, lo revisa en la documentación, y no toca cosas que no tiene que tocar.

Como desarrollador, yo programando a mano nunca tuve esta velocidad ni esta precisión. Ni de lejos. Te lo digo en serio.

Lo meta: un sistema que crea sistemas

Esto es lo que me flipa de todo.

Al final lo que tienes es un sistema que crea otros sistemas. Skills que crean skills. Plantillas que generan plantillas. Documentación que pare documentación.

Y cada vez que creas uno nuevo, es más fácil crear el siguiente. Porque cada sistema es input de los que vienen detrás.

Hace años esto sonaba a ciencia ficción. Hoy es mi rutina de los martes por la mañana.

El trabajo no desaparece. La parte creativa sigue siendo tuya. Las decisiones estratégicas, también. Pero toda la parte repetitiva, la de "ya hice esto una vez y ahora lo tengo que hacer otra vez para otro proyecto", esa parte se evapora.

Y cuando se evapora, te queda tiempo para lo que importa. Para pensar. Para crear cosas nuevas. Para no estar peleándote con el mismo archivo de configuración por décima vez.

Si te interesa ver por dentro cómo tengo montado todo esto, desde el servidor hasta el bot de Telegram que me lo controla desde el móvil, aquí te lo dejo.

Ver mi setup de Claude Code