Cómo trabajar con IA y crecer de forma compuesta con el tiempo

• Una guía práctica que organiza de forma sistemática cinco principios para colaborar con IA: proveer contexto, configurar preferencias, automatizar la verificación, ampliar la delegación y cerrar el ciclo de retroalimentación
• Todos los entregables del trabajo (código, documentos, análisis, decisiones) se acumulan como contexto para la siguiente sesión, y las correcciones se reflejan en la configuración para reducir errores futuros con una dinámica de interés compuesto
• Presenta métodos concretos para gestionar el comportamiento del modelo y el flujo de trabajo como si fueran código usando CLAUDE.md, archivos de skills, guías, etc.
• Incluye estrategias de delegación para escalar la capacidad de trabajo con sesiones en paralelo, verificación cruzada entre modelos y control remoto
• Estos principios no solo aplican a la IA, sino que también son un marco general que puede aplicarse igual a la colaboración entre equipos humanos

---

Construir el contexto como infraestructura

• Si organizas todo el código en ~/src y el trabajo de conocimiento en ~/vault (projects/, notes/, kb/, etc.), al modelo le resulta más fácil buscar contexto con grep o glob
• Es posible conectar el contexto de la organización (Slack, Drive, Mail, etc.) al modelo mediante MCP (Model Context Protocol)
  • Mantén un INDEX.md por proyecto y registra en cada elemento la URL, la persona responsable y una descripción del contenido como comentarios
  • Si solo dejas una lista de URLs, el modelo tendrá que abrir todos los enlaces, así que agregar comentarios ayuda a evitar desperdiciar contexto
• Como el modelo empieza cada sesión desde una hoja en blanco, hay que escribir un CLAUDE.md por proyecto como si fuera un documento de onboarding para una nueva persona
  • Incluye glosarios de abreviaturas, nombres clave del proyecto y formas de distinguir personas con el mismo nombre
  • Define el orden de lectura como INDEX.md → TODOS.md → notas del tema específico
• Operar separando dos capas de memoria
  • ~/vault: guarda hechos (facts) como estado del proyecto, entregables y conocimiento del dominio
  • ~/.claude (CLAUDE.md, skills/, guides/): guarda configuración (configuration) como preferencias, flujos de trabajo y gustos personales

Codificar las preferencias como configuración

• Uso de ~/.claude/CLAUDE.md

  • Funciona como un contrato de comportamiento que Claude lee al inicio de cada sesión
  • Incluye reglas de comportamiento como hablar de forma directa, contradecir cuando no esté de acuerdo, ser honesto cuando haya incertidumbre, investigar la causa raíz y reintentar cuando falle, y no reformatear fuera del alcance del trabajo
  • También se puede configurar una sección de teaching para explicar en 1 o 2 oraciones términos clave cuando aparezca un sistema o dominio nuevo

• Separar el alcance por directorio

  • Global (~/.claude/CLAUDE.md): configuración que aplica en todos lados, como comportamiento, metas de largo plazo y preferencias de aprendizaje
  • Raíz del repo: reglas específicas del repositorio, como linting, naming y convenciones de PR
  • Directorio del proyecto: contexto específico del proyecto, como estructura de directorios y conocimiento del dominio
  • Si Claude Code se inicia en un subdirectorio, sube por el árbol cargando cada CLAUDE.md

• Estrategia para dividir CLAUDE.md cuando se vuelve largo

  • Un CLAUDE.md extenso se convierte en un impuesto de contexto porque se carga completo en cada sesión
  • En vez de @import, implementa lazy loading indicando en CLAUDE.md solo la ruta de los archivos guía con la nota de “leer cuando sea relevante”
  • Ejemplo: al escribir documentación, ~/.claude/guides/writing.md; para tareas de evaluación, ~/.claude/guides/evals.md

