O aproveitamento de ferramentas de inteligência artificial no desenvolvimento de software já não se limita a escrever um único prompt e esperar pela resposta. Os desenvolvedores falam cada vez mais sobre loops de execução repetitivos, agentes múltiplos e sistemas que envolvem o modelo e o orientam — conceitos que o GitHub Blog tenta organizar em um guia publicado por Cassidy Williams em 2 de setembro de 2026, com base em uma discussão no GitHub Podcast da qual participaram Marlene Mhangami e GPS.
Alguns desses termos descrevem novos padrões práticos; outros dão nomes modernos a ideias que já existiam, enquanto os significados de outros ainda estão se formando. Por isso, o guia não apresenta essas palavras como padrões definitivos, mas como uma forma de compreender o debate em curso entre equipes de desenvolvimento de software.
Do prompt único à engenharia de loops
Engenharia de loops significa projetar sistemas repetíveis em torno de agentes, em vez de pedir manualmente a um agente que execute uma tarefa isolada a cada vez. O exemplo apresentado é a criação de um processo agendado que busca novas issues do projeto, passa-as a um agente para que as resuma e proponha correções, verifica o resultado e encaminha os casos pendentes para outro fluxo.
Nesse sentido, o loop se parece com um processo cron configurado para inteligência artificial, mas precisa de mais elementos do que o agendamento. O guia aponta para habilidades específicas, monitoramento do comportamento, verificação das saídas, direcionamento das tarefas e pontos de parada nos quais seja possível intervir ou revisar.
Já os Ralph loops são uma aplicação mais simples e direta da ideia de loop: o agente recebe uma descrição detalhada de uma tarefa, geralmente com base em requisitos ou em uma especificação, e continua trabalhando até considerar a tarefa concluída. Esse método pode ajudar a dividir o trabalho em ciclos repetidos de planejamento, execução e inspeção, mas pode ser caro e ineficiente se cada ciclo consumir mais tokens, contexto e capacidade computacional.
A diferença entre squads, fleets e harnesses
squads e fleets descrevem como o trabalho é distribuído entre vários agentes. Uma equipe é um grupo de agentes com funções diferentes: um planeja, outro revisa o plano, um terceiro executa, um quarto testa e um quinto revisa o resultado. Já uma frota se refere a agentes que trabalham em paralelo em tarefas ao mesmo tempo. É possível executar uma equipe inteira dentro de uma frota paralela ou organizar suas funções sequencialmente.
A ideia prática aqui é a especialização e o paralelismo, em vez de atribuir tudo a um único agente. No entanto, a existência de vários agentes não garante automaticamente maior qualidade; o próprio artigo relaciona o benefício à capacidade da equipe de distribuir e controlar as funções e verificar as saídas.
O harness ou estrutura de execução se refere a tudo o que envolve o modelo e o torna utilizável dentro do fluxo de trabalho: ferramentas, permissões, memória, contexto e coordenação entre tarefas. O guia apresenta o GitHub Copilot como exemplo de um sistema que conecta modelos a bases de código, editores, pull requests e ao terminal. Já a engenharia de harness é o projeto e o aprimoramento desse sistema que envolve o modelo.
Aprimoramento por meio de feedback
O termo hill climbing é usado para descrever o aprimoramento gradual de agentes e harnesses com base em feedback. A equipe pode começar medindo o desempenho do agente por meio de testes de avaliação e, depois, alterar as ferramentas, o contexto ou o mecanismo de orientação quando os resultados não forem suficientemente precisos.
Na revisão de pull requests, por exemplo, a medição não se limita à capacidade do agente de produzir um comentário, mas inclui verificar se ele encontra erros relevantes e oferece recomendações úteis. A leitura prática aqui é que inserir um agente no fluxo de trabalho não é o ponto final; depois disso começa um ciclo contínuo de medição e ajustes.
Termos sobre funções e modelos
Engenheiro de campo descreve uma função que existia antes da onda da inteligência artificial, como a do engenheiro de software que lida diretamente com clientes, do engenheiro de vendas ou do engenheiro de soluções. No contexto da inteligência artificial, essa função ajuda as equipes a adaptar ferramentas, fluxos de trabalho e agentes e a integrá-los aos sistemas existentes.
Já os modelos fechados são disponibilizados por meio de uma interface de programação de aplicações ou de um produto hospedado, sem que os pesos, os dados de treinamento ou o método de treinamento sejam disponibilizados ao usuário. Os modelos de pesos abertos permitem baixar os pesos e executá-los localmente ou na infraestrutura do usuário, mas isso não significa necessariamente que os dados e o método de treinamento estejam disponíveis. Nos modelos de código aberto, o nível de disponibilidade vai além e inclui o modelo, o código, os dados e o processo de treinamento para inspeção, reutilização e modificação.
Por que este guia é importante?
A mudança real não está apenas no surgimento de um novo vocabulário, mas na transição do debate da pergunta “o que o modelo consegue gerar?” para “como construímos em torno dele um sistema repetível e mensurável?”. Isso é importante para equipes de desenvolvimento que pensam em executar agentes em seus processos, porque escolher o termo não substitui a definição de permissões, mecanismos de verificação, pontos de intervenção humana e custo da repetição.
Ainda assim, a fonte reconhece que os termos são instáveis: alguns podem se consolidar, enquanto outros podem desaparecer ou ser substituídos por expressões mais precisas. Por isso, as perguntas mais importantes continuam sendo práticas: o fluxo de trabalho pode ser repetido de forma confiável? Como os resultados são revisados? Quando o ser humano intervém? E qual é o nível aceitável de dependência do modelo? Essas perguntas, segundo o artigo, são mais importantes do que acompanhar cada palavra em alta.