Empezamos la sesión con el equipo técnico de Condis con una pregunta: «¿cuántos habéis copiado algo de un chat de IA y lo habéis pegado en otro sitio esta semana?». Se levantaron todas las manos. Ese gesto, copiar y pegar, es justo el que veníamos a quitar de en medio.
Estaba planteada para 90 minutos y acabó durando tres horas. Y era justo lo que buscaba: en cuanto bajas a lo práctico (abrir un CLAUDE.md real y leerlo juntos, enseñar guías de verdad, hacer una prueba en directo), deja de ser una charla sobre IA y cada uno empieza a ver su propio trabajo dentro.
Chatear no es lo mismo que coworkear
En un chat, el contexto es lo que tú pegas en la ventana. Corriges a mano, cierras la pestaña y la corrección se pierde. La semana que viene la vuelves a hacer.
Trabajando con agentes, con Claude Code y Cowork, el contexto es el repositorio entero: los ficheros, las guías, el histórico y las convenciones. La memoria del proyecto se carga sola en cada sesión. Y el agente ejecuta, ve el error y lo arregla, en lugar de devolverte un texto que tienes que revisar a ojo.
El trabajo ya no es escribir el prompt perfecto. El trabajo es construir el entorno donde cualquier prompt mediocre da un resultado bueno.
De ahí salen tres piezas
Todo el marco se sostiene sobre tres piezas que conviene no mezclar.
- CLAUDE.md: la memoria del proyecto. Se lee sola en cada sesión, sin que nadie lo pida. Es un índice y un contrato, no una enciclopedia; cuando pasa de unas 500 líneas empieza a diluir la atención del agente y toca adelgazarlo.
- Las guías: el conocimiento de cada tarea. Escritas como especificación y no como prosa: obligatorio, prohibido, ruta exacta de entrada y de salida, checklist.
- Las herramientas: las manos del agente. Conectores, skills y scripts para ejecutar, no solo para redactar.
Una guía se parece más a un contrato de API que a un manual
La diferencia entre una guía que funciona y un apunte que no sirve está en cómo se escribe.
- Reglas binarias, no consejos. No «intenta que las frases sean cortas», sino «14 palabras por frase como máximo; si se pasa, rechaza la pieza».
- Tablas de sustitución, no explicaciones. Nuestra guía de corrección tiene cientos de filas del tipo «gap se escribe brecha, upside se escribe potencial alcista». El agente no interpreta, sustituye.
- Rutas exactas, no «por ahí». El fichero, la línea aproximada, el identificador. El agente no busca a ciegas: va directo al sitio.
Y una regla que repetimos mucho: la guía no es un documento de buenas intenciones. Es donde se queda escrito lo que ya has aprendido midiendo.
El bucle que hay que interiorizar
Todo se reduce a cuatro pasos, y el tercero es el que marca la diferencia:
- Haces la tarea con el agente, con el contexto que ya tiene.
- Sale regular y lo corriges a mano. Aquí es donde se queda casi todo el mundo.
- Escribes esa corrección en la guía. Este es el trabajo de verdad, el único que se acumula.
- La próxima vez sale bien a la primera. Y la siguiente. Y la siguiente.
La diferencia con el chat es que aquí el arreglo se queda. Cada corrección que haces a mano y no escribes en una guía, la vas a volver a hacer la semana que viene.
Un caso real: StocksReport
Para que no fuera una demo bonita, enseñamos nuestro propio proyecto: StocksReport, una plataforma que genera informes de inversión sobre más de 300 empresas cotizadas con una sola persona en el equipo. Marketing, ventas, operativa y desarrollo, todo con el mismo modelo; lo que cambia es el entorno que le dice cuál de esos papeles le toca en cada momento.
Ahí se entienden dos decisiones que en un chat ni te planteas. La primera, un modelo distinto para cada tarea: Opus para el análisis y las decisiones difíciles, Sonnet para ejecutar guías bien definidas y Haiku para clasificar y resumir en volumen. La segunda, subagentes para la lectura pesada, como explorar un repositorio entero o auditar treinta ficheros, que te devuelven solo la conclusión y dejan limpio el contexto principal. Al final la regla es simple: una guía floja obliga a Opus a razonar; una guía buena deja que Sonnet ejecute.
Los siete errores que ya hemos cometido
Ninguno lo aprendimos leyendo. Todos nos costaron trabajo que acabó en la basura:
- Empezar sin control de versiones. Git desde el primer día: un agente toca muchos ficheros a la vez, y sin un diff no sabes qué ha cambiado ni cómo volver atrás.
- Dejar claves y tokens dentro del proyecto. Van fuera, en variables de entorno: el agente lee todo lo que hay dentro de la carpeta.
- Validar a ojo con el «tiene buena pinta». Verificación con un script dentro del propio flujo; el agente no se corrige a sí mismo.
- Aceptar permisos a golpe de clic. Mejor una lista de permisos revisada y compartida con el equipo.
- Tener la raíz del proyecto llena de trastos. Cada fichero suelto le cuesta contexto y atención que necesitas para otra cosa.
- Repetir el mismo flujo a mano cada semana. Si lo has escrito tres veces en el chat, ya es un comando.
- No medir la calidad de lo que entrega. Apunta qué guía falla más y cuántas correcciones te cuesta cada entregable: eso es lo que te dice qué guía tocar.
Lo que hacemos y nos funciona
Los errores son la mitad de la foto. La otra mitad son las costumbres que, después de meses, se han quedado porque de verdad ahorran trabajo.
Si tuviera que resumirlas en una frase: todo lo que aprendes se queda escrito y todo lo que se entrega se verifica. Un CLAUDE.md corto que se recarga en cada sesión, guías con rutas de entrada y de salida explícitas, el código muerto marcado para que el agente no lo lea, la verificación con un script en vez de con el «me suena bien», y el modelo elegido según la tarea y no siempre el más caro. Nada de esto es teoría: es lo que queda cuando llevas un tiempo midiendo qué falla.
Qué sembramos con el equipo de Condis
El entorno era muy técnico y la conversación, exigente. En cuanto abrimos un CLAUDE.md real, lo leímos juntos, hicimos una prueba en directo y enseñamos guías de verdad, la sesión dejó de llevarla yo solo. Y ahí es cuando se abre el mundo: no solo el desarrollo, también la operativa, el dato y el día a día de cada departamento empiezan a verse dentro.
Sembramos la visión y el camino para llevarlo a su equipo de personas y a su stack de herramientas. Gracias a Josep Jarque y a Sergio Murillo por la confianza y el trato; con ellos uno se siente como en casa.
Primer paso, esta semana: coge la tarea que más veces has copiado y pegado desde un chat este mes. Escríbele una guía. Una sola. Y la próxima vez, no la copies: lánzala.
Si estáis en ese punto, con un equipo técnico y ganas de pasar de chatear a coworkear, hablamos.
