←
AITYBlog
Engenharia

Engenharia Agente-First: Automação Inteligente com Copilot CLI

Uma Nova Era na Engenharia de Software

Como engenheiro de software sênior, é um padrão familiar: impulsionado pela inspiração, frustração ou, às vezes, até mesmo preguiça, construímos sistemas para eliminar o trabalho repetitivo e focar em tarefas mais criativas. Eventualmente, acabamos mantendo esses sistemas, liberando seus benefícios automatizados para o restante da equipe. Recentemente, levei essa automação um passo além, eliminando o trabalho intelectual repetitivo e agora me vejo mantendo essa ferramenta para capacitar todos os meus colegas na AITY a fazer o mesmo.

Durante esse processo, aprendi muito sobre como criar e colaborar de forma eficaz usando o GitHub Copilot. A aplicação desses aprendizados desbloqueou um ciclo de desenvolvimento incrivelmente rápido para mim e permitiu que meus colegas de equipe construíssem soluções para atender às suas próprias necessidades. Para entender o escopo do que se pode fazer com o GitHub Copilot, é importante compreender o que motivou este projeto.

O Impulso para a Automação Inteligente

Grande parte do meu trabalho envolvia analisar o desempenho de agentes de codificação em relação a benchmarks de avaliação padronizados, como TerminalBench2 ou SWEBench-Pro. Isso frequentemente significava examinar inúmeras "trajetórias" – listas dos processos de pensamento e ações que os agentes tomam ao realizar tarefas.

Cada tarefa em um conjunto de dados de avaliação produz sua própria trajetória, geralmente arquivos .json com centenas de linhas de código. Multiplique isso por dezenas de tarefas em um conjunto de benchmark e novamente pelas muitas execuções de benchmark que precisam de análise em qualquer dia, e estamos falando de centenas de milhares de linhas de código para analisar.

Essa é uma tarefa impossível de fazer sozinho, então eu geralmente recorria à IA para ajudar. Ao analisar novas execuções de benchmark, percebi que repetia o mesmo ciclo: usava o GitHub Copilot para identificar padrões nas trajetórias e, em seguida, as investigava manualmente – reduzindo o número de linhas de código que precisava ler de centenas de milhares para algumas centenas. No entanto, o engenheiro em mim viu essa tarefa repetitiva e disse: "Quero automatizar isso". Agentes nos fornecem os meios para automatizar esse tipo de trabalho intelectual, e assim nasceu o projeto eval-agents.

A Abordagem: Colaboração e Agentes

Meu princípio orientador ao abordar este novo desafio foi que equipes de engenharia e ciência trabalham melhor juntas. Assim, concebi a estratégia de design e implementação deste projeto com dois objetivos em mente:

Os dois primeiros objetivos são intrínsecos à cultura do GitHub e são valores e habilidades que adquiri ao longo da minha carreira. No entanto, o terceiro objetivo moldou o projeto de forma mais significativa. Percebi que, ao configurar o GitHub Copilot para me ajudar a construir a ferramenta de forma eficaz, isso também tornava o projeto mais fácil de usar e colaborar. Essa experiência me ensinou algumas lições cruciais que impulsionaram os dois primeiros objetivos de maneiras inesperadas.

Agentes de Código como Contribuidores Primários

Minha configuração de codificação "agente-first" envolvia:

Também utilizei o Copilot SDK para acelerar a criação de agentes, que é alimentado pelo Copilot CLI. Isso me deu acesso a ferramentas existentes, servidores MCP, uma maneira de registrar novas ferramentas e habilidades, e uma série de outras funcionalidades de agentes prontas para uso que não precisei reinventar.

Com isso em ordem, pude otimizar rapidamente todo o processo de desenvolvimento seguindo alguns princípios centrais:

A descoberta e o seguimento dessas estratégias levaram a um fenômeno incrível: adicionar novos agentes e recursos era rápido e fácil. Tivemos cinco pessoas entrando no projeto pela primeira vez, e criamos um total de 11 novos agentes, quatro novas habilidades e o conceito de "fluxos de trabalho de agentes de avaliação" (pense em fluxos de raciocínio de cientistas) em menos de três dias. Isso resultou em uma mudança de +28.858/-2.884 linhas de código em 345 arquivos.

Estratégias de Prompting

Sabemos que agentes de codificação de IA são muito bons em resolver problemas bem delimitados, mas precisam de orientação para problemas mais complexos que você confiaria apenas aos seus engenheiros mais experientes.

Portanto, se você quer que seu agente atue como um engenheiro, trate-o como tal. Guie seu raciocínio, explique excessivamente suas suposições e aproveite sua velocidade de pesquisa para planejar antes de pular para as mudanças. Achei muito mais eficaz colocar reflexões em modo de "fluxo de consciência" sobre um problema que estava ponderando em um prompt e trabalhar com o Copilot no modo de planejamento do que dar-lhe uma declaração de problema ou solução concisa.

Aqui está um exemplo de um prompt que escrevi para adicionar testes de regressão mais robustos à ferramenta:

/plan Observei recentemente o Copilot atualizando alegremente os testes para se adequar aos seus novos paradigmas, mesmo que esses testes não devessem ser atualizados. Como posso criar um espaço de teste reservado que o Copilot não possa tocar ou deva reservar para proteger contra regressões?

Isso resultou em um diálogo que, em última análise, levou a uma série de guardrails semelhantes a testes de contrato que só podem ser atualizados por humanos. Eu tinha uma ideia do que queria e, através da conversa, o Copilot me ajudou a chegar à solução certa. As coisas que tornam os engenheiros humanos mais eficazes em seus trabalhos são as mesmas que tornam esses agentes eficazes nos seus.

