Claude Code para DevOps

Cristian Córdova

19 feb. 2026 • 9 min read

IA para Devops

¿Quieres mejorar los procesos de desarrollo, la eficiencia, la escalabilidad y seguridad en tu Cloud a la vez que ahorras costes?

Contacta con nuestro equipo de expertos en infraestructura Cloud y lleva tus aplicaciones al siguiente nivel.

Visita nuestra web

⚠️

Esto no es un mandatory ni un consejo de buenas prácticas ni algo escrito en piedra. Solo una muestra de cómo Claude Code puede ayudar en el día a día del trabajo de infraestructura. No solo escribiendo código sino operando sobre el Cloud y sus herramientas.

He pasado varias horas durante varios días documentando y optimizando todo mi entorno local para poder "mecanizar" el trabajo que hago día a día administrando infraestructura de multiples Startups.

Sin querer, a lo largo de los años ya había ido creando una rutina de comandos, rutas y una serie de herramientas que me permitían trabajar siempre de la misma manera, lo que me ha facilitado mucho el poder automatizarlo a través de Claude Code.

Repositorios

Antes de entrar en IA quiero compartir cómo organizo mis repositorios. Esto es algo bastante personal pero en mi caso y dado que trabajo con multiples empresas cada una con sus propias infraestructuras, accesos, repositorios, etc. Lo he organizado de la siguiente forma.

En el home de mi user tengo un directorio llamado repository . Dentro de este tengo un directorio por cada cliente:

➜  repository
------ cliente-A
------ cliente-B
------ ........
------ ........
------ cliente-Z
------ helmcode
------ CLAUDE.md
------ .agents
------ .claude

Cada directorio de cliente sigue también una misma estructura (o muy parecida), ejemplo del contenido de cliente-A:

➜  repository
------ cliente-A
------------ devops # Repositorio de infra
------------------------ argocd
------------------------ helm
------------------------ terraform
------------------------ README.md
------------------------ CLAUDE.md
------------ app-A # Repositorio de app
------------------------ .workflow/build-deploy.yaml
------------------------ [Otros directorios con código de la app]
------------ app-B # Repositorio de app
------------------------ .workflow/build-deploy.yaml
------------------------ [Otros directorios con código de la app]

El repositorio de devops es nuestra base de trabajo, aquí tenemos manifiestos, helm charts, apps de ArgoCD, etc. Todo lo necesario para trabajar y operar sobre la infraestructura del cliente se encuentra aquí.

En los repositorios de las apps de los clientes realmente lo que nos interesa son los ficheros de los Pipelines. En este ejemplo cliente-A usa GitHub Actions pero tenemos clientes que usan GitLab CI y otros que usan Bitbucket Pipelines. Eso es lo de menos y eso es lo bonito, que cada uno puede tener su propio contexto como veremos mas adelante.

Volvamos un momento al repositorio de devops , este tiene un CLAUDE.md el cuál nos debe dar un contexto de:

Arquitectura a alto nivel: Cloud en el que está, región, arquitectura, comunicación de sus servicios, si tiene servicios públicos y privados, etc
Herramientas/Tecnologías que usa el cliente: Kubernetes, Helm, Argo, etc
Entornos que tiene el cliente: producción, dev, staging, preproducción, etc
Dominios principales por entorno: "app.cliente-a.com", "app.dev.cliente-a.com", etc
Incluso si es que tiene alguna particularidad como que requiere de VPN para comunicar con su infraestructura. Qué tipo de CI/CD usan para sus servicios, etc

🚨

Es muy importante que en este fichero le deis un contexto de alto nivel, no es necesario añadir aquí workflows de trabajo ni procesos específicos mas amplios ya que como veremos mas adelante para eso están otras opciones más útiles.

Esto se debe hacer en cada una de las carpetas de cliente. De esta forma la IA tendrá un contexto muy claro de qué puede hacer y cómo lo debe hacer en cada cliente.

Skills, incluyendo workflows y flujos.

➜  repository
------ CLAUDE.md
------ .claude

