Claude Code: Los cuatro caracteres especiales que cambian el modo de comunicación

La mayor parte del tiempo, comunicarse con Claude Code es simplemente escribir texto: describes una tarea, el agente la ejecuta, siguen conversando. Pero hay cuatro caracteres que funcionan de manera diferente. No son parte de un prompt ordinario: son prefijos que cambian el canal de comunicación, de la misma forma en que un @ en un mensaje de Slack no es texto sino una referencia, o en que // en Java no es código sino un comentario.

Estos cuatro caracteres son /, @, ! y #. La mayoría de los developers que empiezan a usar Claude Code conocen el / desde el principio porque es lo más visible. El @ lo descubren rápido. El ! y el # tienden a aparecer tarde en tutoriales o directamente en la documentación oficial, y son los que mayor impacto tienen en la fluidez del trabajo diario una vez que los incorporas.

En este artículo vemos los cuatro en detalle: qué hacen, cómo usarlos, cuándo no usarlos, y los errores más comunes.

Claude Code: Cómo escribir prompts que realmente funcionen

En los artículos anteriores de esta serie vimos qué es Claude Code, cómo instalarlo y cómo manejar sesiones y memoria. En algún punto de esas lecturas probablemente notaste que casi todo lo que escribes para comunicarte con el agente es texto libre en lenguaje natural. Sin sintaxis especial, sin métodos, sin tipos. Solo texto.

Eso suena simple, pero tiene una trampa: cuando el medio de comunicación es el lenguaje natural, la calidad de lo que escribes importa mucho más de lo que intuitivamente esperarías. El mismo agente, con el mismo modelo, puede darte respuestas brillantes o respuestas mediocres dependiendo de cómo le formules la misma tarea. Y la diferencia entre las dos formulaciones puede ser más pequeña de lo que piensas.

En este artículo vamos a entender por qué ocurre eso, y qué puedes hacer al respecto. Empezamos desde los fundamentos: qué es exactamente un prompt, cómo lo procesa el modelo, qué son los tokens y por qué importan. Después pasamos a los tips concretos. Y terminamos con la pregunta que todo el mundo tiene pero pocos admiten haber buscado: ¿debo decirle "por favor" y "gracias" al modelo?

Sin más, vamos al tema.

Claude Code: Domina el manejo de sesiones, memoria y permisos

En el artículo anterior vimos qué es Claude Code, cómo instalarlo y los conceptos básicos de contexto, memoria y permisos. Si ya lo tienes instalado y has hecho tus primeras pruebas, probablemente te has topado con la frustración número uno de todo developer que empieza a usarlo seriamente: cerrar la terminal y perder todo el contexto que habías acumulado en una sesión larga.

En este artículo vamos a resolver exactamente eso. Veremos cómo funciona el sistema de sesiones de Claude Code en profundidad: cómo guardarlas, cómo retomar una sesión anterior, cómo nombrarlas para encontrarlas después, cómo ramificarlas para experimentar sin miedo, y cómo el sistema de checkpoints te permite deshacer cambios con precisión quirúrgica. También veremos cómo inspeccionar el contexto activo y qué herramientas tienes para gestionarlo.

Sin más, vamos al tema.

Introducción a Claude Code: el agente de IA que vive en tu terminal

Parece increible, pero en muy poco tiempo el mundo del desarrollo de software, en particular las actividades que tienen que ver con la programción, han cambiado radicalmente. Platicaba con un colega la forma de trabajo tan diferente que tenemos con respecto a lo que hacíamos hace tan solo un año. En la plática nos dimos cuenta de que no todo el mundo entiende aún bien los conceptos base más imporatentes del uso de agentes para el desarrollo, así que creo que este es el mejor lugar para comenzar a explicarlo. Sé que existen decenas de agentes, tecnologías, modelos, servicios, etc. Esta serie de artículos estarán basados en Claude Code, que es lo que uso en mi día a día y con lo que estoy más familiarizado, pero muchos conceptos son similares o compartidos por otras tecnologías.

Con este artículo inicio una nueva serie dedicada a las herramientas de desarrollo asistido por inteligencia artificial que están cambiando la forma en que escribimos, revisamos y mantenemos código. No hablaremos de plugins de autocompletado ni de ventanas de chat: hablaremos de agentes que pueden leer directamente el código de tu proyecto, desde tu workspace o desde tu repositorio, entender tu arquitectura (usando reglas, limitacione y estándares difinidas por ti miso), ejecutar comandos y proponerte cambios completos antes de que tú hayas terminado tu café.

