Tu Autocompletado no es la Revolución. Es un Fichero de Markdown
Desde principios de 2025 existe una herramienta que te edita los ficheros, te ejecuta los tests, discute con tu linter y vuelve a lanzar la suite hasta que está en verde. Vive en un terminal pelado, no en tu IDE. Y lo incómodo — el desaire que casi nadie digiere — es que la parte que la hace funcionar no es el modelo.
*Es un fichero de Markdown. *
Llámalo CLAUDE.md.
La encuesta Developer Ecosystem de JetBrains Research de 2026 ya lo confirma: Claude Code ha superado a GitHub Copilot en el ranking de herramientas de código con IA preferidas por los desarrolladores. No porque el modelo sea mejor — el debate de pesos es un callejón sin salida. El giro es estructural: los desarrolladores ya no quieren que les autocompletes la siguiente línea. Quieren un operario que participe en el flujo completo del desarrollo.
Y eso cambia todo.
El Error de Base: Seguir Tratándolo como un Chatbot
Aquí está el malentendido que carcome a la mayoría de los equipos.
Los asistentes clásicos predicen el siguiente token. Escribes, te sugiere, aceptas, escribes más. Un loop de un solo paso con feedback humano constante.
Claude Code ejecuta otra cosa: *un ciclo plan–act–observe*. Edita un fichero. Ejecuta un comando. Lee el output. Decide el siguiente edit. Y repite.
La consecuencia práctica es brutal: *los equipos que lo tratan como un chatbot caro obtienen resultados de chatbot caro. Los que lo tratan como un junior con correa corta obtienen otra categoría de output. *
Y como escribí en un artículo anterior, el error fatal es pensar en archivos cuando deberías pensar en sistemas. Claude Code no te sugiere fragmentos; muta el estado de tu repo. Eso exige rediseñar cómo defines una tarea.
---
El Desaire: La CLI no es una Limitación, es la Arquitectura
La típica objeción: "¿Por qué un agente potente vive en un terminal en vez de en mi IDE?"
Porque el terminal es lo que lo hace componible.
El agente necesita una superficie de scripting, no un panel de plugins bonito. La prueba: la industria entera convergió en el CLI. Codex tiene uno, Gemini CLI tiene uno, Aider lleva años con el suyo. Cuando cada vendor de agentes termina en bash, no es coincidencia — es que ahí es donde ocurre el trabajo real.
Los IDEs son excelentes para leer código. Los agentes necesitan poder ser invocados, encadenados y auditados. Y el CLI te da eso nativo: output pipable, modo headless, disparo desde git hooks.
*La "falta de integración con el IDE" no es un hueco. Es una feature. *
---
Los 5 Cimientos del Agente
Aquí va el framework. Lo llamo El Framework de los 5 Cimientos del Agente. Son los pilares que separan el uso disciplinado del "funcionó una hora y luego se fue a la mierda".
Cimiento 1: Instala y Autentica — Cero Configuración de IDE
Primero, lo obvio. Sin IDE, sin extensión, sin siete pasos de setup.
```bash
npm install -g @anthropic-ai/claude-code
cd my-project
claude
```
Completas el login y ya opera en cualquier repositorio. Si gastas más de tres minutos en esto, algo estás haciendo mal.
Cimiento 2: Siembra la Memoria Antes de Cualquier Tarea Real
Este es el paso de mayor palanca de todo el framework. Y es el que más se salta.
Sin CLAUDE.md, el agente re-deriva las reglas de tu proyecto desde cero *en cada sesión*. Tokens desperdiciados, estilo inconsistente, decisiones arbitrarias.
La solución son dos comandos: `/init`, que escanea el codebase y genera el fichero, y después tu edición manual para que las reglas sean explícitas.
```bash
claude
> /init
```
Y luego editas a mano. Un CLAUDE.md mínimo que deja de hacer que adivine:
```markdown
Build
`npm test` ejecuta la suite (vitest)
`npm run lint` debe pasar antes de hacer commit
Conventions
TypeScript estricto; sin `any` salvo justificación
Lógica de dominio en src/domain, sin imports de framework ahí
Errores en español, strings de usuario centralizados en src/i18n
```
Diez minutos. Es el tutorial de onboarding que le darías a un junior. 👉 Y una inversión compuesta: el mismo fichero documenta el proyecto para los humanos que lleguen después.
Cimiento 3: Define "Hecho" como una Verificación Ejecutable
Aquí está la regla de oro que separa la disciplina del caos.
❌ "Arregla el bug del paywall y hazlo bien."
✅ "Escribe un test que reproduzca el fallo del paywall. Implementa. Lanza la suite. Itera hasta verde. Luego muéstrame el diff."
El "hecho" no es una vibración. Es un comando que pasa.
Además: mantén cada sesión acotada a una tarea con tamaño de ticket. Los agentes degradan la calidad según crece su contexto. Compáralo con un junior remoto en tu equipo: tareas pequeñas, bien especificadas y de responsabilidad única, rinden consistentemente mejor que un encargo gigante y abierto.
> Nota honesta: en codebases grandes, el contexto se llena y el comportamiento se degrada. No lo voy a vender de otra forma. Por eso existen los subagentes (aislan tareas en su propia ventana de contexto), `/compact` (resume la conversación para ahorrar tokens) y `/clear` (reset nativo). Eso es gestión de memoria manual — y es una habilidad de ingeniería real en 2026. Y los refactors cross-cutting todavía necesitan un humano conduciendo.
Cimiento 4: Codifica tus Prompts Recurrentes
¿Tienes una instrucción que repites una y otra vez? No la vuelvas a escribir.
Crea un comando custom. Los comandos viven en `.claude/commands/*.md` y pueden parametrizarse con `$ARGUMENTS`.
`.claude/commands/tests.md`:
```markdown
Escribe tests para $ARGUMENTS siguiendo las convenciones del proyecto en CLAUDE.md.
Ejecuta la suite, corrige las fallas, itera hasta verde y muéstrame el delta de cobertura.
```
Y se usa así:
```
> /tests auth.service
```
Ahora todo el equipo tiene el mismo estándar de calidad con un solo comando. Un botón que estandariza cómo escribe tests tu equipo.
Cimiento 5: Diseña el Radio de Explosión Explícitamente
Aquí está el giro que la mayoría de las reviews se pierden. (Mencioné este patrón del loop auditable en el artículo del Agent SDK — ahora lo llevamos al caso real.)
En vez de "confía en el modelo", Claude Code te deja programar la frontera de confianza. Los modos de permiso restringen lo que el agente puede tocar. Y los hooks — `PreToolUse`, `PostToolUse` — reciben JSON en stdin y pueden bloquear, permitir o modificar cualquier tool call con un script plano. El código de salida es el veredicto: 0 para permitir, 2 para denegar.
Un hook de cinco líneas que niega `git push --force`:
```bash
#!/bin/bash
input=$(cat)
if echo "$input" | grep -q '"command": ".*git push --force'; then
echo "Bloqueado: force push no permitido" >&2
exit 2
fi
exit 0
```
Esa garantía es más fuerte que cualquier prompt del modelo. Y es revisable: vive en tu control de versiones.
"¿Dejar que una IA ejecute shell en mi repo es una pesadilla de seguridad?" Es un riesgo real. Y es *diseñable*, que es más de lo que el autocompletado clásico jamás ofreció. Ejecuta el agente en un dev container, restringe las operaciones destructivas con hooks, revisa diffs pequeños en vez de mergear a ciegas.
El Contexto Externo: MCP sin Verborrea
La última pieza. Quieres que el agente consulte fuentes vivas sin que le cuentes todo.
El Model Context Protocol conecta servidores de contexto externos. Un ejemplo real con una base de datos:
```json
{ "mcpServers": { "postgres": { "command": "npx", "args": ["-y", "@modelcontextprotocol/server-postgres", "postgresql://localhost/app"] } } }
```
La disciplina: conecta solo el contexto que la tarea necesita. Todo lo que entra en la ventana de contexto cuesta tokens y ruido. Es tu cimiento 2 aplicado al exterior.
La Objeción Final: "Esto es un Wrapper de la API"
Concedo la parte técnica: el modelo es accesible vía API y podrías construir un loop tú mismo.
Pero lo *tedioso y propenso a errores* — la memoria de sesión (CLAUDE.md), los permisos, los hooks, los subagentes, los comandos custom, MCP — es la parte que no quieres hand-rollar. El modelo es intercambiable.
*La orquestación es el moat. *
El loop plan–act–observe es commodity. La inversión que rinde es el scaffolding alrededor: memoria persistente, un sistema de permisos auditable, eventos de ciclo de vida enganchables e inyección de contexto vía MCP. Eso es lo que la encuesta de JetBrains de 2026 ya detecta como tendencia: no gana el que tiene el modelo más grande, sino el que está más profundamente incrustado en tu flujo de trabajo real.
Resumen: Lo que te Llevas Hoy
→ Claude Code es un operario, no un autocompletado. Trátalo como a un junior: con tareas pequeñas y verificación ejecutable.
→ CLAUDE.md es tu palanca de mayor retorno. Diez minutos de `/init` + edición manual cambian la categoría de output.
→ Define "hecho" como un comando que pasa, no como una vibración.
→ Codifica comandos custom para estandarizar el bar de calidad de tu equipo en un solo `> /tests`.
→ Programa el radio de explosión: modos de permiso + hooks que niegan operaciones destructivas. La confianza no se pide, se diseña.
→ El modo headless `claude -p` encaja en scripts y CI. El agente no es solo interactivo: es automatizable.
El modelo ya es un commodity dentro de un loop. Lo que separa a los equipos que envían de los que discuten en chat es exactamente aquello de lo que se quejan de que "sobra": la capa de orquestación.
Para el vibecoder que envía productos reales, esa capa no es burocracia. Es el sistema de producción. Y empieza en un fichero de Markdown.
El futuro del desarrollo de software no lo decide quien tiene el mejor LLM. Lo decide quien construye la mejor vía de tren habilitada por cualquier LLM.
Lee el artículo completo en brianmenagomez.com
Más sobre mis servicios en brianmenagomez.com
Herramientas: Conversor IAE CNAE · Gestorias cerca de ti · Calculadora IRPF