Lo segundo que tenemos dentro del directorio repository es el directorio .claude . Si lleváis un tiempo ya trabajando con Claude Code sabréis que este es su directorio principal. El global lo tendréis en el home de vuestro usuario pero en mi caso tengo este a nivel de "proyecto" porque quiero que este sea muy específico para mi día a día administrando infraestructura Cloud.

Dentro del directorio de .claude tengo:

➜  .claude
------ settings.local.json
------ skills

Dado el título, empecemos por el directorio de Skills. Si no habéis oído hablar de las skills os aconsejo mucho esta docu de Anthropic donde os da un ejemplo de cómo crear y para qué sirven las skills.

Por resumir mucho, básicamente es una documentación con una estructura específica que sirve para poder "enseñarle" a tus agentes, en este caso, Claude Code. A hacer algo específico.

Por ejemplo, en mi caso tengo varias skills, no solo para cosas de infraestructura sino también para cosas de desarrollo. Podéis encontrar e instalar skills de lo que vosotros queráis aquí: https://skills.sh/

Sin embargo, algo MUY poderoso es crear tus propias skills. Por ejemplo, en nuestro caso gestionamos los usuarios de VPN de todos los clientes mediante un script. Tenemos un script por cada cliente pero el uso de ese script en cada cliente es exactamente el mismo, sin embargo, requiere de una serie de pautas e indicaciones para poder usarlo correctamente.

Este "conocimiento" de indicarle el flujo de trabajo de lo que debe hacer es muy sencillo de documentar en una skill para que cuando necesitemos, por ejemplo, dar de alta un nuevo usuario en una VPN solo le tenemos que decir: "Da de alta en la VPN al user Gandalf el Gris en el cliente A".

Con esto, Claude Code, detectará que tiene una skill para ello y sabrá exactamente qué debe hacer para gestionar esa petición.

Este es solo un ejemplo, ya depende de vosotros, de vuestro trabajo y de vuestra lógica de negocio proveerle de tantas skills como creáis conveniente para que realice flujos de trabajo completos de un solo mensaje.

Os comparto algunas de las skills que yo uso y que son públicas y por tanto cualquiera puede instalar. Algunas son para cosas de infraestructura y otras para cosas de desarrollo:

architecture-patterns
async-python-patterns
fastapi-templates
frontend-design
golang-pro
helm-chart-scaffolding
mcp-builder
python-performance-optimization
python-testing-patterns
skill-development
tailwind-design-system
terraform-module-library
terraform-style-guide
terraform-test
vercel-react-best-practices

Todas ellas las podréis encontrar e instalar con el servicio que os mostré antes.

Permisos

Otra de las cosas que vemos dentro del directorio .claude es el fichero de settings.local.json . Este fichero es el que permite configurar ciertas cosas a Claude Code como por ejemplo los permisos.

Esto permite indicarle a Claude Code qué cosas puede hacer sin preguntar, qué herramientas puede usar siempre o al contrario que cosas NUNCA puede hacer.

Esto depende de cada uno. Si bien yo uso Claude Code ahora para todo, en local, siempre superviso lo que hace ya que trabajo con infraestructuras críticas y no puedo permitirme errores.

Por tanto, no tengo muchas cosas permitidas por defecto pero os puedo dar un pequeño ejemplo del contenido de mi settings para que os hagáis una idea:

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  },
  "permissions": {
    "allow": [
      "Bash(ls:*)",
      "Bash(wc:*)",
      "Bash(find:*)",
      "WebSearch",
      "Bash(gh pr view:*)",
      "Bash(source:*)",
      "Bash(terragrunt plan:*)",
      "Bash(gh pr comment:*)",
      "Bash(kubectl get:*)",
      "Bash(aws sts get-caller-identity:*)",
      "Bash(git pull:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(helm search repo:*)",
      "Bash(helm show chart:*)",
      "Bash(nslookup:*)",
      "Bash(dig:*)",
      "Bash(gh auth status:*)",
      "Skill(bender-config)",
      "WebFetch(domain:docs.anthropic.com)",
      "Bash(gh search:*)",
      "Bash(gh issue list:*)",
      "Bash(gh run view:*)",
      "Bash(gh pr diff:*)"
    ]
  }
}

