Apresentando meu viés, ao analizar este artigo:
Eu tenho explorado já há algum tempo o tema do uso de ferramentas de IA para a tarefa de desenvolvimento de software, e minha posição sobre o hype é bastante clara:
Inclusive comentando sobre o uso dessas ferramentas, e seu impacto aparente de longo prazo. Esse post é uma continuidade do que já estou escrevendo.
Github Copilot e Qualidade de código. Como mentir com estatística
Github Copilot é talvez a principal ferramenta na atualidade quando se fala de assistentes de código. O peso da Microsoft, com a sua abordagem de produto peculiar, tem com certeza aumentado o hype da ferramenta e provavelmente se você está num contexto corporativo, já bateram na sua porta oferecendo AI dentro do Pacote do Visual Studio, ou do Office 365.
A um preço realmente caro, na casa dos US$400 por ano por dev, o mínimo que se espera é que a empresa apresente resultados e informações consistentes sobre a eficiência do uso da ferramenta.
Pois é isso que o último artigo "Github Copilot aumenta a qualidade de código? Isso é os dados dizem" se propõe a demostrar, com a análise sobre o impacto positivo na qualidade de código que o uso de copilot pode trazer para seu time.
O artigo é terrível, e o estudo extremamente enviesado e sem muito critério. Parece que foi escrito por uma LLM com o prompt: "crie um estudo sobre qualidade de código que fale bem do copilot". Esperava maior rigor da empresa.
Primeira regra de uma pessoa de tecnologia:
Empresas não divulgam pesquisas com resultados ruins sobre seus produtos. Não existe incentivo nenhum em divulgar informações que possam impactar negativamente a venda de seus produtos.
Separar o marketing de tecnologia das informações relevantes é a skill importante no mundo de vendedores de ferramenta.
O Estudo - Qualidade de código?
Segundo o próprio artigo:
"Resultados in nosso último estudo mostram que a qualidade de código escrito com o Github Copilot é significativamente mais funcional, legível, confiável, manutenível e concisa"
Este estudo foi, provavelmente, feito para um Executivo ou Líder de tecnologia sem conhecimento técnico, e consegue facilmente dar a entender que estamos diante de um salto quântico de melhoria. Numa primeira passada, a expectativa é grande e a possiblidade de quando de performance, a eterna busca do mercado.
Os resultados apresentados são interessantes, mas não se sustentam numa análise minimamente detalhada.
GitHub conduziu um experimento com 243 desenvolvedores, divididos em dois grupos: um usando Copilot e outro não. As principais alegações incluem:
Desenvolvedores usando Copilot têm 56% mais chances de ter todos os testes passando
Usando Copilot consegue adicionar 13% mais código antes de introduzir algum Code smell
Usando Copilot o código é 3.62% mais legível, 2.94% mais confiável, 2.47% mais manutenível, e 4.16% mais conciso;
PRs de usuários do Copilot têm 5% mais chances de serem aprovados sem comentários
O que a minha mente cética vê nessas afirmações:
Com tanto tempo no mercado, eu posso dizer com 99.99% de certeza que essas métricas não significam absolutamente nada. Zero, niente, rien, 白 - e não devem ser usadas nesse contexto!
Porque esse gráfico acima erra também nos percentuais? Foi o Bing que fez? 62.2% + 39.2% = 100% ??!?! Como assim?!
Além disso, sem avaliar o contexto e o significado, um aumento de 2.94% em confiabilidade me parece um erro de arredondamento! Esse tipo de percentual é irrisório e sem significado: "hoje estou 2% mais gordo, tomei uma coca-cola no almoço"
Qual o desafio técnico avaliado?
Difícil de acreditar que a empresa conseguiu somente 243 indivíduos para fazer essa pesquisa - um número infinitamente pequeno para se ter alguma percepção da complexidade do trabalho de desenvolvimento de software e sua interação diária. Mas é interessante saber qual foi o desafio em que o uso do Copilot foi avaliado:
Escrever código para uma API fictícia de um APP de review de restaurante. Cada grupo completou o exercício com 10 testes de unidade para validar a funcionalidadeJunto com construir uma app de TODO List, talvez seja o desafio de entrevista mais conhecido do mundo, e bem longe do dia a dia de trabalho de desenvolvimento (Ainda que eu acredite que CRUD seja a maior parte das aplicações hoje em dia).
Se você treinar a sua própria rede neural no seu celular é capaz de conseguir responder a esse desafio - sem nenhuma LLM moderna.
Quantos casos esse 10 testes de unidade conseguem cobrir para uma API? Qual a real complexidade e relevância desse endpoint coberto por testes?
O que é Qualidade de Código?
Informação interessante to texto: Inicialmente é dito que Copilot pode adicionar até 13% mais código até introduzir code smell. Ao olhar o gráfico, estamos falando de 2 linhas de código. Estatisticamente relevante (segundo eles), mas praticamente inútil.
Onde o artigo nitidamente dá uma viajada é na hora de definir a avaliação de qualidade e erros para o teste:
Neste estudo, nós definimos Erros de Código como qualquer código que reduz a capacidade deste código ser facilmente compreendido. Não incluindo erros funcionais que podem impedir o código de funcionar, mas ao invés disso, erros que representam praticas ruins de código.
Ou seja: gerar código que não funciona não foi o critério do estudo. Afinal, não é importante para qualidade de software. E ao invés disso, foram analisados
Inconsistência de nomes, identificadores obtusos, tamanho excessivo de linhas, excesso de espaços, documentação faltante, código repetido, profundidade do loop, separação de funcionalidade insuficiente e complexidade variante.
O problema com esses items é que eles não significam muita coisa sem o contexto da tecnologia, experiência dos envolvidos, familiaridade com a linguagem. E nenhum desses itens avaliados tem uma definição muito clara e definitiva para qualquer linguagem de programação.
O que é duplicação para Rust, não necessariamente é para Java. O que parece absurdo de entender para quem não conhece de C++ e manipulação de matrizes, é o dia a dia de quem trabalha com Arduino e IoT.
Um exemplo:
Sem o contexto ou conhecimento, essa linha de código não é boa o suficiente. Mas para quem está estudando OpenCV e YOLO, é uma linha tranquila de entender.
cv2.putText(img, f"{class_name} {confidence:.2f}", vertex1, cv2.FONT_HERSHEY_SIMPLEX, 1, colour, 2,)
Toda equipe precisa criar as próprias convenções de código, para dar significado ao que é Qualidade de Código. Seja em C, Javascript, Rust ou Typescript, contexto e experiência são infinitamente mais importantes.
Apresentar uma estatística com a suposição de que o uso de uma ferramenta traz ganhos significativos, ao mesmo tempo em que mostra 3% de melhora em métricas subjetivas é no mínimo questionável, e me faz pensar se esse artigo não é direcionado para persuadir erroneamente pessoas que não entendem o mínimo de Tecnologia, mas que podem assinar o cheque com a expectativa de ganho de performance.
Em um dos meus últimos artigos, eu já apresentava resultados muito mais detalhados do uso de LLMs como assistentes de codificação, e a tendência que estamos identificando de aumento de complexidade, churn de código e potencial redução de qualidade. Vale a pena ler.
Jadarma faz uma análise ainda mais detalhada das diversas falhas desse "estudo", indo mais além e demonstrando como, da escolha do grupo de estudo, ao cálculo estatístico dessa notícia, tudo está errado.
Esperava mais.
Comentários