Un asistente que no olvida

Martes, 18:40

Revisemos por qué no llegan las confirmaciones de reserva.

Encontré la causa. El proveedor rechaza los correos que rebotan.

Anoté la decisión en la bitácora y en el ticket.

La sesión se cortó

Miércoles, 09:05

¿En qué quedamos?

Leí el último resumen. Decidimos validar el correo antes de enviar.

Queda pendiente el cambio en el formulario, que depende de producto.

Revisé el ticket y no hay cambios desde ayer.

¿Seguimos con el formulario?

Esta entrada no es sobre GATE. Trata de cómo trabajo con Claude cuando estoy solo frente a un problema, algo que en un rol como el mío pasa seguido.

Casi todo lo que se escribe sobre asistentes de IA trata de código: cuánto más rápido se programa o qué tan buenas son las pruebas que generan. Pero gran parte del tiempo que trabajo con Claude no estoy programando. Diagnostico incidentes, preparo documentos, reviso el trabajo del equipo y sigo temas que duran semanas. Para eso necesito que el asistente sepa en qué quedamos la última vez y qué falta.

Las prácticas que armé para eso tienen poco que ver con el ciclo de desarrollo. Las aprendí en años de trabajar con personas, y le sirven a cualquiera que use un asistente en serio.

Una bitácora por tema

Cada tema tiene un resumen corto: qué se pidió, qué se decidió, dónde quedó cada cosa y qué falta. Claude lo escribe solo, cada vez que algo avanza, sin esperar al final de la sesión. Lo hago así porque una sesión puede cortarse o resumirse para liberar espacio, y lo que no quedó escrito se pierde. Una vez se me cortó una sesión a mitad de un cambio, y como lo avanzado estaba escrito, retomarlo me tomó minutos.

El resumen no copia lo que ya está en otro lado: si algo está en el código o en un ticket, pone el enlace. Y para que no dependa de que el asistente se acuerde, un hook se lo recuerda con cada mensaje.

Retomar un tema

Cuando vuelvo a un tema, Claude lee primero su último resumen. Después revisa en la fuente qué pudo cambiar, porque un resumen de hace una semana puede estar desactualizado. Si abro una sesión sin pedir nada, me dice en pocas líneas qué quedó abierto y por dónde conviene partir.

Así no tengo que explicar el contexto cada mañana, y en semanas cargadas eso es un alivio.

Las decisiones, con su motivo

Una decisión anotada sin su razón sirve poco. Por eso cada resumen guarda qué se decidió y por qué, y también las opciones descartadas con su motivo. Semanas después, cuando alguien propone algo que ya se había descartado, la respuesta está escrita y no hay que discutirlo de nuevo.

Corregir una sola vez

Claude tiene una memoria que se mantiene entre sesiones, y la uso para lo que no quiero repetir: cómo me gusta que escriba, a quién le toca revisar cada tipo de cambio o cuál es la única fuente confiable para diagnosticar producción. Cada vez que lo corrijo en algo que va a volver a pasar, la corrección se guarda con su motivo y con cuándo aplica. Es lo mismo que se hace con alguien que recién llega al equipo: se le corrige una vez.

Proyectos separados

Trabajo en proyectos que no se deben mezclar: los de mi empresa, los personales y otros con sus propios accesos. Cada uno está en su carpeta, con su identidad y sus credenciales, y Claude no sale del proyecto de la sesión sin que yo lo autorice para esa tarea.

Con los permisos pasa algo parecido. Leer, analizar y preparar no necesita aprobación. Escribir en un sistema compartido sí, y lo más delicado, como producción o un merge, la pide siempre. Así el asistente avanza solo en lo seguro y se detiene cuando tiene que decidir una persona.

El trabajo, en un tablero

El trabajo diario queda en tickets y no solo en la conversación. Antes de empezar un tema, Claude busca su ticket y, si no existe, lo crea con el contexto, lo que hay que hacer y cómo se sabe que está listo. Cada avance, bloqueo o decisión se anota ahí en el momento, y el ticket cambia de estado.

Así se ve un trabajo que antes estaba solo en mi computador, y eso también ayuda a sentirse menos solo, porque otros pueden ver en qué estoy. Si otra persona tiene que saber o hacer algo, se lo pido con un comentario en su ticket, mencionándola, y no por chat, donde se pierde. La bitácora sigue, pero apunta al ticket.

Verificar antes de afirmar

La regla más importante es que nada se afirma sin revisarlo contra el código, los datos o el sistema real. Si Claude no pudo verificar algo, tiene que decirlo. Un asistente que suena seguro y se equivoca hace más daño que uno que avisa lo que no sabe.

Lo que cambia

Ninguna de estas prácticas es nueva. Son las mismas que espero de cualquier persona con la que trabajo. La diferencia es que a un asistente hay que dejárselas escritas, porque no las trae aprendidas. Con eso, Claude deja de ser solo quien escribe código y sigue el trabajo conmigo de un día para otro.

No reemplaza a un equipo, y no quiero que lo haga. Pero en los días largos ayuda saber que lo avanzado no se va a perder cuando cierre la ventana.