• Si una tarea se repite al menos una vez por semana, conviértela en un skill

  • Un skill es un archivo Markdown de flujo de trabajo con nombre, trigger y procedimiento
  • /polish: revisar el diff del artefacto; si hay métricas, correr evals; si hay render en navegador, verificar con Chrome; si no, ejecutar el código y revisar salida/errores → repetir y luego redactar un borrador de PR
  • /write: entrevista para el outline → crear un subagente de research → redactar borrador → recibir feedback de un crítico adversarial → iterar
  • /daily: leer calendario, Slack, PR y el log del día anterior para escribir las prioridades de hoy
  • SKILL.md debe enfocarse en el flujo de trabajo y el routing, mientras que el conocimiento como templates o scripts se separa en otros archivos para cargarse solo cuando haga falta

• Cómo hacer bootstrap de un skill

  • Realiza una tarea una vez de manera interactiva y luego pídele al modelo que la convierta en un skill
  • Ejecuta el skill en tareas iguales o similares, y corrige la salida dentro de la misma sesión
  • Pídele al modelo que actualice el skill con base en las correcciones y el feedback
  • También puedes darle ejemplos de la salida deseada para que extraiga patrones, como estructura de código o estructura y tono de documentos

• Mejorar skills a partir de transcripciones

  • Es normal que la primera versión quede sobreajustada (overfit) a la sesión original
  • No edites SKILL.md directamente; corrige dentro de la sesión para que se acumulen pares before-and-after en la transcripción
  • Cuando la salida sea satisfactoria, pídele al modelo que incorpore el feedback al skill → después de varias rondas, el skill converge

• No todo trabajo necesita este contexto

  • Para brainstorming, exploración y borradores, usa el modo simple (CLAUDE_CODE_SIMPLE=1 claude)
  • CLAUDE.md se carga, pero el agent harness (hooks, skills, tool loop) se desactiva, lo que permite pensar más cerca del modelo mismo

Verificación para la autonomía

• Mover la verificación hacia la izquierda (shift left)

  • Estructura la verificación como una escalera: abajo está lo barato y determinista; arriba, lo más costoso y lo que requiere criterio
  • En el nivel más bajo: un post-edit hook que ejecuta ruff format y ruff check --fix sobre los archivos modificados por el modelo → es determinista y no tiene costo de tokens
  • Niveles superiores: tests, evals, revisión por LLM, etc.

• Diseñar el sistema para que el modelo pueda verificar su propio trabajo

  • Si el sistema produce métricas, el modelo puede ejecutar evals directamente para optimizar
  • Si la salida es renderizada en navegador, inspeccionarla con Claude in Chrome
  • Al construir una imagen Docker, leer los errores, corregir el Dockerfile y volver a compilar
  • Al construir un dashboard, verificar en Chrome el render de tooltips, superposición de labels y si los números coinciden con la narrativa

• Para trabajos largos, hacer que un modelo vigile a otro modelo

  • En sesiones largas, los errores se acumulan y puede aparecer drift
  • Solución: ejecutar una segunda sesión con contexto fresco para comparar la especificación original con los turnos recientes de la primera sesión
  • Configuración de dos paneles de tmux: uno para el desarrollo principal y otro para el programador en pareja
  • Agrega instrucciones iniciales y prompts de seguimiento a un archivo compartido, y el programador en pareja revisa periódicamente
  • Execution drift: si el modelo está haciendo correctamente la tarea — ignorar errores, reportar métricas equivocadas, desviarse de la especificación, etc. → revisión táctica frecuente
  • Direction drift: si el modelo está haciendo la tarea correcta — malinterpretar la intención original y construir algo incorrecto → problema estratégico que se revisa de vez en cuando

Escalar mediante delegación

• Delegar unidades de trabajo cada vez más grandes

  • El enfoque de pair programming con tareas cortas y feedback rápido sirve para iteraciones veloces, análisis exploratorio y prototipado
  • Con modelos más potentes, conviene delegar explicando por adelantado la intención, las restricciones y los criterios de éxito, para que el modelo ejecute de punta a punta
  • No se puede delegar lo que no se puede verificar, así que primero hay que definir criterios de éxito y métricas
  • Ejemplo: “construir contenedores aislados por eval suite y hacer smoke tests → ejecutar todo → registrar métricas y transcripciones → validar exactitud con un subagente → repetir n veces para obtener intervalos de confianza → generar reporte y enviar resultados por Slack”

