Agentes de código que escrevem, testam e revisam o código no seu repositório. Os seus engenheiros decidem, e uma pessoa aprova cada merge.
Montamos este sistema dentro do seu repositório, sob controle de versão, ao lado do seu código. Se pararmos, ele fica com você. Começamos este trabalho em 2025. Hoje ele roda nos nossos próprios produtos e em código de clientes em C, Rust e Go.
Fixamos o seu ambiente de build com Nix, e o agente roda dentro desse mesmo ambiente. Assim ele usa o compilador, o linter e os testes que os seus engenheiros usam. Um agente com outras ferramentas relata falhas que não existem.
Antes que os agentes escrevam código, escrevemos como o seu produto funciona: um glossário, registros de decisão e especificações de comportamento. Cada agente lê esses documentos, então sabe o que é correto para o seu produto, e não só para a linguagem.
Um trabalho grande começa como um mapa de perguntas abertas. Um agente faz ao seu engenheiro cada pergunta de design, uma por vez. Cada resposta vira um registro de decisão, e todo agente posterior o lê.
Entregamos um plugin versionado por meio de um marketplace. A sua equipe o instala com um comando. Um prompt em uma janela de chat ajuda uma pessoa uma vez. Um plugin ajuda cada engenheiro, todos os dias, e você pode revisá-lo em um pull request.
O seu engenheiro marca uma issue como pronta. Um agente a pega, trabalha em um contêiner isolado e abre um pull request. Se não conseguir terminar, ele devolve a issue com as suas notas. A fila roda enquanto os seus engenheiros fazem outro trabalho.
Cada execução recebe um token para um repositório, e o token expira em uma hora. O agente lê a issue como dados, e não como instruções. Limites de tempo, de custo e de execuções paralelas, e uma parada de emergência, interrompem uma execução que dá errado.
Quatro agentes de revisão leem cada pull request em três eixos: os seus padrões, a especificação e a correção. Depois, um agente separado verifica cada achado antes de publicá-lo. Agentes pequenos com uma tarefa cada encontram mais que um agente grande.
Build, testes, formatação e lint rodam em cada pull request, de um engenheiro ou de um agente. O agente não roda só em um laptop. Uma pessoa aprova o merge.
Publicamos o ai-plugin-vendor-tool. Ele copia uma skill de uma fonte pública, fixa a versão em um lockfile e dá o crédito ao autor em um arquivo NOTICE. Assim você sabe o que usa e de onde veio.
Um fabricante de equipamentos agrícolas rodava os seus serviços de controle em Python, em dispositivos ARM construídos com o Yocto Project. Um dos nossos engenheiros os levou para Go com agentes. O novo código roda ao lado da frota antiga durante a mudança.
O engenheiro respondeu às perguntas de design e decidiu o que os agentes construíam. Os agentes escreveram o código, os testes e as revisões.
O código de teste é maior que o código do produto, com 1.364 funções de teste. As 135 horas incluem a configuração dos agentes autônomos, que levou quatro.
O ShellHub é um produto público com licença Apache-2.0. Adicionamos a revisão por IA a ele em fevereiro de 2026, e ela ainda lê cada pull request. Toda revisão que ela escreveu é pública.
Também dizemos quando um agente ajudou no upstream. As nossas mudanças com merge no nixpkgs têm uma linha Assisted-by, e duas delas empacotam ferramentas do Yocto Project e do Zephyr Project.
Veja no nixpkgsEscreva um parágrafo sobre o produto, o silício e o prazo. Um engenheiro que faz esse trabalho vai ler e responder para você.
Ou escreva para contato@ossystems.com.br