En esta primera entrega explico qué es Claude Code, por qué es diferente a lo que probablemente ya conoces, cómo instalarlo, y los conceptos fundamentales que necesitas entender para usarlo bien: el contexto, la memoria y los permisos. En artículos posteriores profundizaremos en flujos de trabajo reales, integración con CI/CD y cómo sacarle provecho en proyectos Java.

Sin más preámbulos, vamos al tema.

Patrón de diseño Builder

Builder es un patrón de diseño creacional con ámbitos de objeto. Nos ayuda a crear objetos complejos de una forma sencilla usando un procedimiento de "paso por paso". Esto facilita el trabajo enormemente cuando tenemos objetos con muchos atributos, pero no necesitamos establecer de inicio todos sus valores, o no siempre establecemos los mismos. De esta forma nos guía en la construcción de estos obejtos. También ayuda en el ensamblado de objetos complejos que están formados por otros objetos.

Debido a esto, este patrón es una de las formas más utilizadas para la creación de objetos; ya que es un elemento externo a los objetos que estamos creando, pero con la suficiente información para ayudarnos en el ensamblaje correcto de estos

En este tutorial te explico los detalles de este patrón, y te muestro tres estrategias diferentes de implementación.

Patrón de diseño Adapter

Adapter es un patrón de diseño estructural. Este es el único patrón que tiene los dos ámbitos, clases y objetos, ya que podemos implementarlos de dos formas diferentes. Este patrón se utiliza cuando tenemos dos elementos de una aplicación los cuales necesitamos que trabajen juntos, pero sus interfaces de comunicación no son compatibles. Para esos casos creamos una clase intermedia que facilita la comunicación entre ambas. Así, Adapter servirá como puente entre ambos elementos.

Algunas personas describen a este patrón con la frase: "Obtener la interface que quieres a partir de la interface que tienes" o "proporcionarle al cliente un objeto con la interface que necesita".

En este tutorial se mostraré la funcionalidad de este patrón, junto con dos estrategias diferentes de implementación, una para el ámbito de clases y otro para el ámbito de objetos.

Patrón de Diseño Strategy

Strategy es un patrón de diseño de comportamiento con el ámbito de objeto. Su finalidad es la de poder cambiar el algoritmo o comportamiento de un objeto en tiempo de ejecución. Esto ayuda cuando tenemos una aplicación en la que varían solo ciertas partes de la lógica. Con este patrón podemos aislar estos comportamiento o algoritmos en clases diferentes y elegir entre uno u otro en tiempo de ejecución.

En este tutorial te explicó más a fondo cómo funciona este patrón y te muestro una estrategia de implementación del mismo.

Patrón de Diseño Template Method

Template Method es un patrón de diseño de comportamiento del ámbito de clases. Con este patrón se define el esqueleto de un algoritmo en una clase abstracta, y se deja que sean las subclases quienes proporcionen los detalles concretos de algunos o todos los pasos de ese algoritmo. Lo interesante de este patrón es que también da la opción a las subclases de redefinir los pasos de acuerdo con sus necesidades, sin cambiar la estructura del algoritmo.

En este tutorial te explico los detalles de Template Method, y te muestro una estrategia de implementación.

Diferencias: Simple Factory vs. Factory Method vs. Abstrac Factory

En los tutoriales anteriores vimos tres patrones de diseño que son muy parecidos en nombre y concepto: Simple Factory (conocida también como Factory, a secas), Factory Method y Abstract Factory. La finalidad de los tres patrones es la misma: encapsular la instanciación de objetos. Sin embargo, cada uno de los patrones lo hace de una forma diferente dependiendo del problema que estemos tratando de resolver.

Al tener nombres tan parecidos, estos tres patrones generan mucha confusión entre los desarrolladores.

En este tutorial te explico las diferencias entre estos tres patrones y te doy algunas recomendaciones de cuándo debes usar uno u otro.

Patrón de Diseño Abstract Factory

Abstract Factory es un patrón de diseño creacional del ámbito de objetos. Este patrón ayuda a crear grupos o familias de objetos que, aunque en esencia son diferentes, tienen una relación de herencia o dependencia entre ellos a niveles de padres e hijos, pero también a nivel de hermanos. De esta forma ayudan a que la construcción de esa familia de objetos mantenga una lógica y coherencia, manteniendo al mismo tiempo un alto nivel de abstracción y bajo acoplamiento a través del polimorfismo.

En algunas ocasiones este patrón es descrito como una fábrica de fábricas lo cual, en parte, tiene razón, pero esta descripción se queda corta con respecto al potencial que ofrece.

En este tutorial te explicaré más en detalle en qué consiste este patrón de diseño, así como una estrategia de implementación.