Agentes de código que escriben, prueban y revisan el código en su repositorio. Sus ingenieros deciden, y una persona aprueba cada merge.
Configuramos este sistema dentro de su repositorio, bajo control de versiones, junto a su código. Usted lo conserva si dejamos de trabajar juntos. Empezamos este trabajo en 2025. Hoy funciona en nuestros propios productos y en código de clientes en C, Rust y Go.
Fijamos su entorno de build con Nix, y el agente se ejecuta dentro de ese mismo entorno. Así usa el compilador, el linter y las pruebas que usan sus ingenieros. Un agente con otras herramientas informa de fallos que no existen.
Antes de que los agentes escriban código, escribimos cómo funciona su producto: un glosario, registros de decisiones y especificaciones de comportamiento. Cada agente los lee. Así sabe qué es correcto para su producto, y no solo para el lenguaje.
Un trabajo grande empieza como un mapa de preguntas abiertas. Un agente le hace a su ingeniero cada pregunta de diseño, una por una. Cada respuesta se convierte en un registro de decisión, y cada agente posterior lo lee.
Entregamos un plugin con versiones a través de un marketplace. Su equipo lo instala con un comando. Un prompt en una ventana de chat ayuda a una persona una vez. Un plugin ayuda a cada ingeniero, todos los días, y usted lo puede revisar en un pull request.
Su ingeniero marca un issue como listo. Un agente lo toma, trabaja en un contenedor sellado y abre un pull request. Si no puede terminar, devuelve el issue con sus notas. La cola avanza mientras sus ingenieros hacen otro trabajo.
Cada ejecución recibe un token para un repositorio, y el token vence en una hora. El agente lee el issue como datos, no como instrucciones. Hay límites de tiempo, de coste y de ejecuciones en paralelo. Esos límites y un interruptor de parada detienen una ejecución que sale mal.
Cuatro agentes de revisión leen cada pull request en tres ejes: sus estándares, la especificación y la corrección. Después un agente separado verifica cada hallazgo antes de publicarlo. Agentes pequeños con una tarea cada uno encuentran más que un agente grande.
Build, pruebas, formato y lint se ejecutan en cada pull request, sea de un ingeniero o de un agente. El agente no se ejecuta solo en un portátil. Una persona aprueba el merge.
Publicamos ai-plugin-vendor-tool. Copia una skill de una fuente pública, fija la versión en un lockfile y da crédito al autor en un archivo NOTICE. Así usted sabe qué usa y de dónde vino.
Un fabricante de equipos agrícolas ejecutaba sus servicios de control en Python, en equipos ARM construidos con Yocto Project. Uno de nuestros ingenieros los llevó a Go con agentes. El código nuevo funciona junto a la flota antigua durante el cambio.
El ingeniero respondió las preguntas de diseño y decidió qué construían los agentes. Los agentes escribieron el código, las pruebas y las revisiones.
El código de pruebas es más grande que el código del producto, con 1.364 funciones de prueba. Las 135 horas incluyen la configuración de los agentes sin supervisión, que llevó cuatro.
ShellHub es un producto público con licencia Apache-2.0. Le añadimos la revisión con IA en febrero de 2026, y aún lee cada pull request. Cada revisión que ha escrito es pública.
También decimos cuando un agente ayudó en upstream. Nuestros cambios con merge en nixpkgs tienen una línea Assisted-by, y dos de ellos empaquetan herramientas de Yocto Project y de Zephyr Project.
Verlos en nixpkgsEscriba un párrafo sobre el producto, el silicio y el plazo. Un ingeniero que hace este trabajo lo leerá y le responderá.
O escriba a contato@ossystems.com.br