La herramienta más cara es la que usas mal
Cuando le digo a alguien que reduje el costo por tarea en Claude Code un ~60% sin sacrificar calidad, lo primero que me preguntan es si cambié de modelo o si limité el uso.
No. Aprendí a configurarlo correctamente.
Claude Code es uno de los agentes de IA más potentes para desarrollo de software que existen hoy. Pero la mayoría de los desarrolladores lo usa como si fuera un chat con superpoderes. Eso es como comprar un Ferrari y manejarlo en segunda velocidad.
En este tutorial voy a mostrarte exactamente cómo lo configuro, con ejemplos reales del setup que uso en mis proyectos.
1. CLAUDE.md: Tu contexto permanente
Esta es la diferencia más grande entre un usuario casual y uno avanzado de Claude Code.
El problema: Cada sesión de Claude Code empieza desde cero. Si no hay contexto guardado, el agente tiene que inferir o preguntarte cosas que ya debería saber: tu stack, tu arquitectura, tus convenciones, tus reglas de negocio. Eso es tokens desperdiciados antes de escribir una sola línea de código productivo.
La solución: El archivo CLAUDE.md en la raíz de tu proyecto.
# Crear el archivo
touch CLAUDE.md
Este archivo se carga automáticamente en cada sesión. Es tu contexto permanente. Todo lo que Claude necesita saber sobre tu proyecto vive ahí.
Qué incluir en tu CLAUDE.md
Un buen CLAUDE.md responde estas preguntas antes de que el agente las haga:
# CLAUDE.md
## Stack tecnológico
- Framework: Next.js 16 con App Router
- Styling: Tailwind CSS + shadcn/ui
- Package Manager: pnpm
- Base de datos: PostgreSQL con Drizzle ORM
## Arquitectura
- Feature-based con Atomic Design
- SOLID principles estrictos
- Server Components por defecto, Client solo cuando necesario
## Comandos importantes
- `pnpm dev` → servidor de desarrollo
- `pnpm build` → build de producción
- `pnpm db:migrate` → correr migraciones
## Convenciones críticas
- NUNCA usar dangerouslySetInnerHTML
- Siempre validar inputs en el servidor
- Los adapters abstraen librerías externas (ver /src/adapters)
## Estructura de directorios
src/
├── adapters/ # Wrappers de librerías externas
├── components/ # Atomic Design (atoms/molecules/organisms)
├── features/ # Módulos por feature
└── hooks/ # Custom React hooks
Impacto real: Con un CLAUDE.md bien configurado, cada sesión empieza con el agente ya orientado. No hay preguntas innecesarias, no hay suposiciones incorrectas, no hay tokens gastados en "descubrir" lo que ya sabe.
CLAUDE.md para el directorio del usuario
También puedes tener un ~/.claude/CLAUDE.md global con preferencias que aplican a todos tus proyectos:
# Preferencias globales
## Estilo de comunicación
- Respuestas concisas y directas
- Sin emojis a menos que yo los use
- Referencias a líneas de código en formato file:line_number
## Idioma
- Código y comentarios técnicos: inglés
- Comunicación: español
## Herramientas preferidas
- Package manager: pnpm (nunca npm o yarn)
- Tests: Vitest + Testing Library
2. Sub-agentes: Divide y vencerás
Este es el cambio de paradigma más importante cuando escalas el uso de Claude Code.
El problema del "prompt gigante": Pedirle a Claude que investigue, implemente, refactorice y pruebe todo en un solo mensaje es ineficiente. El contexto se contamina, el agente pierde el hilo y los errores se propagan.
La solución: Sub-agentes especializados con la herramienta Task.
Claude Code puede lanzar sub-agentes que trabajan de forma autónoma en tareas específicas. Cada agente tiene su propio contexto limpio y una responsabilidad definida.
Cómo funcionan los sub-agentes
Tu tarea principal
├── Agente Explorer → Investiga el codebase, mapea dependencias
├── Agente Implementador → Escribe el código basado en el plan
└── Agente Reviewer → Verifica que no hay errores ni regresiones
Cada agente trabaja en paralelo cuando las tareas son independientes, o secuencialmente cuando hay dependencias.
Ejemplo práctico
En lugar de escribir:
"Investiga cómo funciona el sistema de autenticación, luego agrega soporte para OAuth con Google, asegúrate de que los tests pasen y actualiza la documentación."
Estructúralo así:
- Tarea 1 (Explore): Mapea el sistema de auth actual, identifica los archivos clave y devuelve un resumen.
- Tarea 2 (Plan): Con el contexto del Explore, diseña la implementación de OAuth.
- Tarea 3 (Bash/Implement): Implementa el plan aprobado.
- Tarea 4 (Bash): Corre los tests y valida.
Resultado: Menos tokens desperdiciados en re-orientación, más resultado concreto por sesión.
3. Skills personalizadas
Las Skills extienden lo que Claude puede hacer. Creas un archivo SKILL.md con instrucciones y Claude lo agrega a su toolkit. Puedes invocarlas manualmente con /nombre-skill, o Claude las usa automáticamente cuando las considera relevantes para el contexto.
Estructura de una Skill
Cada skill es un directorio con un SKILL.md como entrypoint. Hay dos alcances:
# Skill personal — disponible en todos tus proyectos
mkdir -p ~/.claude/skills/create-component
# Skill de proyecto — solo este repositorio
mkdir -p .claude/skills/create-component
El SKILL.md tiene dos partes: frontmatter YAML entre --- que configura cuándo y cómo se invoca, y el contenido markdown con las instrucciones que Claude seguirá.
# .claude/skills/create-component/SKILL.md
---
name: create-component
description: Crea componentes React siguiendo Atomic Design. Usar cuando el usuario pida crear un nuevo componente UI.
disable-model-invocation: true
---
Crea un componente React siguiendo la arquitectura Atomic Design del proyecto.
1. Determina si es Atom, Molecule u Organism según la complejidad
2. Crea la carpeta en `src/components/[nivel]/[Nombre]/`
3. Archivos requeridos:
- `ComponentName.tsx` → Componente principal
- `index.ts` → Export barrel
4. Server Component por defecto. `'use client'` solo si necesitas estado o browser APIs
5. Importa dependencias externas siempre via adapters: `@/adapters`
No importes directamente desde `lucide-react`, `next/image` o `next/link`.
No uses `dangerouslySetInnerHTML`.
Ahora simplemente escribes /create-component en lugar de explicar todo esto cada vez.
El campo disable-model-invocation
Por defecto Claude puede invocar una skill automáticamente cuando el contexto lo sugiere. disable-model-invocation: true le dice que solo tú la disparas manualmente. Úsalo en skills con efectos secundarios como /deploy, /commit o /send-message: no quieres que Claude decida hacer un deploy porque el código "parece listo".
Skills con argumentos
Usa $ARGUMENTS para pasar parámetros al invocar la skill:
# .claude/skills/fix-issue/SKILL.md
---
name: fix-issue
description: Corrige un issue de GitHub por número
disable-model-invocation: true
---
Corrige el issue $ARGUMENTS siguiendo las convenciones del proyecto.
1. Lee la descripción del issue
2. Implementa el fix
3. Escribe los tests
4. Crea un commit
Invocas con /fix-issue 123 y Claude recibe "Corrige el issue 123 siguiendo las convenciones del proyecto."
4. MCP: Conecta Claude a tus sistemas reales
MCP (Model Context Protocol) es el protocolo que permite a Claude conectarse con sistemas externos: bases de datos, APIs, herramientas de terceros, tu propio código.
Sin MCP: Claude tiene que imaginar el contexto. Te pide que pegues el schema de tu base de datos, que copies la respuesta de una API, que le muestres los logs de error.
Con MCP: Claude lee directamente. Consulta tu DB, llama tu API, revisa tus logs.
Configurar MCP
El archivo de configuración vive en ~/.claude/claude_desktop_config.json (Claude Desktop) o en la configuración de Claude Code:
{
"mcpServers": {
"postgres": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-postgres"],
"env": {
"POSTGRES_CONNECTION_STRING": "postgresql://user:pass@localhost/mydb"
}
},
"filesystem": {
"command": "npx",
"args": [
"-y",
"@modelcontextprotocol/server-filesystem",
"/home/user/projects"
]
},
"github": {
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-github"],
"env": {
"GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
}
}
}
}
MCPs que uso en producción
Para desarrollo web:
@modelcontextprotocol/server-filesystem→ Lee y navega el proyecto@modelcontextprotocol/server-postgres→ Consulta la DB directamente@modelcontextprotocol/server-github→ Maneja issues, PRs, code review
Para productividad:
- Notion MCP → Claude puede leer y escribir en tu workspace de Notion
- Linear MCP → Gestiona tickets directamente desde Claude Code
Si ya usas LLMs en producción y quieres entender cómo integrarlos correctamente en flujos de trabajo empresariales, te recomiendo leer Integrando LLMs en flujos de trabajo empresariales.
Caso de uso real
Con el MCP de PostgreSQL configurado, en vez de decirle:
"Tengo una tabla
userscon estas columnas: id, email, created_at, role... quiero que me ayudes a..."
Simplemente dices:
"Revisa el schema de la tabla users y crea una query optimizada para..."
Claude consulta la DB, ve el schema real, y trabaja con información verídica en lugar de suposiciones.
5. Prompts atómicos: Una tarea, un prompt
Esta es la regla de oro que más impacto tiene en el costo por tarea.
El problema: Los prompts vagos o compuestos generan respuestas largas, re-intentos, y correcciones que duplican el consumo de tokens.
La solución: Un prompt = una tarea clara y acotada.
Anatomía de un prompt atómico
[Contexto necesario] + [Acción específica] + [Criterio de éxito]
Antes (prompt vago):
"Arregla los errores del componente de login y mejora el diseño."
Esto genera:
- Preguntas de aclaración
- Cambios de scope inesperados
- Posibles regresiones por cambios no solicitados
Después (prompt atómico):
"En
src/features/auth/components/LoginForm.tsxlínea 47, el handleronSubmitno limpia el estado de error cuando el submit es exitoso. AgregasetError(null)al inicio del bloquetry. No toques ningún otro archivo."
Esto genera:
- Cambio preciso
- Sin efectos secundarios
- Sin preguntas innecesarias
Checklist de un buen prompt atómico
Antes de enviar un prompt, verifica:
- ¿Hay un archivo y línea específicos? Si puedes señalar exactamente dónde, hazlo.
- ¿La acción es una sola cosa? "Arregla Y" es atómico. "Arregla Y y mejora Z" no lo es.
- ¿Dijiste qué no tocar? Agregar "no modifiques ningún otro archivo" evita cambios no solicitados.
- ¿Está claro cuándo termina? "El test X debe pasar" o "el componente debe renderizar sin errores" son criterios concretos.
El efecto compuesto
Ninguna de estas técnicas por sí sola te da un 60% de reducción. Es la combinación:
- CLAUDE.md elimina el costo de orientación en cada sesión
- Sub-agentes eliminan la contaminación de contexto en tareas complejas
- Skills eliminan la repetición de instrucciones complejas
- MCP elimina el costo de copiar y pegar contexto externo
- Prompts atómicos eliminan las iteraciones por ambigüedad
Con todo configurado, cada token que gastas es un token que produce valor.
Por dónde empezar
Si todo esto te parece mucho, hay un orden de implementación con el mejor ratio impacto/esfuerzo:
-
Semana 1: Crea tu
CLAUDE.md. Solo documentar tu stack y convenciones principales ya hace una diferencia notable. -
Semana 2: Identifica los 3 tipos de tarea que más repites y crea una Skill para cada una.
-
Semana 3: Configura 1 o 2 MCPs. El de filesystem ya viene incluido de hecho. Agrega el de tu base de datos si tienes acceso.
-
Semana 4: Experimenta con sub-agentes en la próxima tarea compleja que tengas.
El resultado no es solo pagar menos por el mismo output. Es entregar 10x más con el mismo presupuesto.
Recursos para seguir
¿Ya tienes tu CLAUDE.md configurado? ¿Usas sub-agentes o todavía le pides todo en un solo mensaje? Cuéntame en LinkedIn.
Si quieres seguir mejorando como ingeniero en la era de la IA, no te pierdas la lista de los 12 libros que separan al programador que la IA reemplaza del que la IA potencia.