• Operar sesiones en paralelo e identificar cuellos de botella

  • Al delegar tareas grandes, es posible ejecutar 3 a 6 sesiones en paralelo
  • El cuello de botella se desplaza de “hacer el trabajo” a “escribir especificaciones claras y revisar salidas rápidamente”, dejando vacía la etapa intermedia
  • Si varias sesiones comparten el mismo repo, usa git worktrees para que cada sesión tenga su propio checkout independiente

• Asegurar observabilidad de las sesiones

  • stop hook: reproducir un sonido cuando termina una sesión (en macOS, reproducir Glass.aiff con afplay)
  • tmux window titles: identificar cada panel con un emoji de estado (⏳ trabajando, 🟢 completado) y una etiqueta corta generada por Haiku
  • Barra de estado de Claude Code: muestra el uso de contexto y el modo actual

• Poder revisar incluso estando lejos del teclado

  • Con la función /remote-control de Claude Code, puedes revisar el estado de ejecución desde la pestaña de código de la app de Claude mientras te desplazas y agregar contexto extra o nuevas instrucciones a sesiones bloqueadas
  • Esto evita que una sesión quede inactiva durante horas, aunque conviene usarlo solo en casos urgentes

Cerrar el ciclo de retroalimentación

• Trabajar en abierto para mantener un contexto rico

  • Si trabajas en documentos, repositorios y canales compartidos, todo el equipo, incluido el modelo, puede aprovechar ese contexto
  • Una prueba simple: “¿Una persona nueva del equipo puede reproducir lo trabajado la semana pasada usando solo el contexto compartido?”; si no, entonces hay contexto importante que solo existe en tu cabeza
  • Indica en CLAUDE.md que, al completar trabajo real, publique automáticamente en el canal de worklog una breve actualización y enlaces a los artefactos

• Minar transcripciones para actualizar la configuración

  • Si haces que el modelo lea transcripciones de sesiones pasadas, puede detectar brechas
  • Tras escanear alrededor de 2,500 turnos históricos de usuario, una proporción considerable incluía expresiones como “can you also…”, “did you check…”, “still wrong”
  • Eso sugiere que el modelo debió haber hecho esas tareas por iniciativa propia o que faltó una etapa de verificación, o bien falló
  • Haz las correcciones dentro de la sesión para usar la transcripción como dato de entrada para futuras actualizaciones de CLAUDE.md o de los skills

• Refactorizar y ordenar periódicamente

  • A medida que crece la configuración, puede solaparse o entrar en conflicto
  • Si el modelo ignora una regla, puede deberse a que contradice otra, así que conviene refactorizar para que cada regla o preferencia exista en un solo lugar (las instrucciones importantes pueden repetirse en el CLAUDE.md principal)
  • Consolidar los settings.json dispersos por directorio en ~/.claude para unificarlos y ordenarlos

Conclusión

• Aunque la configuración concreta puede cambiar a medida que evolucionen los modelos, siguen siendo válidos los principios de proveer buen contexto, codificar preferencias, verificar a bajo costo, delegar más y cerrar el ciclo de retroalimentación
• En el fondo, este proceso consiste en entrenar a un colaborador una retroalimentación a la vez, y aplica igual a la colaboración con equipos humanos
• Estos principios no se limitan a herramientas personales; también pueden aplicarse al diseño de agent harnesses, definición de normas de equipo y construcción de infraestructura organizacional

[xguru]

La trayectoria de esta persona es interesante: De graduado en psicología a estudiar con el curso de ciencia de datos de Coursera
Entró en las primeras etapas de Lazada, que era como el Amazon del Sudeste Asiático, y ascendió hasta VP.
Lazada fue adquirida por Alibaba.
Después se cambió a Amazon como científico principal de recomendación/LLM.
Actualmente es miembro del personal técnico de Anthropic