Para mis compas ❤️✌️❤️

Hay mucho fervor en este momento en criticar el progreso en IA. Yo entiendo todas las razones que andan dando vueltas, algunas estoy de acuerdo, otras no. Me preocupa la concentración en pocas empresas, todas del norte mundial, de la oferta de IA de alta calidad. Me alegra que China esté compitiendo en forma "open source". Me preocupa que esto no sea así por siempre. Como me importa esto colaboro como puedo con la Fundación de Desarrollo Humano Integral, la mejor decisión que tomé en materia política.

Ahora, la única verdad es la realidad, y está claro que la realidad es que la programación y por ende, todo lo programable, cambió para siempre. Podemos discutir el cómo, los detalles, pero, amigos, no hay vuelta atrás, y el que no lo vea y adapte sus modelos mentales a esta nueva realidad, no la va a pasar bien.

Por eso, así como uno usa un celular para comunicarse aunque sabe que hay explotación infantil para la obtención de los materiales raros que lleva dentro, la IA plantea una telaraña de dilemas morales que vamos a tener que resolver como sociedad, pero esto no quita lo fascinante que es esta tecnología y todo el bien que puede hacer en buenas manos.

Recapitulando

Mi primer entorno de programación fue QuickBasic en DOS, en 1993. Pasé por todo lo que hubo en el medio desde ese año: copiar código de revistas, diskettes 5 1/4, diskettes 3 1/2, borland c++, BBS's, dial-up, linux, el open source, ICQ, copiar cds, visual basic, MSN, fibra optica, ruby, rails, fotolog, la explosión de frameworks, mobile y objective c, Rust, LSP, hacer juegos con C++, Unity, Unreal, la mentira crypto, GitHub Copilot, etc. Y ahora... esto.

La programación asistida por agentes de código es, sin duda alguna, el cambio más drástico y excitante que hubo desde que empecé a programar a los 8 años. El cambio fundamental es que, con suficiente conocimiento adquirido durante los años, puedo por fín enfocarme en pensar qué quiero, y usar cada vez menos recursos cognitivos en los detalles de código. Ya no se trata de "ayuda para autocompletar", es otra cosa. El modelo mental cambió completamente, y con él, instintos tan básicos como la evaluación de costo-beneficio de cualquier proyecto.

Yo soy una persona extremadamente inquieta, cada tres días tengo ideas de cosas que me gustaría que existan. Antes descartaba muchas ideas de herramientas pequeñas o proyectos que pensaba que sería "cool" tener pero que nunca podría justificar tener una vida saludable si quisiera implementar todas esas ideas. Por ejemplo, la semana pasada necesitaba una app de spaced repetitions que use LLMs para generar tarjetas y evaluar mis respuestas. Ese es un proyecto de fácil 3 o 4 meses. Lo hice en 4 horas mientras trabajaba en otra cosa. Este tipo de cosas antes no valían la pena, ahora puedo hacer MVPs y prototipos con documentos de especificación que encima genero usando los mismos agentes. Una locura.

El cambio mental

Durante años tuve dos capas de pensamiento que a veces se mezclaban: una orientada al usuario y otra orientada al código. En mi trabajo de consultoría, no era raro que tuviese que hablar con personas que me pedían cosas específicas, como por ejemplo un sistema de recomendación usando una base de datos de grafos. Era muy común que yo, mientras hablábamos, ya fuera pensando detalles de implementación. ¿Qué base de datos? ¿Neo4j? ¿Cómo modelar las relaciones? Esto me distraía de la discusión general.

Había un context switching constante entre "requerimientos" e "implementación" que me sacaba del momento presente. Parte de mi cerebro estaba resolviendo problemas técnicos mientras la otra parte intentaba entender qué quería realmente el cliente.

Ahora me fuerzo a no pensar en implementación durante esas conversaciones, porque de todas formas no lo voy a hacer yo. Y esto cambió todo. Mi capacidad de preguntar mejoró mucho porque mi cerebro está más presente en el modo correcto. Escucho mejor, pregunto mejor, entiendo mejor.

¿Pierdo algo al no pensar en implementación? No, porque ahora hay un momento específico para eso: cuando discuto arquitectura con el agente. Ese es el momento adecuado, no mientras estoy tratando de entender qué quiere el usuario.

Por qué la terminal

Empecé usando Cursor pero me frustraba lo lento que era. VS Code es una porquería de editor, heredada de Electron y toda esa arquitectura pesada innecesariamente. Mis editores predilectos son Sublime Text y vim, desde siempre porque son rapidísimos. Pero su integración con agentes es medio pésima.

