Claude Code para desarrollo y automatización

El dominio de Claude Code pesa un 3,1 %. Parece poco, hasta que miras el resto de la guía: la gestión de configuración de D2 pregunta por CLAUDE.md, settings.json, fijar la versión del modelo y dependencias de plugins; D7 tiene un apartado entero de hooks para frenar acciones destructivas; y D6 pide aislar contexto con subagentes. Sumado, Claude Code aparece en bastantes más preguntas de las que su etiqueta sugiere.

Esta lección no va de atajos de teclado. Va de lo que un desarrollador configura para que Claude Code trabaje en un repositorio real de forma predecible y segura, y de cómo lo sacas de tu terminal para ponerlo a trabajar en CI.

Las piezas de Claude Code

Claude Code es un agente que lee tu código, edita ficheros y ejecuta comandos. Todo lo que lo personaliza vive en ficheros que puedes versionar. Pulsa cada pieza:

La idea de examen que atraviesa toda la lección: si algo tiene que cumplirse siempre, no basta con escribirlo en CLAUDE.md. Va en permisos o en un hook.

CLAUDE.md y settings.json: jerarquía y precedencia

CLAUDE.md se acumula. Claude Code carga varios niveles a la vez: la política gestionada de la organización, el tuyo de usuario (~/.claude/CLAUDE.md), el del proyecto (./CLAUDE.md o ./.claude/CLAUDE.md, compartido en el repo) y el local (./CLAUDE.local.md, personal y en .gitignore). Los de directorios por encima del de trabajo se cargan al arrancar; los de subdirectorios, cuando Claude lee ficheros allí.

Tres consejos oficiales que salen en preguntas: /init genera un primer CLAUDE.md analizando el repo (y si ya existe, propone mejoras en lugar de sobrescribir); apunta a menos de 200 líneas por fichero, porque más texto gasta contexto y baja el cumplimiento; y puedes importar otros ficheros con @ruta/al/fichero.

settings.json se sobrescribe por prioridad. De más a menos: ajustes gestionados (los de la empresa, no se pueden anular), argumentos de línea de comandos, .claude/settings.local.json (tuyo en ese proyecto), .claude/settings.json (del equipo, en el repo) y ~/.claude/settings.json (tuyo, global). Una excepción importante: con los permisos, una regla deny de cualquier nivel gana a un allow de cualquier otro.

Un settings.json de proyecto razonable para un repo con integración SAP:

{
  "model": "claude-opus-5-5",
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git commit *)"],
    "deny": ["Read(./.env)", "Read(./secrets/**)", "Bash(git push *)"]
  },
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash",
        "hooks": [
          { "type": "command", "if": "Bash(rm *)", "command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/block-rm.sh" }
        ]
      }
    ]
  }
}

Fíjate en tres cosas. El modelo va fijado con su ID (claude-opus-5-5), y en la API cada ID actual es una instantánea fija: así un cambio de modelo es una decisión que pasa por revisión, no una sorpresa. Los permisos se evalúan en orden deny, ask, allow y gana la primera coincidencia. Y los secretos se protegen con reglas deny de lectura, no con una frase en CLAUDE.md.

Los modos de permisos completan el cuadro: default (pregunta la primera vez que usa cada herramienta), acceptEdits (acepta ediciones de ficheros), plan (explora y propone sin editar el código), auto (un clasificador revisa cada acción en segundo plano en lugar de preguntarte), dontAsk (deniega lo que no esté preaprobado) y bypassPermissions (se salta los avisos; solo para entornos aislados). Con Shift+Tab los recorres en la sesión.

Hooks: la barrera que no depende del modelo

Un hook PreToolUse recibe en JSON por stdin la herramienta y sus argumentos antes de que se ejecute. Recorre cómo se resuelve el del ejemplo:

Dos matices que se preguntan. Un hook que no dice nada no aprueba: la llamada sigue el flujo normal de permisos. Y una regla deny sigue mandando aunque el hook devuelva allow. Además de command, hay hooks de tipo http, mcp_tool, prompt (un modelo evalúa) y agent (experimental).

Usos típicos más allá de bloquear: PostToolUse para pasar el formateador o el linter tras cada edición, y Stop para comprobar que los tests pasan antes de dar la tarea por terminada.

Subagentes: contexto aislado

Cada subagente corre en su propia ventana de contexto, con su prompt, sus herramientas y sus permisos, y devuelve solo el resultado. Se definen en .claude/agents/ (proyecto) o ~/.claude/agents/ (todos tus proyectos) con un frontmatter: name y description obligatorios; tools, model, permissionMode, skills o isolation: worktree opcionales. La description es lo que Claude lee para decidir cuándo delegar, igual que la de una herramienta.

Para qué sirven en examen: aislar contexto. Si una tarea exige leer cuarenta ficheros para encontrar dónde se calcula un precio, que lo haga un subagente de solo lectura y te devuelva la respuesta; tu conversación principal no se llena de ruido. Y limitar herramientas: un revisor con tools: Read, Grep, Glob no puede editar aunque quiera.

Para la higiene de sesión, el resto de comandos que conviene tener claros: /compact resume la conversación para liberar contexto, /clear empieza de cero en otra tarea, claude --continue retoma la última sesión del directorio y claude --resume te deja elegir.

Headless y CI: Claude Code sin pantalla

Con -p (o --print), Claude Code se ejecuta de forma no interactiva: recibe la tarea, trabaja y devuelve el resultado. Es la base de scripts, pipelines y del propio Agent SDK.

# Tarea con herramientas preaprobadas y salida JSON (incluye coste estimado)
$ claude --bare -p 'Revisa el diff y lista riesgos' --allowedTools 'Read,Grep' --output-format json
# Salida que cumple un esquema: llega en el campo structured_output
$ claude -p 'Clasifica este log' --output-format json --json-schema '{«tu esquema JSON»}'
# Cortar el bucle si se alarga
$ claude -p --max-turns 5 'Arregla el test que falla en tests/test_pedidos.py'
# Integración con GitHub: instala la app, crea el secreto y el workflow
$ /install-github-app

Ojo con un detalle de seguridad de la documentación: sin --bare, una ejecución con -p carga los hooks del .claude/settings.json del repo y conecta los servidores de su .mcp.json sin diálogo de confianza. En un pipeline que procesa código de terceros, eso importa.

Para GitHub Actions, el camino rápido es /install-github-app desde Claude Code: instala la app de GitHub, guarda la credencial como secreto del repositorio (ANTHROPIC_API_KEY, o CLAUDE_CODE_OAUTH_TOKEN si usas suscripción) y abre un pull request con el workflow. A partir de ahí, mencionar @claude en una issue o en un PR lanza el trabajo. La clave vive en los secretos de GitHub, nunca en el YAML.

Si trabajas con ABAP, todo esto encaja con ADT en VS Code: Claude Code no sustituye al sistema de transportes, pero puede preparar y revisar el código en local. Tienes el contexto en ADT for VS Code.

Para el examen

Siguiente parada

Próxima lección: el Claude Agent SDK. Workflow o agente, el bucle agéntico por dentro, herramientas propias, subagentes y hooks en código, sesiones, y cuándo usar el Agent SDK, tu propio bucle o Claude Managed Agents.