Trabajar con IA en Distrope

En los últimos seis meses, las herramientas que usan los equipos de ingeniería para trabajar con modelos cambiaron más que en toda la década anterior. Aplicaciones de escritorio conectadas a CLIs, agentes autónomos en la nube, protocolos de contexto compartidos, y archivos .md funcionando como memoria operativa del equipo: todo aterrizó entre noviembre y abril. Trabajar con IA dejó de ser abrir una ventana de chat, pegar código, copiar respuesta y se volvió un ejercicio de orquestación — darle al agente el contexto correcto, las herramientas correctas, y dejarlo cerrar loops.

Los modelos no cambiaron tanto. Lo que cambió fue cómo los usamos.

Los agentes dejaron de ser chat

Hace un año, "trabajar con IA" era un flujo de copy-paste. Hoy los equipos punta — incluyendo a Distrope — trabajan con agentes que leen el código, editan archivos, corren comandos, proponen migraciones, abren pull requests, revisan sus propias ejecuciones, y reportan con evidencia. No es magia; son tres piezas que maduraron casi a la vez:

• CLIs con acceso a tools reales — Claude Code, Codex CLI, Gemini CLI, Aider, OpenCode. El agente vive en tu máquina o en una sandbox, corre git, lee logs, ejecuta tests, y responde con el output en mano.
• Agentes autónomos en la nube — los mismos workflows, pero disparables desde un webhook o una tarea programada. El agente puede despertarse en la madrugada, leer un reporte, decidir si hay algo que investigar, y abrir un ticket si lo encuentra.
• El sistema de archivos .md como memoria — convenciones como CLAUDE.md y AGENTS.md le dan al agente una identidad, un contrato de trabajo, una historia. Con un .md bien escrito, el agente se comporta como un miembro del equipo, no como un chatbot.

Esa última pieza fue la que cambió cómo trabajamos.

Seis meses montando workspaces

Desde noviembre del año pasado, en Distrope hemos construido lo que internamente llamamos workspaces: directorios con su propio .md raíz, documentación de decisiones, runbooks operativos y tokens scoped a esa marca o dominio. Cada workspace tiene uno o varios agentes asignados a tareas específicas.

Hoy corremos workspaces para:

• Operaciones de servidor — pasadas periódicas sobre logs, detección de anomalías, apertura de incidents, y propuesta del fix (no sólo alerta).
• Triage de comunicaciones — mensajes entrantes en canales asíncronos, filtrados, clasificados y resumidos antes de que un humano entre.
• Sincronización de plataformas — mover datos entre Monday, Supabase, Stripe, Google Docs y Make sin click-through humano; cuando algo se rompe, el agente deja contexto, no un stack trace pelón.
• Recordatorios internos — el inbox de "esto lleva pendiente desde el jueves". Trivial para un humano, pero son los pendientes triviales los que se pierden.
• Onboarding de proyecto — cuando arrancamos un cliente nuevo, el primer barrido de docs + reconocimiento del stack + primeros ADRs pasó de días a horas.
• Investigación técnica — spikes de decisión ("¿este stack sirve?") que antes eran un día de lectura hoy son una sesión de 40 minutos probando ejemplos en paralelo.

Ninguno reemplaza a una persona. Lo que hacen es absorber el trabajo que no tiene que hacer una persona — para que el tiempo humano rinda en diseño, conversaciones con el cliente y decisiones que sí requieren criterio.

Lo que cambió por dentro

Tres cosas que sentimos todos los días:

Velocidad. Implementaciones que antes tomaban tres días se cierran en media jornada. No porque el código salga solo — sale solo el código aburrido: configuración, boilerplate, tests de primer orden, migraciones tibias. Lo que queda para humanos es más denso y más divertido.

Alcance. Podemos aceptar proyectos con stacks legacy que antes no cabían en la semana. Un agente abre un repo con diez años de acumulación, mapea qué hace cada pieza, identifica el bug reportado, y deja un plan de cambios revisable en horas. Esa fase de reconocimiento era antes una cotización aparte.

Calidad. Cada cambio pasa por al menos una pasada de review automático — real, no cosmético. Un agente lee el diff completo, corre los tests, y escribe una opinión antes de que un humano la lea. El humano firma al final, pero con el ruido ya filtrado.

Lo que cambia para un cliente

Un ejemplo concreto, sin nombres: entramos a un cliente con un backend de Node corriendo desde hace ocho años. Tenían un bug intermitente que nadie había podido reproducir — de esos que "se arregla solo al rato". En la primera sesión con un agente reconstruimos el flujo sospechoso, encontramos un race condition en un callback, escribimos el test que lo reproducía, lo fixeamos y lo desplegamos. Cuatro horas, de frío. Ese mismo cliente tenía pendiente un módulo de reportes hace ocho meses; lo cerramos la semana siguiente.

Este tipo de velocidad no se paga más caro. Al contrario: nos permite ofrecer retainers con más alcance real al mismo precio, porque el tiempo humano rinde distinto. El cliente ve progreso más continuo y menos semanas de "en eso estamos".

El siguiente paso: agentes para tu marca

El patrón no se queda dentro de Distrope. Lo que empezamos a ofrecer — y va a crecer en los siguientes meses — es montar la misma infraestructura dentro del equipo del cliente:

• Setup inicial — elegir la herramienta correcta (desde opciones open-source como OpenCode hasta implementaciones de Claude Code), configurar accesos con scope discipline, y escribir el primer .md que define cómo va a operar ese agente.
• Capacitación — sesiones con el equipo humano para que usen al agente como herramienta, no juguete. Las reglas de oro: nunca darle permisos que no le darías a un junior, nunca confiar en su output sin verificar, nunca dejarlo correr en producción sin logs.
• Acompañamiento — los primeros meses el agente necesita tuning: qué docs leer, cuáles ignorar, cómo reportar, qué puede y qué no puede tocar. Nosotros ya tenemos ese proceso andado.
• Workspaces a la medida — igual que tenemos uno por rubro de Distrope, podemos construir uno por rubro del cliente: soporte, ventas, ops, ingeniería.

La IA dejó de ser un producto que se contrata una vez. Se volvió una capa de infraestructura, parecida a la nube: se elige con cuidado, se configura bien, se cuida mes a mes, y devuelve un retorno que escala con el uso.

Si eres parte de un equipo que todavía ve a la IA desde el lado del chat, desde acá lo que vemos es que hay mucho camino por ganar — y el camino ya está pavimentado. Sólo hay que empezar a caminarlo.