Herramientas

Lo que cambió en Claude Code, y lo que no

Cuando salió, Claude Code era un CLI. Un terminal con un agente atrás, capaz de leer archivos, editar código, ejecutar comandos. Para muchos, una curiosidad técnica más en un campo lleno de novedades.

A varios meses de uso intensivo, lo que empezó como herramienta de programación se convirtió en otra cosa: la pieza central de mi forma de trabajar con cualquier proyecto que toque archivos. Código, sí, pero también contenido, configuración, documentación, automatizaciones.

Esto es lo que es hoy y lo que cambió desde su lanzamiento.

Qué es.

Claude Code es un agente que opera en tu sistema de archivos. Le das un objetivo en lenguaje natural — “armame este proyecto”, “buscá el bug en este archivo”, “reescribí estos tres scripts” — y trabaja. Lee archivos, los modifica, ejecuta comandos, encadena pasos sin pedirte cada uno.

A diferencia de un chat tradicional, no le pegás texto. Trabaja con tu repo, tu carpeta, tu máquina. Lo que devuelve no es una respuesta para que copies y pegues — son archivos cambiados, comandos corridos, resultados verificables.

Detrás corre un modelo de Anthropic — hoy Opus 4.7 por default, con la opción de usar Haiku para tareas más livianas. La elección del modelo cambia el tradeoff entre velocidad, costo y profundidad.

Cómo se usa.

Tres caminos principales:

  • CLI en la terminal. El formato original. Abrís una sesión en el directorio del proyecto y conversás con el agente. Para tareas rápidas o cuando trabajás directamente en servidor.
  • Extensión en VS Code y JetBrains. El editor integra Claude Code como panel lateral. Ves el código y la conversación a la vez. Para mí, el formato que más uso.
  • Agente en background. Le pedís una tarea larga y la corre solo, mientras hacés otra cosa. Te avisa cuando termina.

Las tres comparten contexto si las configurás bien. Empezás algo en el editor, lo seguís en la terminal, lo dejás corriendo en background. Es el mismo agente, no tres herramientas distintas.

Lo que cambió desde el lanzamiento.

En los meses que llevo usándolo, hubo varias incorporaciones que valieron la pena.

  • Skills y plugins. El cambio más grande para mi flujo. Empacar capacidades en módulos reutilizables — generación de documentos, revisión de código, automatización de browser — sacó al agente del “todo desde cero” a “lo que necesita ya viene puesto”. Lo conté en otro post.

  • MCP (Model Context Protocol). Conectores estándar para hablar con servicios externos. Gmail, Calendar, Drive, n8n, browsers — cada conector se instala una vez y queda disponible. Antes, integrar al agente con una herramienta era un proyecto; ahora es un comando.

  • Sub-agentes. Posibilidad de delegar tareas a agentes especializados con contexto propio. Un explorador del repo, un revisor de cambios, un planner de features. Cada uno trabaja en paralelo y reporta al agente principal.

  • Hooks. Ganchos que se disparan en eventos del agente — antes de un commit, después de un edit, al inicio de una sesión. Permite automatizar verificaciones que no quiero estar pidiendo cada vez.

  • Context window de 1M tokens (Opus 4.7). Repos enteros entran en una sola sesión. Documentación larga, transcripciones, archivos pesados — todo procesable sin trocear.

  • Background agents y tareas programadas. El agente puede dejar tareas corriendo y avisarme cuando terminan, o ejecutarse en horarios fijos. La diferencia entre “asistente que respondo cuando le pregunto” y “colaborador que también trabaja sin mí presente”.

  • Modo planificación. Antes de ejecutar cambios grandes, el agente arma un plan, lo presenta y espera aprobación. Reduce sorpresas en proyectos serios.

Cada release suma algo. Lo que listo arriba es lo que más cambió mi forma de trabajar; hay otras incorporaciones más chicas que también pesan en el día a día.

Lo que sigue siendo igual.

Dos cosas no cambiaron.

Una: Claude Code es bueno con criterio del usuario, no sin él. Cuando le pido cosas vagas, me devuelve cosas vagas. Cuando le doy contexto preciso, reglas claras y un objetivo concreto, entrega. Eso es responsabilidad mía, no del modelo. Y es la pieza que más subestimaron muchos colegas que probaron la herramienta dos veces y la abandonaron.

Dos: human-on-the-loop. La aprobación final siempre es mía. El agente propone, ejecuta, encadena pasos, plantea opciones — pero la decisión sobre qué se commitea, qué se publica, qué sale a producción, queda en mi cabeza y mis manos. Cuanto más capaz se vuelve la herramienta, más importante es no delegar esa última instancia.

Para quién aplica.

Hoy, mi recomendación honesta: si trabajás con archivos — código, contenido, configuración, scripts, documentos — vale la pena dedicarle dos semanas a probarlo en serio. No el “saludo y adiós” de la primera tarde. Dos semanas de uso real, en proyectos reales, con paciencia para entender cómo opera.

Después, o lo dejás (porque no te encaja) o ya no lo soltás. En mi caso, fue lo segundo.

Comentarios