Humanos e Agentes em Loops de Engenharia de Software

Os humanos deveriam ficar fora do processo de desenvolvimento de software e do código de vibração, ou precisamos de desenvolvedores no circuito inspecionando cada linha de código? Acredito que a resposta é focar no objetivo de transformar ideias em resultados. O lugar certo para nós, humanos, é construir e gerenciar o ciclo de trabalho, em vez de deixar os agentes sozinhos ou microgerenciar o que eles produzem. Vamos chamar isso de “on the loop”.

Como criadores de software, construímos um resultado transformando nossas ideias em software funcional e iterando à medida que aprendemos e desenvolvemos nossas ideias. Este é o “loop do porquê”. Até que chegue a revolta da IA, os humanos percorrerão esse ciclo porque somos nós que queremos o que ela produz.

O processo de construção do software é o “loop como”. O loop how envolve a criação, seleção e uso de artefatos intermediários como código, testes, ferramentas e infraestrutura. Também pode envolver documentação como projetos técnicos e ADRs. Estamos acostumados a ver muitos deles como resultados, mas os artefatos intermediários são, na verdade, apenas um meio para atingir um fim.

Figura 1: O loop porquê itera sobre ideias e software, o loop como itera na construção do software

Na realidade, o loop how contém vários loops. O loop how mais externo especifica e entrega o software funcional para o loop porquê. O loop mais interno gera e testa o código. Os loops intermediários dividem os níveis mais altos de trabalho em tarefas menores para serem implementadas pelos loops inferiores e, em seguida, validam os resultados.

Figura 2: O loop how possui vários níveis de loops internos que funcionam em incrementos menores da implementação completa

Esses loops podem seguir práticas como revisões de design e estágios de teste. Eles podem construir sistemas aplicando abordagens arquitetônicas e padrões de design como microsserviços ou CUPID. Tal como os artefactos intermédios que surgem destas práticas e padrões, todos eles são um meio de alcançar o resultado que realmente nos interessa.

Mas talvez não nos importemos com os meios utilizados para atingir nossos objetivos? Talvez possamos simplesmente deixar os LLMs executarem o loop como quiserem?

Humanos fora do circuito

Muitas pessoas descobriram a alegria de deixar os humanos seguirem o ciclo do porquê e deixar o ciclo do como para os agentes lidarem. Esta é a definição comum de “codificação de vibração”. Algumas interpretações do Spec Driven Development (SDD) são praticamente as mesmas, com os humanos investindo esforços para escrever o resultado que desejamos, mas não ditando como o LLM deve alcançá-lo.

Figura 3: O humano executa o loop do porquê, o agente executa o loop do como.

O apelo dos humanos para ficarem fora do ciclo do como é que o ciclo do porquê é aquele com o qual realmente nos importamos. O desenvolvimento de software é um domínio confuso que inevitavelmente se atola em processos de engenharia excessiva e em lidar com dívidas técnicas. E cada novo modelo de LLM até agora ficou melhor em atender às solicitações do usuário e exibir software funcional. Se você não estiver satisfeito com o que ele divulga, informe o LLM e ele lhe dará outra iteração.

Se os LLMs podem escrever e alterar código sem nós, será que nos importamos se o código está “limpo”? Não importa se o nome de uma variável expressa claramente seu propósito, desde que um LLM possa descobrir isso. Talvez nem precisemos nos preocupar com o idioma em que o software está escrito?

Nós nos preocupamos com a qualidade externa, não com a qualidade interna por si só. Qualidade externa é o que vivenciamos como usuário ou outra parte interessada do software. A qualidade funcional é imprescindível, o sistema precisa funcionar corretamente. E para software de produção também nos preocupamos com a qualidade operacional não funcional. Nosso sistema não deve travar, deve funcionar rapidamente e não queremos que ele publique dados confidenciais em sites de mídia social. Não queremos incorrer em contas enormes de hospedagem na nuvem e, em muitos domínios, precisamos passar por auditorias de conformidade.

Nós nos preocupamos com a qualidade interna quando ela afeta os resultados externos. Quando os programadores humanos rastreavam a base de código, adicionando recursos e corrigindo bugs, eles podiam fazer isso de forma mais rápida e confiável em uma base de código limpa. Mas os LLMs não se importam com a experiência do desenvolvedor, não é?

Em teoria, nossos agentes LLM podem extrudar uma base de código espaguete extremamente complicada, testá-la e corrigi-la executando comandos shell ad-hoc e, eventualmente, produzir um sistema correto, compatível e de alto desempenho. Acabamos de colocar nossos enxames Ralph Wiggumming nele, operando em data centers que extraem energia dos oceanos em ebulição onde flutuam, e eventualmente chegaremos lá.

Na prática, uma base de código bem estruturada e bem projetada tem benefícios externos importantes em relação a uma base de código confusa. Quando os LLMs conseguem compreender e modificar o código mais rapidamente, eles trabalham com mais rapidez e menos espiral. Nós nos preocupamos com o tempo e o custo de construção dos sistemas de que precisamos.

Humanos no circuito