Si bien para tareas de infraestructura, no estoy usando equipos de agentes sino solo un único agente, para algunas tareas de desarrollo si que estoy usando equipos de agentes de Claude Code.

Para eso sirve la env var CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS . Si me seguís en Twitter habréis visto la turra diaria que doy con esto, o en LinkedIn alguna vez he hecho algún post comentando por encima alguna cosa también.

Quizá más adelante haga un post sobre equipos de agentes.

¿Y qué pasa con los famosos MCP?

La verdad es que al principio cuando empecé a utilizar Claude Code empecé a instalar varios MCP para interactuar con todo lo que os he ido comentando antes: Kubernetes, el cloud de turno, etc.

El problema de los MCP, en mi caso particular, es que su configuración es muy cerrada. Ejemplo: el MCP de Kubernetes, en su settings solo me permitía configurar un kubeconfig (Y si yo sé que existen los contextos pero nunca me ha gustado trabajar con eso). Dado que tenemos +20 clusters cada uno con su kubeconfig, esto era completamente inviable para mi. Mismo problema con MCPs de ArgoCD y otras muchas cosas.

Al final, he optado por utilizar principalmente la tool que trae por defecto Claude Code, "Bash()" y que a través de esta llame a las CLI que utilizo en mi día a día (kubectl, argocd, aws, etc)

La ventaja es que estas CLI en su mayoría son bastante populares, por lo que el agente conoce muy bien cómo usar estas CLI y apenas comete errores en su uso. De hecho cuando no tenía tanta documentación hecha, su principal problema era que no sabía que yo trabaja con multiples clientes. Ahora gracias al contexto y su propio conocimiento de la CLI va a tiro hecho la mayoría de las veces.

Por tanto, al menos de momento, en mi flujo de trabajo me está funcionando mucho mejor utilizar directamente las CLI que andar configurando MCPs.

Actualmente, el único MCP configurado que tengo y lo uso principalmente cuando hago cosas de desarrollo Frontend, es el de playwright, que me permite controlar el navegador y así testear mejor la UI.

Planes, Modelos, etc

La realidad es que hasta hace un mes tiraba únicamente con el plan pro ($20/mes) de Claude y alternaba entre Sonnet 4.5 y Opus 4.5.

Sin embargo, desde que anunciaron la inclusión de los equipos de agentes y sacaron Opus 4.6, este plan ya se me ha quedado muy corto y he tenido que pasar al plan Max 5x ($100/mes). Y este con Opus 4.6 también llegaba a los límites varias veces al día pero solo cuando realizo tareas de desarrollo puro y duro. Si me limito a realizar cosas de infraestructura, no llego a quemar los límites del Max 5x ni loco, de momento.

Ahora con Sonnet 4.6 parece que los resultados son buenos e incluso haciendo tareas de desarrollo no llego a los límites de este plan pero veremos a ver con el tiempo qué tan eficiente es este modelo y si no tengo que tirar de Opus de vez en cuando.

En cuanto a tokens, en las últimas semanas por día estoy quemando ~80K tokens. Seguramente si hacéis un trabajo de full desarrollo estaríamos hablando de cifras bastante mayores pero para operar y gestionar infraestructura de varias empresas estos han sido mis resultados.

En Twitter, estoy contando todos los días las diferentes pruebas que voy haciendo y sus resultados, tanto los buenos como los malos. Estaré encantado de escuchar vuestro feedback o ideas sobre todo esto.

Si no queréis perderos más posts de IA enfocada en infraestructura Cloud no os olvidéis de suscribiros. ¡Hasta la próxima! 🖖

Repositorios

Lo más importante es el contexto

Skills, incluyendo workflows y flujos.

Permisos

¿Y qué pasa con los famosos MCP?

Planes, Modelos, etc

Sign up for Helmcode - Blog