Contexto técnico
Me encantan este tipo de ideas, no por el factor de asombro, sino porque resuelven de inmediato un problema real. El concepto aquí es sencillo: añado un done skill que, al finalizar una tarea, escribe automáticamente un breve historial de decisiones en devlog.md. Esto ya no es un juguete, sino una base sólida para la AI automation en el desarrollo.
La estructura consta de dos partes. Primero, el skill en sí: recopila lo que decidí en esta sesión, por qué elegí este camino específico, qué alternativas descarté y qué quedó pendiente. Segundo, el archivo AGENTS.md o agent.md en la raíz del repositorio, donde le indico explícitamente al agente: una vez terminada la tarea, invoca el done skill.
Me gusta que casi no hay magia de por medio. Puedo almacenar el skill como un archivo markdown independiente, definir una plantilla de registro fija y exigir que se cree devlog.md si aún no existe. Cuanta menos libertad haya en el formato, menos ruido habrá en el registro.
Yo estructuraría la entrada de la siguiente manera: tarea, decisión tomada, motivo, opciones descartadas, archivos modificados, seguimiento (follow-up). Esto es suficiente para que otro agente u otro desarrollador no tenga que adivinar al día siguiente por qué el código tomó ese rumbo. Los mensajes de commit habituales no salvan en estos casos.
Si busca mayor fiabilidad, sugeriría delegar la escritura a un script como log_done.sh. De este modo, el agente no escribe markdown manualmente, sino que invoca un mecanismo predecible. Para la AI integration en el flujo de trabajo de un equipo, esto es mucho más robusto que confiar en la disciplina del modelo.
Impacto en los negocios y la automatización
Veo el efecto práctico de inmediato en tres áreas. En primer lugar, entregas (handoffs) más económicas: un nuevo agente o desarrollador se integra mucho más rápido. En segundo lugar, menos duplicación de decisiones y refactorizaciones innecesarias. En tercer lugar, es mucho más sencillo rastrear el origen de una bifurcación arquitectónica polémica.
Los equipos con varios agentes, cambios de contexto frecuentes y ramas de tareas largas son los que ganan. Pierden los que siguen confiando en que "todo se ve en el código". No, no se ve.
Yo pruebo estas cosas directamente en flujos de tareas reales, porque sobre el papel los patrones son bonitos, pero en un repositorio real surgen rápidamente duplicados, entradas vacías y ruido. Este es el tipo de flujos que optimizamos para nuestros clientes en Nahornyi AI Lab, donde no solo se trata de conectar un modelo, sino de construir una AI architecture funcional para el equipo.
Si su agente ya escribe código, pero la memoria de las decisiones se desvanece en el historial del chat cada vez, analicemos su proceso. En Nahornyi AI Lab, puedo ayudarle a configurar esta AI automation para que el contexto no se pierda y su equipo avance realmente más rápido, sin tareas manuales innecesarias.