Estratégias Arquitetônicas

Engenheiros, alegrem-se! Lembram-se de todas aquelas refatorações que queriam fazer para tornar a base de código mais legível, os testes que nunca tiveram tempo de escrever e a documentação que desejavam que existisse quando foram onboardados? Agora são as coisas mais importantes em que você pode trabalhar ao construir um repositório "agente-first".

Longe vão os dias em que despriorizar esse trabalho em detrimento de novos recursos era necessário, porque entregar recursos com o Copilot se torna trivial quando você tem um projeto bem mantido e "agente-first".

Passei a maior parte do meu tempo neste projeto refatorando nomes e estruturas de arquivos, documentando novos recursos ou padrões e adicionando casos de teste para problemas que descobri ao longo do caminho. Até mesmo dediquei alguns ciclos à limpeza de código morto que os agentes (como seus engenheiros juniores) podem ter deixado passar ao implementar todos esses novos recursos e mudanças.

Esse trabalho facilita para o Copilot navegar pela base de código e entender os padrões, assim como faria para qualquer outro engenheiro. Posso até perguntar: "Com o que sei agora, como projetaria isso de forma diferente?" E então posso justificar de fato voltar e reestruturar todo o projeto (com a ajuda do Copilot, é claro). É um sonho que se tornou realidade!

Estratégias de Iteração

À medida que os agentes e modelos melhoraram, passei de uma mentalidade de "confiar, mas verificar" para uma mais confiante do que duvidosa. Isso reflete como a indústria trata as equipes humanas: "culpe o processo, não as pessoas". É assim que as equipes mais eficazes operam, porque as pessoas cometem erros, então construímos sistemas em torno dessa realidade.

Essa ideia de cultura "blameless" proporciona segurança psicológica para as equipes iterarem e inovarem, sabendo que não serão culpadas se cometerem um erro. O princípio central é que implementamos processos e guardrails para proteger contra erros, e se um erro acontecer, aprendemos com ele e introduzimos novos processos e guardrails para que nossas equipes não cometam o mesmo erro novamente.

Aplicar essa mesma filosofia ao desenvolvimento orientado por agentes tem sido fundamental para desbloquear esse pipeline de iteração incrivelmente rápido. Isso significa que adicionamos processos e guardrails para ajudar a evitar que o agente cometa erros, mas quando ele comete um erro, adicionamos guardrails e processos adicionais – como testes mais robustos e prompts melhores – para que o agente não possa cometer o mesmo erro novamente. Ir um passo além significa que praticar bons princípios de CI/CD é uma necessidade.

Práticas como tipagem estrita garantem que o agente esteja em conformidade com as interfaces. Linters robustos impõem regras de implementação ao agente que o mantêm seguindo bons padrões e práticas. E testes de integração, ponta a ponta e de contrato – que podem ser caros para construir manualmente – tornam-se muito mais baratos de implementar com a assistência do agente, ao mesmo tempo em que fornecem confiança de que novas mudanças não quebram os recursos existentes.

Quando o Copilot tem essas ferramentas disponíveis em seu ciclo de desenvolvimento, ele pode verificar seu próprio trabalho. Você o está preparando para o sucesso, da mesma forma que prepararia um engenheiro júnior para o sucesso em seu projeto.

Colocando Tudo em Prática: Seu Loop de Desenvolvimento Agente-First

Aqui está o que tudo isso significa para seu ciclo de desenvolvimento quando você tem sua base de código configurada para desenvolvimento orientado por agentes:

Além disso, fora do seu ciclo de recursos, certifique-se de solicitar ao Copilot de forma precoce e frequente o seguinte:

Eu os executo automaticamente uma vez por semana, mas muitas vezes me vejo executando-os ao longo da semana, à medida que novos recursos e correções são incorporados, para manter meu ambiente de desenvolvimento orientado por agentes.

Conclusão: O Impacto Prático da Engenharia Agente-First

O que começou como uma frustração com uma tarefa de análise impossivelmente repetitiva transformou-se em algo muito mais interessante: uma nova forma de pensar sobre como construímos software, como colaboramos e como crescemos como engenheiros.

Construir agentes com uma mentalidade "agente-first" mudou fundamentalmente a forma como trabalho. Não se trata apenas das vitórias da automação – embora ver quatro cientistas lançarem 11 agentes, quatro habilidades e um conceito totalmente novo em menos de três dias seja nada menos que notável. Trata-se do que esse estilo de desenvolvimento nos força a priorizar: arquitetura limpa, documentação completa, testes significativos e design cuidadoso – as coisas que sempre soubemos que importavam, mas nunca tínhamos tempo para elas.

A analogia com um engenheiro júnior continua a se provar. Você o onboarda bem, fornece contexto claro, constrói guardrails para que seus erros não se tornem desastres e, em seguida, confia nele para crescer. Se algo der errado, você culpa o processo. Não o agente. Se há uma coisa que quero que você leve daqui, é que as habilidades que o tornam um grande engenheiro e um grande colega de equipe são as mesmas habilidades que o tornam ótimo em construir com o Copilot. A tecnologia é nova. Os princípios não são.

Portanto, vá limpar essa base de código, escreva aquela documentação que você tem adiado e comece a tratar seu Copilot como o mais novo membro de sua equipe. Você pode acabar se automatizando para o trabalho mais interessante de sua carreira.

Comentários

Interações
Seu Perfil

Aguardando Login...