Cómo usa Claude Code su propio creador (y qué puedes copiar para tu homelab)

JaimeAlberto
Herramientas, Sysadmin
Índice
Cómo usa Claude Code su propio creador (y qué puedes copiar para tu homelab)

Boris Cherny es el creador de Claude Code. Lo construyó y lo usa a diario. En los últimos meses ha publicado sus técnicas y principios de uso — la mayoría orientados a desarrollo de software de producto. Pero hay algo interesante: casi todo funciona igual de bien si en lugar de escribir código de aplicación estás administrando servidores, automatizando tareas o gestionando un homelab.

Este artículo recoge las ideas más útiles y las traduce a ese contexto.

Quién es Boris Cherny

Boris Cherny es ingeniero en Anthropic, donde creó Claude Code — el CLI que permite usar Claude directamente desde la terminal. Antes trabajó en Meta. Es también el autor de Programming TypeScript (O’Reilly, 2019).

Ha publicado sus principios de uso en su web personal y en LinkedIn. No son trucos de prompt engineering. Son principios de flujo de trabajo — cómo estructurar las tareas, cuándo intervenir, cómo evitar que la IA haga cosas que no querías.

El principio más importante: verificación

“Siempre dale a Claude una forma de verificar su propio trabajo.”

Esta es la idea que más multiplica la calidad del resultado. No es dar instrucciones mejores — es dar a Claude una forma de comprobar que lo que hizo funciona antes de darte la respuesta.

En desarrollo de software esto se hace con tests. En sysadmin es igual de fácil:

  • Después de un cambio en un servicio: systemctl status nombre.service
  • Después de editar una configuración: nginx -t o sshd -T
  • Después de abrir un puerto: ss -tlnp | grep puerto
  • Después de crear un registro DNS: dig nombre @servidor

Si le dices a Claude qué comando usar para verificar, lo ejecutará y te dirá si el resultado es el esperado. Sin ese paso, Claude asume que funcionó porque el comando no dio error — y eso no es lo mismo.

La diferencia en calidad es notable. Cherny la describe como un multiplicador 2-3x.

Plan Mode: pensar antes de actuar

Claude Code tiene un modo de planificación que se activa antes de empezar a ejecutar. En ese modo, Claude describe lo que va a hacer, qué ficheros va a tocar y por qué, sin hacer nada todavía. Puedes leer el plan, corregirlo, y solo entonces autorizar la ejecución.

Cherny recomienda usarlo en tareas que:

  • Tocan más de tres ficheros o sistemas a la vez
  • Son difíciles de revertir
  • Afectan a algo en producción

En un homelab: cambios en el firewall, modificaciones de red, actualizaciones que afectan a varios servicios, cualquier cosa que si sale mal implique tiempo de inactividad.

La ventaja no es solo seguridad — es que el plan te obliga a pensar si el enfoque es correcto antes de que Claude empiece a ejecutar. Es mucho más fácil corregir un plan que deshacer diez cambios en cascada.

Contexto upfront: tres preguntas antes de empezar

Cuando la tarea es compleja, Cherny recomienda definir explícitamente tres cosas antes de que Claude empiece:

  1. Goal — qué se quiere conseguir exactamente
  2. Constraints — qué no se puede tocar, qué límites existen
  3. Acceptance criteria — cómo sabemos que está hecho

En la práctica, esto parece excesivo para tareas pequeñas. Pero para tareas que duran varios pasos — instalar un servicio nuevo, migrar datos, configurar monitorización — define la diferencia entre “Claude hizo lo que pedí” y “Claude hizo lo que necesitaba”.

Un ejemplo real: “quiero monitorizar si cae internet en casa” puede derivar en cien soluciones distintas. Con contexto upfront queda claro: la solución tiene que funcionar sin depender de internet para enviar la alerta (constraint), y la prueba de que funciona es desconectar el router y recibir la notificación en el móvil en menos de dos minutos (acceptance criteria).

CLAUDE.md: la memoria del sistema

Claude Code lee un fichero CLAUDE.md en el directorio de trabajo al inicio de cada sesión. Ahí puedes escribir todo lo que normalmente tendrías que repetir en cada conversación: cómo se llama cada host, qué convenciones usas, qué cosas no se deben tocar nunca, cómo verificar cambios.

Cherny lo describe como un sistema de aprendizaje: cuando descubres un patrón que funciona bien, lo escribes ahí para que persista. Cuando algo sale mal, también. Con el tiempo, ese fichero acumula el conocimiento operativo del entorno.

Para sysadmin esto es especialmente útil. Un CLAUDE.md que describe la topología de red, los nombres de los hosts, los procedimientos de backup y las reglas de seguridad que no se deben vulnerar transforma a Claude de “asistente genérico” a “alguien que conoce tu infraestructura”.

/btw y /loop: dos herramientas de flujo

/btw — permite hacer una pregunta lateral sin interrumpir la tarea en curso. Si estás en medio de configurar algo y surge una duda sobre otra cosa, /btw te da la respuesta sin perder el contexto de lo que estabas haciendo.

/loop — lanza Claude en modo autónomo para tareas largas. Claude ejecuta, verifica, avanza, y solo te interrumpe si necesita una decisión. Para tareas background — publicar un artículo programado, revisar logs de un sistema, ejecutar una secuencia de pasos — es el mecanismo nativo de automatización.

Lo que es distinto en español

La mayoría de lo que Cherny ha publicado sobre Claude Code está en inglés y orientado a ingenieros de software de producto. Hay poca documentación en español sobre cómo aplicar estas técnicas a tareas de infraestructura.

La brecha no es técnica — Claude entiende español perfectamente y los mismos principios aplican. La brecha es de ejemplos y contexto. Un artículo sobre cómo instalar un servicio en Proxmox, configurar OPNsense o automatizar backups con estas técnicas en castellano tiene audiencia que no está bien cubierta.

Si administras servidores en casa o en una pyme, las herramientas son las mismas. El flujo de trabajo de Cherny no requiere saber programar — requiere saber qué quieres conseguir, cuáles son los límites y cómo vas a verificar que funciona. Eso es exactamente lo que hace un buen sysadmin.

Fuentes: