O Foreman transforma agentes de modelos de linguagem de grande escala (LLM) em recursos nativos do Kubernetes, permitindo que equipes executem código gerado por IA em produção, mantendo custos e segurança sob controle rigoroso.

Como a ideia se encaixa no fluxo de trabalho de desenvolvimento atual

Empresas têm experimentado LLMs que podem escrever código, mas a maioria das implementações trata o modelo como uma "caixa preta" confiável. Um único sinal de "concluído" do modelo pode enviar alterações não testadas diretamente para um repositório, levantando preocupações de segurança e confiabilidade. Ao mesmo tempo, executar serviços de IA na nuvem pode se tornar caro rapidamente, especialmente quando o mesmo modelo é chamado repetidamente de pipelines de CI.

A resposta do Foreman é incorporar todo o ciclo de codificação dentro de um cluster Kubernetes. O Foreman é executado como recursos do Kubernetes.

Os quatro objetos principais que fazem isso acontecer

  • Agent – Define um trabalhador. Ele nomeia o LLM a ser chamado, lista as ferramentas que o modelo pode invocar (ex: file-write ou git-push) e define um orçamento que limita as chamadas ao modelo. As funções (roles) são atribuídas aqui; um agente codificador (coder agent) escreve o código, um agente verificador (verifier agent) o checa.
  • Workload – A unidade de trabalho escrita pelo usuário. Ela contém a intenção de alto nível (ex: “adicionar testes unitários para o módulo X”), uma referência ao repositório de destino e uma lista de agentes que devem lidar com o trabalho.
  • AgenticTask – A tarefa concreta que uma Workload gera. À medida que o trabalho progride, cada AgenticTask registra atualizações de status, permitindo que os operadores monitorem o pipeline em tempo real.
  • FleetNode – Um nó do Kubernetes que realmente executa as tarefas. O agendador (scheduler) integrado associa AgenticTasks pendentes a FleetNodes que possuem a função e os recursos necessários.

A verificação substitui a confiança cega

O Foreman não assume que a saída do modelo esteja correta. Quando um agente codificador termina seu trabalho, ele envia uma solicitação em vez de um resultado final. Um verificador — geralmente um script determinístico, não outro LLM — executa o código através de linters, testes unitários ou builds completos. Somente se essas verificações passarem é que o Foreman grava a nova branch de volta no repositório.

Se o verificador falhar, a tarefa é marcada como rejeitada e as alterações nunca são aplicadas. Essa separação permite que o modelo gere código de forma criativa, enquanto a rede de segurança permanece totalmente sob controle humano.

Instalando a stack em um cluster

  1. Faça o deploy do chart principal do LLMKube com Helm.
  2. Faça o deploy do chart do Foreman, também via Helm.
  3. Altere o modo do agente para “native” para que o loop real de requisição-resposta esteja ativo.
  4. Atribua funções (roles) (coder, verifier) aos FleetNodes que hospedarão o trabalho.

Dois conjuntos de credenciais são necessários: credenciais do git para ler issues e fazer push de branches, e credenciais do modelo para chamar uma API hospedada ou um serviço de inferência auto-hospedado.

Ajustes de custo e segurança que você realmente pode controlar

O Foreman permite que os operadores limitem a autoridade de um modelo removendo ferramentas da definição do agente. Remover “bash” ou “write_file” impede que o modelo execute comandos de shell arbitrários ou escreva fora do espaço de trabalho designado.

Um limite de turnos (turn limit) restringe o número de invocações do modelo por tarefa, controlando diretamente os gastos. Ajustar a janela de contexto — quanto do prompt o modelo vê — reduz ainda mais o uso de tokens. Quando o modelo é executado localmente em hardware on-prem, nenhum dado sai da organização, satisfazendo políticas rigorosas de privacidade de dados.

Onde a plataforma brilha e onde ainda encontra dificuldades

O Foreman se destaca em tarefas mecânicas e bem delimitadas:

  • Corrigir um bug documentado.
  • Adicionar casos de teste ausentes.
  • Atualizar a documentação para clareza ou estilo.

Essas tarefas possuem critérios de sucesso claros que um verificador pode checar automaticamente. O sistema ainda tem dificuldades com redesenhos arquiteturais de alto nível ou trabalhos de funcionalidades ambíguas, onde a "correção" depende do julgamento humano.

Conclusão

Ao tratar codificadores baseados em LLM como recursos de primeira classe do Kubernetes e impor uma etapa de verificação determinística, o Foreman oferece um caminho pragmático para a geração de código por IA em produção, mantendo os gastos visíveis e a segurança sob controle. Não é uma solução mágica para todo o trabalho de desenvolvimento, mas para tarefas repetíveis e testáveis, ele fornece um fluxo de trabalho auditável que se encaixa naturalmente nas operações cloud-native existentes.