Após 6 meses trabalhando em uma ferramenta CodeGen Dev (GPT Pilot), foi isso que aprendi

Nos últimos 6 meses, tenho trabalhado no GPT Pilot ( https://github.com/Pythagora-io/gpt-pilot ) para entender o quanto podemos realmente automatizar a codificação com IA, então gostaria de compartilhar nossos aprendizados até agora e até onde é capaz de ir.

Quando comecei a construir o GPT Pilot, escrevi esta postagem no blog sobre como ele foi concebido. Agora, quero compartilhar meu pensamento revisado e analisar o que funcionou e o que não funcionou.

Por fim, você verá exemplos de aplicativos que foram criados com GPT Pilot e como você pode criar um aplicativo com um programador de pares de IA real .

Qual é a ideia por trás do GPT Pilot?

O GPT Pilot é concebido como um verdadeiro desenvolvedor de IA – não um preenchimento automático ou um chatbot . Em vez disso, é um desenvolvedor que cria um plano de como seu aplicativo ou recurso deve ser construído e inicia a codificação. Ele deseja fazer a maior parte da codificação sozinho, mas quando fica preso, precisa de esclarecimentos sobre os requisitos fornecidos ou de uma revisão do código, ele pede ajuda.

A IA é como um desenvolvedor júnior? Ou…

Costumo ver ferramentas baseadas em CodeGen GPT-4 que dizem que estão construindo um desenvolvedor júnior de IA.

De alguma forma, sempre tive problemas com isso porque quando uso o ChatGPT para codificação, ele me dá respostas e ideias que apenas uma pessoa super-sênior poderia dar – algo que absolutamente nenhum desenvolvedor júnior seria capaz de entender. Ainda assim, nenhum LLM pode construir um aplicativo tão bem quanto um desenvolvedor sênior, mas o conhecimento que o GPT-4 tem sobre codificação está muito além de qualquer desenvolvedor júnior.

Eu diria que o GPT-4 tem tanto conhecimento sobre todas as partes do desenvolvimento de software como se fosse o desenvolvedor mais sênior do mundo, mas com a memória de um peixinho dourado. Eu o imagino como um robô sobre-humano que fica parado no meio de uma sala e só consegue realizar uma pequena ação por vez, mas não consegue combinar muitas ações e trabalhar repetidamente. Você deve dizer exatamente o que deve fazer a seguir.

É isso que buscamos com o GPT Pilot – queremos criar uma estrutura de pensamento para o LLM que faça com que aquele robô sobre-humano trabalhe continuamente, revisando suas ações anteriores, tenha um ciclo de feedback e determine o que deve fazer a seguir para para finalizar o objetivo final, que é construir um aplicativo pronto para produção.

Na postagem do blog que mencionei acima , descrevi os principais pilares sobre os quais o GPT Pilot foi construído. Mas isso mudou um pouco com base no aprendizado da nossa equipe, então aqui estão os pilares revisados:

1. É necessário um ser humano para supervisionar a IA, não apenas porque a IA não é boa o suficiente, mas também porque você pode querer mudar a forma como algo funciona ou parece depois de implementado. É comum que um desenvolvedor ou gerente de produto, ao ver como é uma implementação, decida alterá-la.

   
   

2. Ou você percebe que há mais casos extremos do que inicialmente previsto e acha que é mais fácil refatorar sua implementação atual do que corrigir todos os problemas. O problema é quando você termina o aplicativo inteiro e tenta refatorá-lo – é aí que fica muito mais difícil porque cada mudança afetará todos os outros recursos.

   
   

   Por outro lado, se você refatorar antes de confirmar suas alterações, poderá prosseguir com os próximos recursos com base em um código bem escrito. É por isso que é crucial para um desenvolvedor de IA ter um ser humano informado sempre que uma tarefa é implementada .

   
   

   Dessa forma, o humano pode revisar a implementação de cada tarefa (assim como uma revisão de código antes de mesclar um PR) antes que o GPT Pilot continue para a próxima tarefa. Se um humano disser ao GPT Pilot o que está errado, será muito mais fácil corrigir os problemas na própria tarefa. Ao mesmo tempo, o LLM contextualiza o que precisa ser feito na tarefa e o que foi feito até agora.

   
   

3. A IA pode repetir seus próprios erros. Tenho a sensação de que muitas pessoas julgam a capacidade do ChatGPT de escrever código pela qualidade da entrega na primeira vez que você solicita algo. Se não produzir código funcional, muitos pensarão que não é impressionante. Na realidade, os humanos quase nunca escrevem código funcional na primeira tentativa . Em vez disso, você escreve o código, executa-o, vê os erros e itera. Isso é exatamente o que o GPT Pilot permite que o GPT-4 faça – depois de escrever o código, o GPT Pilot pode executar o código, obter a saída e perguntar ao LLM se a saída está correta, se algo deve ser corrigido e, em caso afirmativo, como .

   
   

4. O desenvolvimento de software pode ser orquestrado . Existem muitas rotinas repetitivas pelas quais todos os desenvolvedores passam ao construir um aplicativo. Uma das rotinas pode ser – escrever código, executá-lo, ler os erros, alterar o código, executá-lo novamente, etc. Outra rotina de nível superior pode ser – pegar uma tarefa, implementá-la, testar a implementação (repetir até que todos os testes sejam aprovados) , envie-o para revisão, corrija os problemas (repita até que o revisor aprove) e implante. Muitas dessas rotinas podem ser orquestradas se tivermos um tomador de decisão inteligente no circuito (como um LLM).

   
   

5. O processo de codificação não é uma linha reta . Quando criamos a primeira versão do GPT Pilot, pensamos que seria necessário iterar as tarefas, implementar o código, corrigi-lo e seguir em frente. Na realidade, você não progride continuamente ao codificar um aplicativo – você reescreve seu código o tempo todo.

   
   

   Às vezes, você refatora a base de código porque, após a implementação inicial, percebe que existe uma maneira melhor de implementar algo. Outras vezes, você faz isso devido a uma mudança nos requisitos. Como mencionei no item 1, depois de perceber que uma solução não está funcionando, às vezes você precisa reverter várias alterações, pensar em uma solução alternativa para o problema e tentar resolvê-lo dessa forma.

   
   

   Para fazer o GPT Pilot, ou qualquer outro desenvolvedor de IA, trabalhar em escala, ele precisa ter um mecanismo que lhe permita voltar atrás, escolher um caminho alternativo e reimplementar uma tarefa.

O que aprendemos?

LLMs, em geral, são uma nova tecnologia que todos estão tentando entender – como funciona, o que pode ser feito melhor, como fazer a engenharia imediata adequada, etc. LLMs para produzir melhores resultados .

O raciocínio é que os LLMs vão melhorar e, se passarmos semanas otimizando um prompt, isso poderá ser completamente resolvido com a nova versão do GPT.

Em vez disso, estamos nos concentrando em como deve ser a experiência do usuário e quais mecanismos são necessários para controlar o LLM para permitir que ele funcione continuamente, aproximando-se cada vez mais da solução final. Então, aqui estão nossos aprendizados até agora:

1. A descrição inicial do aplicativo é muito mais importante do que pensávamos . Nosso pensamento original era que, com a contribuição humana, o GPT Pilot seria capaz de navegar na direção certa e chegar cada vez mais perto da solução funcional, mesmo que a descrição inicial fosse vaga.

   
   

   No entanto, o pensamento do GPT Pilot se ramifica nas instruções, começando com a descrição inicial. E com isso, se algo for enganoso no prompt inicial, todas as outras informações que o GPT Pilot possui irão levar na direção errada. Então, quando você corrigir isso no futuro, ele estará tão profundamente envolvido nesse caminho incorreto que será quase impossível colocá-lo no caminho certo.

   
   

   Agora, enquanto escrevo isto, parece tão óbvio, mas isso é algo que precisávamos aprender – focar muito mais na descrição inicial. Portanto, construímos um novo agente chamado “Spec Writer”, que trabalha com você para detalhar os requisitos do projeto antes de iniciar a codificação.

   
   

2. A codificação não é uma linha reta . Como mencionei acima na seção de pilares, a refatoração acontece o tempo todo, e o GPT Pilot também deve fazer isso. Ainda não implementamos uma solução para isso, mas provavelmente funcionará adicionando a capacidade do GPT Pilot de criar marcadores em torno de sua árvore de decisão para que sempre que algo não estiver funcionando, ele possa revisar os marcadores e pensar onde poderia ter fez uma curva errada.

   
   

3. Os agentes podem revisar a si mesmos . Meu pensamento era que se um agente revisasse o que o outro agente fez, seria redundante porque é o mesmo LLM reprocessando as mesmas informações. Mas acontece que quando um agente analisa o trabalho de outro agente, ele funciona surpreendentemente bem. Temos 2 agentes “Revisores” diferentes que revisam como o código foi implementado.

   
   

   Um faz isso em alto nível, como a forma como toda a tarefa foi implementada, e outro revisa cada alteração antes de serem feitas em um arquivo (como fazer um git add -p).

   
   

4. Os LLMs funcionam melhor quando podem se concentrar em um problema em comparação com vários problemas em um único prompt. Por exemplo, se você disser ao GPT Pilot para fazer 2 alterações diferentes em uma única descrição, ele terá dificuldade em focar em ambas. Portanto, dividimos cada entrada humana em várias partes, caso a entrada contenha várias solicitações diferentes.

   
   

5. Logs detalhados ajudam . Isso é muito óbvio agora, mas inicialmente não instruímos o GPT-4 a adicionar nenhum log ao código. Agora, ele cria código com registro detalhado, de modo que, quando você executar o aplicativo e encontrar um erro, o GPT-4 terá muito mais facilidade para depurar ao ver quais logs foram gravados e onde esses logs estão no código.

   
   

6. Dividir a base de código em arquivos menores ajuda muito . Esta também é uma conclusão óbvia, mas tivemos que aprender. É muito mais fácil para o GPT-4 implementar recursos e corrigir bugs se o código for dividido em muitos arquivos em vez de alguns arquivos grandes. Assim como nós, humanos, pensamos – é muito mais fácil processar pedaços menores de código do que grandes. Fazemos isso criando níveis de abstração – funções, classes, etc.

   
   

   Uma das maneiras mais fáceis de fazer com que o LLM crie uma abstração mais gerenciável é simplesmente instruí-lo a criar mais código modular e dividi-lo em mais arquivos. Funciona incrivelmente bem e o resultado final também é melhor para nós, desenvolvedores.

   
   

7. Para que um humano seja capaz de consertar o código, ele precisa ver claramente o que foi escrito na tarefa e a ideia por trás dela . A meta do GPT Pilot é realizar 90% de todas as tarefas de codificação e deixar os outros 10% para um ser humano. Esses 10% geralmente incluem correções ou pequenas mudanças que o LLM tem dificuldade em perceber, mas para o humano pode ser uma mudança simples.

   
   

   No entanto, o problema é que não é fácil dizer ao ser humano o que não está funcionando e qual código ele deve examinar. Se o GPT Pilot escreve 3.000 linhas de código, o desenvolvedor humano, se quiser ajudar o GPT Pilot, precisa entender toda a base de código antes de mergulhar no código real.

   
   

   Nas versões futuras do GPT Pilot, o desenvolvedor humano terá uma explicação detalhada de qual código foi adicionado à tarefa atual e o raciocínio por trás dele. Dessa forma, você poderá ajudar o GPT Pilot.

   
   

8. Os humanos são preguiçosos . É melhor que os LLMs façam perguntas aos humanos em vez de deixá-los pensar sobre todos os erros possíveis. Novamente, é muito óbvio olhando para trás, mas uma das coisas que notamos foi que as pessoas estavam muito mais dispostas a responder às perguntas que o GPT Pilot lhes fazia, em vez de ter um campo de entrada aberto onde pudessem escrever feedback irrestrito.

   
   

9. É difícil fazer um LLM pensar fora da caixa . Esse foi um dos maiores aprendizados para mim. Achei que você poderia solicitar ao GPT-4, fornecendo algumas soluções que ele já havia usado para corrigir um problema e dizendo-lhe para pensar em outra solução. No entanto, isso não é tão fácil quanto parece.

   
   

   O que acabamos fazendo foi pedir ao LLM que listasse todas as soluções possíveis que pudesse imaginar e as salvasse na memória. Quando precisávamos tentar outra coisa, pegamos as soluções alternativas e pedimos que tentasse uma solução diferente, mas específica.

Aplicativos criados com GPT Pilot

Atualmente, você pode criar aplicativos simples, mas não triviais, com o GPT Pilot. Também vimos pessoas criarem aplicativos com GPT Pilot que são muito impressionantes, como um aplicativo que pode ajustar um modelo ResNet para contar palmeiras e então, quando você carrega uma imagem, contar as árvores nela. Aqui estão alguns aplicativos que criamos, junto com o código, estatísticas e demonstrações:

Laboratório de prompt ( DEMO )

Pense nisso como OpenAI Playground com esteróides – ele permite que você carregue uma conversa de um array JSON ou insira-a manualmente, execute a conversa com o LLM X várias vezes, salve a conversa no banco de dados e carregue-a novamente. na verdade, usamos este aplicativo quando projetamos um prompt e queremos ver como ele se comporta.

O Playground não é bom o suficiente porque é demorado executar novamente um único prompt repetidamente. Com o Prompt Lab, você pode escolher quantas vezes executá-lo e deixar o aplicativo executar o prompt repetidamente.

Quando terminar, você pode analisar os resultados. Isso pode ser útil para pessoas que estão criando um aplicativo de IA e precisam otimizar seus prompts.

• ⏳ Tempo gasto: ~2 dias
• 💾 Repositório Github

Ferramenta SQLite Database Analyzer ( DEMO )

Este também é um aplicativo que usamos internamente para analisar um banco de dados SQLite local. Ele extrai os dados do banco de dados em um formato muito específico para a estrutura do banco de dados GPT Pilot, mas pode ser facilmente modificado para se adequar a outras estruturas.

Ele lê e carrega seu banco de dados SQLite, divide as linhas por um campo específico, descompacta as linhas em valores, carrega os dados da conversa LLM em um formulário e permite que você simplesmente altere uma das mensagens e envie a solicitação LLM para GPT-4 para ver como ficarão os resultados.

Dessa forma, você pode analisar as conversas que os agentes do GPT Pilot têm com o LLM e explorar facilmente o que aconteceria se os prompts fossem diferentes.

• ⏳ Tempo gasto: ~2 dias
• 💾 Repositório Github

Sussurrador de Código ( DEMO )

Code Whisper é um projeto divertido que criamos como exemplo para mostrar. A ideia é que você possa usá-lo para fazer perguntas ao LLM sobre sua base de código. Você cola o link para um repositório público do Github.

Em seguida, ele clona o repositório, envia os arquivos relevantes ao LLM para análise, que cria uma descrição para cada arquivo sobre o que o código faz e salva essas descrições no banco de dados.

Depois disso, você pode fazer perguntas ao aplicativo sobre a base de código, e a base de código mostra a resposta. Nesta demonstração, usamos GPT-3.5.

• ⏳ Tempo gasto: 7 horas
• 💾 Repositório Github

História da Estrela ( DEMO )

Tenho lançado projetos de código aberto há anos e sempre quis ver o quão rápido meu repositório Github está crescendo em comparação com outros repositórios de sucesso em https://star-history.com/ . O problema é que no Star History não consigo ampliar o gráfico, então um novo repositório que tem 1.000 estrelas não pode ser comparado com um grande repositório que tem 50.000 porque você não consegue ver como o repositório maior se sai no início .

Então, pedi ao GPT Pilot para construir essa funcionalidade. Ele coleta repositórios do Github para observadores de estrelas, salva-os no banco de dados, plota-os em um gráfico e permite que o gráfico seja ampliado e reduzido.

• ⏳ Tempo gasto: 6 horas
• 💾 Repositório Github

Conclusão

Espero que você tenha obtido alguns insights sobre o estado atual, os problemas e as descobertas com os quais lidamos no GPT Pilot.

Então, para recapitular:

Achamos que uma verdadeira ferramenta de desenvolvimento de IA deve ser baseada nos seguintes pilares:

• É necessário um humano para supervisionar a IA.

  
  

• Devemos permitir que a IA repita os seus próprios erros.

  
  

• O desenvolvimento de software pode ser orquestrado , o que deve ser implementado em uma camada acima dos LLMs.

  
  

• O desenvolvedor de IA deve ser capaz de refatorar a base de código porque, na realidade, o processo de codificação não é uma linha reta.

Até agora, aprendemos que:

1. A descrição inicial do aplicativo é muito mais importante do que pensávamos

2. A codificação não é uma linha reta, os agentes podem revisar a si mesmos

3. LLMs funcionam melhor quando se concentram em um problema em comparação com vários problemas em um único prompt

4. Logs detalhados fazem milagres

5. Dividir a base de código em arquivos menores ajuda muito

6. Para um humano ser capaz de consertar o código

7. Devem ser mostrados claramente o que foi escrito e a ideia por trás disso

8. Humanos são preguiçosos

9. É difícil fazer com que o LLM pense fora da caixa

   
   

O que você acha? Você notou algum desses comportamentos em suas interações com LLMs ou tem uma opinião diferente sobre algum deles?

Ficarei muito feliz em receber notícias suas, então deixe um comentário abaixo ou envie-me um e-mail para [email protected] .

Você pode tentar criar um aplicativo com IA com GPT Pilot aqui:

• Repositório de código aberto GPT Pilot
• Extensão do código GPT Pilot VS

Se você gostou deste post, significaria muito se você estrelasse o repositório GPT Pilot Github e, se você experimentar, diga-nos o que você pensa. Seu feedback é muito importante para toda a equipe piloto do GPT.

Também publicado aqui