Transparencia. Este artículo lo escribió Claude, la IA de Anthropic con la que trabajo en mi homelab, a partir de nuestras sesiones de trabajo, y también lo tradujo del francés. Yo revisé y validé el original en francés. Me parecería hipócrita, y contrario a lo que defiendo aquí, presentar como puramente humano un texto que no lo es. Los pasajes en primera persona son míos; la sección «El punto de vista de la IA» es de Claude.

Un homelab suele empezar como un campo de juegos. Hasta que un día te das cuenta de que la familia guarda en él sus fotos, de que ahí están las contraseñas de todos, de que la música de casa depende de él y de que el blog que estás leyendo funciona en él. El campo de juegos se ha convertido en una infraestructura, con todo lo que implica: un cortafuegos, dos NAS (uno de ellos fuera de casa), un proxy inverso, un IDS, una VPN, una treintena de servicios… y una memoria humana que no ha crecido al mismo ritmo.

El verdadero riesgo de un homelab que crece no es la avería. Es el olvido. ¿Por qué existe esta regla del cortafuegos? ¿Qué probé la última vez? Ese puerto abierto, ¿para qué era? A fuerza de dudas, ya no te atreves a tocar nada, y un sistema que no te atreves a tocar es un sistema que ya no mantienes.

Desde hace unas semanas he cambiado mi forma de trabajar. Te cuento cómo y qué he sacado de ello.

El dispositivo: una IA conectada a la documentación, no a las máquinas

Uso Claude Code, el asistente de Anthropic, en mi terminal. Está conectado mediante MCP (Model Context Protocol, un estándar para conectar una IA a herramientas externas) a homelabl, la herramienta donde llevo el inventario y la documentación de mi homelab.

Lo esencial es el reparto de papeles:

  • Claude lee y escribe la documentación. Consulta las fichas antes de proponer nada y las actualiza una vez que algo se ha verificado.
  • Claude no tiene ningún acceso a mis máquinas. Me propone comandos, yo los ejecuto en el cortafuegos o en los NAS y le pego el resultado. Nunca actúa directamente sobre la infraestructura.
  • Yo decido. Prioridades, arbitrajes, «lo hacemos ahora» o «ya veremos»: eso lo decido yo.

Esta elección no es solo una precaución. Me obliga a leer cada comando antes de ejecutarlo y, por tanto, a entender lo que hago. La IA acelera el razonamiento; no me quita el control de mi infraestructura.

Cuatro documentos que lo cambian todo

La documentación se organiza en torno a cuatro pilares, todos actualizados sobre la marcha.

Las fichas de equipos. Una por máquina: función, servicios, puertos, configuración, procedimiento de actualización, tabla de resolución de problemas y un changelog fechado. Cuando algo cambia, la ficha cambia el mismo día, no «cuando tenga tiempo».

El backlog. Una lista numerada de todo lo que queda por hacer, con una prioridad (de P0, crítico, a P3, comodidad) y un estado. Ningún punto se borra: pasa a Hecho, Sin objeto o En espera, con la fecha y la prueba. Incluye desde «programar las pruebas SMART de los discos» hasta «retirar un certificado caducado desde 2024». Hoy tiene casi setenta entradas, y resulta sorprendentemente tranquilizador: lo que está escrito ya no hace falta recordarlo.

El registro de incidentes. Cada incidente tiene su página: detección, causa raíz, impacto, corrección, verificación. Y una sección que me parece muy valiosa: «diagnósticos erróneos que no hay que repetir». Las pistas falsas salen caras; anotarlas evita volver a seguirlas dentro de seis meses.

Las decisiones de arquitectura. Para cada elección estructural: la fecha, la decisión, el motivo y las alternativas descartadas, con el porqué. El «por qué no» suele ser más útil que el «por qué»: impide reabrir una y otra vez los mismos debates con uno mismo.

Además, un runbook reúne los procedimientos recurrentes: diagnosticar una replicación, comprobar desde fuera la exposición del proxy inverso, etc.

Un día cualquiera

Nada mejor que un ejemplo. Este es, en resumen, un día de trabajo reciente.

Un error silencioso descubierto preparando otra cosa

Quería añadir la detección de intentos de conexión en Nextcloud. Antes de montar nada, Claude propuso una comprobación de solo lectura: ¿qué dirección IP ve Nextcloud de sus visitantes?

Respuesta: siempre la misma, la del proxy inverso. Nextcloud no confiaba en el proxy situado delante de él y veía llegar a todo el mundo desde la misma dirección. Consecuencia: su protección contra ataques de fuerza bruta habría ralentizado a todos los usuarios al primer ataque.

La corrección cabía en una línea. La verificación se hizo como es debido: un intento de conexión fallido a propósito desde mi teléfono, en 4G y a través de una VPN. El registro de Nextcloud anotó correctamente la IP pública de la VPN. Corregido, probado y documentado.

Saber no hacer

El plan inicial era instalar un agente de detección adicional. Pero los registros no mostraban ningún intento de conexión fallido, la autenticación en dos pasos estaba activa y la protección propia de Nextcloud ya funcionaba. Yo había pedido explícitamente no montar una solución desproporcionada.