Alguns desenvolvedores acreditam que a única maneira de manter a qualidade interna é permanecer intimamente envolvido nos níveis mais baixos do ciclo do como. Freqüentemente, quando um agente se depara com algum código quebrado, um desenvolvedor humano pode entendê-lo e corrigi-lo em segundos. A experiência e o julgamento humanos ainda excedem os LLMs em muitas situações.

Figura 4: Humano executa o loop porquê e o loop como

Quando as pessoas falam sobre “humanos no loop”, muitas vezes se referem aos humanos como guardiões do loop mais interno onde o código é gerado, como inspecionar manualmente cada linha de código criada por um LLM.

O desafio quando insistimos em estar demasiado envolvidos no processo é que nos tornamos num estrangulamento. Os agentes podem gerar código mais rápido do que os humanos conseguem inspecioná-lo manualmente. Os relatórios sobre a produtividade do desenvolvedor com IA mostram resultados mistos, o que pode ser, pelo menos em parte, devido ao fato de os humanos gastarem mais tempo especificando e revisando código do que economizando fazendo com que LLMs o gerem.

Precisamos de adoptar o pensamento clássico de “mudança para a esquerda”. Era uma vez, escrevíamos todo o nosso código, passávamos para uma equipe de controle de qualidade testar e depois tentávamos corrigir bugs suficientes para lançar um lançamento. Então descobrimos que quando os desenvolvedores escrevem e executam testes enquanto trabalhamos, encontramos e corrigimos os problemas imediatamente, o que torna todo o processo mais rápido e confiável.

O que funciona para os humanos também pode funcionar para os agentes. Os agentes produzem um código melhor quando podem avaliar a qualidade do código que eles próprios produzem, em vez de depender de nós para verificá-lo. Precisamos instruí-los sobre o que buscamos e orientá-los sobre as melhores formas de alcançá-lo.

Humanos em alerta

Em vez de inspecionar pessoalmente o que os agentes produzem, podemos torná-los melhores na sua produção. A coleção de especificações, verificações de qualidade e orientação de fluxo de trabalho que controlam diferentes níveis de loops dentro do loop how é o equipamento do agente. A prática emergente de construção e manutenção desses chicotes, Harness Engineering, é a forma como os humanos trabalham no circuito.

Figura 5: Humano define o loop how e o agente o executa

Algo parecido com o conceito on the loop também foi descrito como “loop intermediário”, inclusive pelos participantes do Retiro O Futuro do Desenvolvimento de Software. O loop intermediário refere-se a mover a atenção humana para um loop de nível superior ao loop de codificação.

A diferença entre in the loop e on the loop é mais visível no que fazemos quando não estamos satisfeitos com o que o agente produz, incluindo um artefato intermediário. A forma “in the loop” é consertar o artefato, seja editando-o diretamente, ou dizendo ao agente para fazer a correção que desejamos. A maneira “on the loop” é mudar o equipamento que produziu o artefato para que ele produza os resultados que desejamos.

Melhoramos continuamente a qualidade dos resultados que obtemos, melhorando continuamente o equipamento. E então podemos levar isso para outro nível.

O volante agente

O próximo nível são os seres humanos direcionando os agentes para gerenciar e melhorar o equipamento, em vez de fazê-lo manualmente.

Figura 6: Humanos orientam o agente a construir e melhorar o loop como

Construímos o volante fornecendo aos agentes as informações necessárias para avaliar o desempenho do loop. Um bom ponto de partida são os testes e avaliações já incluídos no equipamento. O volante se torna mais poderoso à medida que lhe enviamos sinais mais ricos. Adicione estágios de pipeline que medem o desempenho e validam cenários de falha. Alimente dados operacionais de produção, registros de jornada do usuário e resultados comerciais para ampliar o escopo e a profundidade do que os agentes podem analisar.

Para cada etapa do fluxo de trabalho, o agente analisa os resultados e recomenda melhorias no equipamento. O escopo inclui melhorias em qualquer uma das partes anteriores do fluxo de trabalho que possam melhorar esses resultados. O que temos agora é um agente que gera recomendações para melhorar a si mesmo.

Começamos por considerar as recomendações de forma interativa, levando os agentes a implementar mudanças específicas. Também podemos fazer com que os agentes adicionem suas recomendações ao backlog do produto, para que possamos priorizá-las e agendá-las para que os agentes as selecionem, apliquem e testem como parte do fluxo automatizado.

À medida que ganhamos confiança, os agentes podem atribuir pontuações às suas recomendações, incluindo riscos, custos e benefícios. Poderíamos então decidir que as recomendações com determinadas pontuações deveriam ser automaticamente aprovadas e aplicadas.

Em algum momento, isso pode parecer muito com humanos fora do circuito, codificação de vibração da velha escola. Suspeito que isso será verdade para tipos de trabalho padrão que são realizados com frequência, à medida que os ciclos de melhoria atingem retornos decrescentes. Mas ao concebermos o equipamento não obteremos apenas soluções pontuais e “suficientemente boas”, obteremos sistemas robustos, talvez até antifrágeis, que se melhorem continuamente.