Ahora estoy abandonando estos editores también en el día a día. El workflow cambió tanto que el editor/IDE pasó a un segundo plano.

Yo tengo mi idiosincrasia: iterar rápido, interfaces rápidas, keyboard first porque el mouse es para los débiles. La terminal es mi ambiente favorito desde siempre. Mis amigos se sorprendían cuando veían que chateaba con ellos por CenterICQ.

No es sorpresa entonces que haya terminado enamorado de Claude Code. La filosofía Unix de tools pequeñas integradas con la terminal para lograr comportamientos complejos se integra mucho mejor con Claude Code que con otros entornos. Creo que es natural el uso de agentes CLI por mi modelo mental previo.

Sobre esta serie

Esta es mi experiencia personal. Hay otras formas de trabajar con agentes: Conductor, Cursor, Windsurf, y muchas más. No estoy diciendo que esta sea la mejor forma, es simplemente la que funciona para mí.

Puse el año en el título a propósito. Esto está cambiando constantemente y es lógico que todo lo que escribo acá quede obsoleto en poco tiempo.

Esto es una foto de cómo estoy programando con Claude Code en Enero de 2026.

En los próximos posts voy a hablar sobre:

• Integración con GitHub
• Manejo de especificaciones
• Agentes, Skills y Comandos
• Code Review
• MCP & CLI
• Próximos pasos

Ahora, lo menos interesante pero necesario:

CLAUDE.md

El archivo CLAUDE.md es el primer paso para transformar un agente generalista en un agente particular para tu proyecto. Es el low hanging fruit de la configuración. Claude lo lee automáticamente al iniciar cada conversación.

Yo principalmente pongo algunos pilares importantes: forma de ejecutar tests, compilar, y el workflow típico del proyecto. Cada proyecto es distinto, así que este archivo siempre cambia un poco.

Tips útiles

Es muy importante mantener CLAUDE.md conciso. El contenido se agrega al principio de cada prompt y consume tokens, mejor no zarparse y usar bullets cortos, sin mucha cháchara. Escribís para Claude, no para onboardear un junior. El contexto específico se puede dar a mano.

Mientras trabajás y notas problemas recurrentes podés poner #, y le das una instrucción que Claude Code incorpora automáticamente al CLAUDE.md. Muy útil para documentar sobre la marcha mientras trabajás.

Algo que aprendí hace poco es que no tiene que estar todo en el CLAUDE.md en la raíz del repo. Podés usar CLAUDE.local.md para instrucciones locales (y agregarlo al .gitignore), podes tener CLAUDE.md en directorios hijos (se cargan cuando trabajás en esos archivos), y ~/.claude/CLAUDE.md en tu home para settings globales que apliquen a todos tus proyectos.

Lo obvio: usar /init para generar un CLAUDE.md inicial analizando tu proyecto, pero hay que refinarlo mucho.

El directorio .claude/rules/

Para proyectos más grandes, podés organizar instrucciones en múltiples archivos dentro de .claude/rules/. Se cargan todos automáticamente.

.claude/rules/
├── frontend/
│   ├── haml.md
│   └── css.md
├── backend/
│   ├── api.md
│   └── database.md
└── general.md

Incluso podés hacer reglas que apliquen solo a ciertos archivos usando frontmatter YAML con el campo paths:

paths:
  - "app/controllers/api/**/*.rb"

// Reglas que solo aplican a las APIs
...

Y si tenés reglas que querés compartir entre proyectos, podés usar symlinks:

ln -s ~/shared-claude-rules .claude/rules/shared

En todo momento podés usar /memory para ver qué archivos de memoria están cargados en la sesión actual.

Lo que viene

Con el CLAUDE.md tenés un agente que entiende tu proyecto. Pero el código no vive en el vacío: vive en un repositorio, con issues, branches, pull requests. El flujo real de trabajo necesita que el agente pueda interactuar con todo eso.

La filosofía Unix que mencioné antes — tools pequeñas que se integran — aplica perfecto acá. El CLI de GitHub (gh) le da a Claude Code la capacidad de crear PRs, leer issues, revisar el estado de los pipelines. Y combinado con git worktrees, cada tarea vive en su propio universo aislado.

En el próximo post voy a contar cómo armo ese flujo: desde que elijo un issue del sprint hasta que el PR está mergeado.