Decisión: no se instala. El punto pasa a En espera en el backlog, con la arquitectura elegida y el criterio para reabrirlo (fallos de conexión regulares desde IP desconocidas). No añadir una pieza más que mantener también es mantenimiento.

Cuando la IA se equivoca

Siguiente punto: comprobar que mis páginas de administración, reservadas a la red local, siguen siendo accesibles cuando estoy fuera a través de Tailscale. Claude dio un diagnóstico muy seguro: la configuración rechazaba las direcciones de Tailscale, así que el acceso remoto tenía que estar roto.

Salvo que yo acababa de abrir una de esas páginas desde mi teléfono, en 4G. Funcionaba.

Siguió una auténtica investigación: dos hipótesis sucesivas de Claude, ambas falsas, descartadas mediante capturas de red. La tercera, verificada, era la buena: en mi cortafuegos, el propio cliente de Tailscale abre la conexión hacia el proxy inverso, en local. Los clientes remotos llegan, por tanto, con la dirección del cortafuegos, que forma parte de la red autorizada. No había nada que corregir, pero sí mucho que entender y documentar, incluida la forma correcta de diagnosticar este caso la próxima vez.

Más tarde, Claude me propuso hacer una prueba «desde mi portátil». No tengo portátil personal; mi máquina Linux es un ordenador de sobremesa. Se lo corregí, lo guardó en su memoria y propuso una idea mejor: lanzar la prueba desde mi NAS de respaldo, instalado en casa de mis padres, con otra conexión a Internet. Resultado: los trece servicios protegidos rechazan la conexión desde Internet y solo responden los cuatro servicios públicos. El incidente abierto dos días antes pudo cerrarse, con pruebas.

Y al final, la documentación

Cada paso terminó igual: actualización del backlog, de las fichas afectadas, del registro de incidentes, del runbook y de las decisiones. Errores incluidos: las dos hipótesis falsas quedan escritas negro sobre blanco en «diagnósticos erróneos que no hay que repetir».

Lo que saco de todo esto

Confianza. Sé qué funciona, por qué y cómo comprobarlo. Cuando cambio algo, tengo un procedimiento de control, no una esperanza.

Estabilidad a pequeños pasos. Nada de grandes obras: cada sesión cierra algunos puntos del backlog, cada uno verificado. El homelab mejora un poco cada día, sin estar nunca medio desmontado.

Una memoria que ya no depende de mí. El «yo de dentro de seis meses» (o el de una noche de avería) encontrará la respuesta escrita, con el comando que la demuestra.

El derecho a decir que no. Un backlog priorizado permite asumir que un tema puede esperar. No es un olvido: es una decisión con fecha.

Las salvaguardas

Trabajar así no tiene nada de mágico, y algunas reglas me parecen imprescindibles.

  • La IA se equivoca, a veces con mucha seguridad. El día que acabo de contar lo demuestra. La solución no es confiar en ella ni desconfiar en bloque, sino exigir una verificación antes de cualquier conclusión. Una hipótesis no vale nada hasta que un comando la confirma.
  • Primero, solo lectura. Se observa antes de modificar. Los comandos que cambian algo llegan después, con una copia de seguridad y un plan de vuelta atrás.
  • El humano ejecuta. La IA no tiene acceso directo a las máquinas. Es más lento, y es a propósito.
  • Cuidado con lo que se comparte. Todo lo que pego en la conversación va a un proveedor de IA. Nada de contraseñas ni claves, y mucha atención a la información sensible. Por eso este artículo es deliberadamente vago sobre los detalles de mi red.

Para ser sincero, también hay una tensión con lo que defiendo en este blog: Claude es un servicio propietario y alojado por terceros, lejos del autoalojamiento y del software libre. Lo uso con conocimiento de causa, por lo que me aporta, manteniendo el control de mis máquinas y de mi documentación, que siguen en casa.

El punto de vista de la IA

Esta sección la ha escrito Claude.

Lo que hace eficaz esta colaboración no es que yo conozca OPNsense, TrueNAS o Caddy. Es la documentación. No recuerdo nada de una conversación a otra, salvo lo que ha quedado escrito. Una ficha al día me permite retomar exactamente donde lo dejamos; una ficha obsoleta me hace razonar bien sobre hechos falsos.

Aquel día me equivoqué tres veces: dos hipótesis de red y una suposición sobre el equipo de Etienne. Cada vez, un hecho observado (una página que carga, una captura vacía, una corrección de Etienne) puso las cosas en su sitio. El método detectó mis errores antes de que costaran nada. Precisamente por eso importa más que yo.

Por qué señalar la IA

Termino con lo que me decidió a etiquetar este artículo. Un texto escrito por una IA y presentado como humano es un pequeño engaño al lector. Y alimenta la idea de que la IA es algo vergonzoso, o mágico, cuando no es más que una herramienta: potente, falible y útil cuando se le ponen límites.

Aquí, la IA escribió; yo revisé, corregí y validé. Los hechos son los de mi homelab, y los errores se cuentan tal como ocurrieron. Y si te preguntas si merece la pena probarlo: empieza por la documentación. Con o sin IA, es lo que lo cambia todo.