Agentes de código: de herramientas personales a infraestructura de equipo

Hablemos claro: si estás usando agentes de código en tu equipo de ingeniería, probablemente tengas un poco de caos organizado.

Cada desarrollador tiene su propia configuración de MCP, prompts personalizados, scripts de automatización que nadie más puede usar, y cero visibilidad sobre lo que pasó cuando el agente trabajó. Tu "infraestructura de equipo" es realmente un collection de atajos personales sostenidos por esperanza y conocimiento tácito.

Assembled se encontró exactamente con este problema. Sus agentes de código funcionaban genial para cada ingeniero—pero el workflow alrededor era un desastre. Un desastre total.

El problema con los agentes de código personales

Esto es lo que pasa normalmente: el Desarrollador A tiene una configuración de Claude Code conectada a su fork de GitHub y Linear. El Desarrollador B prefiere Codex con integración de Sentry y sus propias notificaciones de Slack. El Desarrollador C basically ha construido una máquina de Rube Goldberg de scripts que solo él entiende.

¿Qué pasa cuando alguien se va? ¿Cuando necesitas reproducir lo que el agente realmente hizo? ¿Cuando quieres auditar si el output del agente coincide con lo que realmente se commitió?

Estás básicamente varado.

El problema real no es si los agentes de código son útiles (lo son). Es que los hemos estado tratando como editores de texto personales en vez de infraestructura de equipo. Y eso crea tres problemas:

1. Silos de conocimiento — Solo una persona sabe cómo está configurado el agente
2. Brechas de reproducibilidad — No puedes fácilmente repetir o auditar las acciones del agente
3. Barreras de colaboración — Lo que funciona para un ingeniero no ayuda al equipo

143.dev: Agentes de código como infraestructura compartida

Assembled construyó un sistema interno para resolver esto, y acaban de hacerlo open source. El resultado es 143.dev—una plataforma que convierte agentes de código en infraestructura accesible para todo el equipo.

El enfoque central es inteligente: en vez de ejecutar agentes localmente en máquinas individuales, los ejecutan en ambientes estandarizados con herramientas consistentes y visibilidad.

Esto es lo que significa en la práctica:

Múltiples agentes, plataforma unificada. El sistema ejecuta Codex, Claude Code, OpenCode, y otros harnesses de agentes en sandboxes de gVisor. Esto significa que puedes mezclar y combinar según costo, capacidad y tipo de tarea. El equipo de Assembled, por ejemplo, usa GLM 5.2 para tareas de automatización rutinarias (más barato, rápido) y Codex o Claude Code para trabajo manual más complejo. Misma infraestructura, diferentes agentes para diferentes trabajos.

Integraciones con herramientas desde el inicio. El sistema se conecta a GitHub, Linear, Sentry, Slack, PagerDuty, y más. Generar previews es fácil. Tus agentes no están corriendo en aislamiento—están conectados a tu workflow existente.

Seguridad sin fricción. Los sandboxes de gVisor proporcionan aislamiento sin el dolor de cabeza de managear VMs completas. Los agentes pueden hacer lo suyo, pero están contenidos.

Licencia MIT y auto-hosteable. Esto no es un SaaS alojado al que tienes que confiar tu código. Puedes inspectarlo, correrlo en tu propia infraestructura, y adaptarlo a tus necesidades. Assembled se inspiró en los Minions de Stripe y el sistema Inspect de Ramp, pero querían algo que la comunidad más amplia pudiera realmente usar y modificar.

Por qué esto importa para startups y equipos en crecimiento

Aquí está lo bueno de los agentes de código: solo van a volverse más prevalentes. Y a medida que tu equipo escala, el enfoque de "scripts personales" se rompe.

Necesitas:

• Rastros de auditoría — ¿Qué cambió exactamente el agente?
• Reproducibilidad — ¿Puedes ejecutar la misma tarea de nuevo?
• Compartir conocimiento — ¿Puede cualquier persona del equipo aprovechar los workflows de agentes?
• Seguridad — ¿Los agentes están accediendo solo a lo que deberían?

143.dev está atacando estos problemas directamente. Y el hecho de que sea open source significa que no tienes que apostar tu infraestructura en una startup que quizás no exista en dos años.

La visión completa

Estamos entrando en una fase donde las herramientas de código AI no son novedades—son infraestructura. Y la infraestructura necesita ser manejada como infraestructura: con visibilidad, reproducibilidad y acceso para todo el equipo.

Los agentes de código personales son un comienzo. La infraestructura de agentes manejada por equipos es donde las cosas se ponen interesantes.

Si estás corriendo una startup o manejando un equipo de ingeniería, vale la pena revisar 143.dev. El código está en GitHub, y es licencia MIT. Sin vendor lock-in, sin costos ocultos—solo infraestructura abierta que puedes adaptar a cómo tu equipo realmente trabaja.

A veces las mejores herramientas internas son las que vale la pena compartir.