O impacto da IA generativa em trabalhos de alta qualificação: um experimento com desenvolvedores de software
(papers.ssrn.com)Resumo
- Visão geral da pesquisa
- Este estudo avalia o impacto da IA generativa na produtividade de desenvolvedores de software por meio de três experimentos controlados randomizados conduzidos na Microsoft, Accenture e em uma empresa anônima de manufatura eletrônica da Fortune 100.
- Os experimentos foram realizados como parte do trabalho cotidiano de cada empresa, oferecendo a desenvolvedores selecionados aleatoriamente um assistente de programação baseado em IA chamado GitHub Copilot.
- Com um total de 4.867 desenvolvedores de software, o estudo constatou que o número de tarefas concluídas pelos desenvolvedores que usaram ferramentas de IA aumentou 26,08% (erro padrão: 10,3%).
- Em particular, desenvolvedores menos experientes apresentaram taxas de adoção e ganhos de produtividade mais altos.
Resumo do GN⁺
- Este estudo mostra que a IA generativa pode aumentar significativamente a produtividade de desenvolvedores de software.
- Ela é especialmente útil para desenvolvedores menos experientes, sugerindo que ferramentas de IA podem ajudar a suavizar a curva de aprendizado.
- Ferramentas de IA como o GitHub Copilot podem desempenhar um papel importante no aumento da eficiência no desenvolvimento de software.
- Outros projetos com funcionalidades semelhantes incluem TabNine e Kite.
1 comentários
Opiniões do Hacker News
Às vezes me pergunto se a queda na qualidade da mão de obra de TI acontece porque as empresas estão empurrando cada vez mais funções para uma única pessoa para reduzir o quadro
Antes, desenvolvimento, operações e segurança eram funções dedicadas separadamente; quando criaram DevOps, algumas empresas entenderam isso não como integração de equipes, mas como sinal de que bastava ter 2/3 do pessoal; quando criaram DevSecOps, passaram a achar que bastava ter 1/3 das funções originais e que o desenvolvedor poderia cuidar também de operações e segurança de aplicações
Não estou criticando shift-left nem o modelo de operações integrado em si; quero dizer que esse é o resultado lógico que esses modelos produzem quando executivos acham que podem ganhar bônus maiores cortando custos ao reduzir pessoas
Agora o desenvolvedor júnior entra em um ambiente de n microsserviços absurdamente complexo e precisa aprender a base de código existente, cinco pipelines de CI/CD e até a função de DBA, ao mesmo tempo em que mantém um ciclo constante de releases
Será mesmo tão surpreendente que usem ChatGPT para tentar acompanhar? E isso vai continuar até as empresas de TI pararem de reduzir pessoal para “fazer a linha subir”, em vez de adotar boas estratégias de negócio
Acho que o que os MBAs deixam passar é o fenômeno das restrições excessivas. Quando se divide uma função genérica de “desenvolvedor” em “desenvolvimento, operações, segurança”, surgem todos os tipos de detalhes sobre como cada papel deve ser executado. Mesmo que se junte tudo de novo como DevSecOps, esses detalhes permanecem; então não é que uma pessoa trabalhe com 3 vezes mais eficiência, ela passa a carregar 3 vezes mais trabalho
Para reverter isso de verdade, é preciso aliviar as restrições e permitir que essa pessoa julgue como o trabalho deve ser feito
A conclusão disso é que o tamanho das organizações não pode diminuir, apenas aumentar. À medida que o número de funcionários cresce, os cargos ficam mais especializados; se você os elimina, aquela função simplesmente deixa de ser executada. Nesse nível de especialização, é difícil para os funcionários restantes assumirem novas responsabilidades só mudando um pouco a descrição do cargo
No fim, é preciso abandonar a organização antiga e recomeçar com uma organização nova e menor; é também por isso que existem os ecossistemas de private equity/venture capital/startups. A lei de Gall segue a mesma linha: https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law
Por outro lado, olhando para as novas startups que estão surgindo hoje, há cada vez mais gente realmente talentosa. Acho que, em um ambiente de financiamento mais apertado, é preciso ter gente de verdade muito competente para abrir uma empresa, e essas pessoas contratam outras pessoas excelentes
A indústria de tecnologia atual parece muito mais com o período de 2004 a 2008, quando quase todo mundo interessado em startups entrava porque gostava de hackear problemas técnicos
Pela minha experiência usando o Cursor, ele é excelente para o tipo de coisa que um engenheiro mediano consegue fazer, mas péssimo em tarefas mais avançadas do que isso, e também exige a capacidade de entender código alheio muito rapidamente
Talvez isso permita que engenheiros técnicos seniores que não se concentram em frontend ou desenvolvimento de apps web deixem de contratar tantos desenvolvedores web júnior quanto antes. É parecido com o desaparecimento dos webmasters depois que surgiram frameworks e ferramentas para criar rapidamente HTML/CSS básico para páginas web
Digamos que uma pessoa de “DevSecOps” esteja fazendo 3 vezes o trabalho que deveria fazer; também precisamos olhar para o que mais ela faz. Ela pode acabar reservando viagens, prestando contas e fazendo relatórios de despesas, dividindo e reportando horas de trabalho por classificação de negócio, gerenciando férias, administrando reuniões, criando apresentações com gráficos feitos por ela mesma e preparando 80% das compras de fornecedores externos
Essas tarefas não estão na descrição do cargo, atrapalham o trabalho real e corroem de forma desproporcional a capacidade de executar a função principal. Antigamente havia especialistas dedicados para cada uma dessas coisas, que conseguiam fazê-las com 10 vezes mais eficiência e por muito menos dinheiro
Especialistas como secretárias, departamentos internos de design gráfico e pessoal de finanças apareciam nas demonstrações financeiras. Eliminar esses papéis não faz o trabalho desaparecer; ele só é distribuído em pequenos pedaços para todo mundo, sob a justificativa de que softwares de escritório self-service melhoram a “produtividade”
O resultado é que todo mundo fica desproporcionalmente mais lento, mas quem olha só para os números enxerga apenas o dinheiro economizado nos salários dos cargos eliminados. A lentidão aparece apenas como uma sensação difusa e genérica de queda de produtividade, uma misteriosa doença de custos que todos sofrem
Não acho que haja nada de misterioso: não há aumento de produtividade; pelo contrário, há perda. Só que, como custos claros e visíveis são transformados em custos distribuídos e difíceis de calcular, fica fácil se iludir achando que se está economizando dinheiro
A competência essencial que está sendo esquecida é a capacidade de entender o negócio em que a empresa atua. Mesmo uma capacidade de desenvolvimento razoável, quando combinada com um bom entendimento dos objetivos de negócio, pode continuar relevante enquanto alguns desenvolvedores puros são substituídos por IA
Em 13 anos em uma empresa do setor bancário, vi a complexidade aumentar muito, junto com uma burocracia absurda. Ainda consigo fazer o trabalho necessário, mas não tenho acesso. E também não posso ter
Uma tarefa simples agora virou uma negociação em 10 etapas com alguma equipe desconhecida em Pune, que preciso perseguir e escalar 10 vezes até que reconheçam que têm algo a fazer de fato
Os processos ficaram tão ridículos que, quando algo começa, não se sabe se levará 2 dias ou 3 meses. Todo aplicativo quebra relativamente rápido se não for mantido continuamente, por causa de alguma nova tarefa de rede, alguma atualização Unix não validada ou uma das inúmeras coisas que inevitavelmente vão acontecer
No fim, os processadores de papelada e as pessoas que são medianas até no próprio trabalho se entrincheiraram nos processos e venceram; as áreas de negócio recebem TI de baixa qualidade, e os projetos atrasam e estouram o orçamento. Isso só reforça ainda mais a imagem de TI como um “mal ruim, mas que precisa ser tolerado”
Agora desliguei emocionalmente, e basta que o trabalho seja um meio para a vida. Meu foco e minhas realizações estão nessa parte da “vida”
O que você mede é importante. Este estudo analisou apenas o uso do Copilot
Sou um engenheiro experiente e, para mim, o Copilot não só é inútil como atrapalha. Passo a maior parte do tempo entendendo o domínio do problema, identificando as restrições e possibilidades do ambiente em que estou e pensando no código que vou escrever
Quando de fato começo a digitar o código, já sei o que vou escrever, então o autocompletar “útil” do Copilot só me distrai. Ele piora muito meu fluxo de trabalho
Por outro lado, a IA é extremamente útil nas etapas anteriores à codificação em si. Às vezes, com base no raciocínio feito previamente, dá para obter um rascunho só com um prompt bem elaborado, e depois é muito útil trabalhar em dupla com um LLM para obter respostas rápidas para pequenos problemas inesperados que surgem
Por isso, ao contrário deste relatório, acho que desenvolvedores experientes, se usarem bem IA, podem ter um ganho maior do que desenvolvedores inexperientes
Mas usar o Claude Sonnet 3.5 com Cursor ou Continue.dev melhora isso drasticamente. Dá para controlar explicitamente o contexto, por exemplo selecionando e injetando 6 ou 7 arquivos, e, somando a excelente capacidade do Claude, isso muda completamente o jogo
Dependendo da tarefa, fico facilmente de 2 a 5 vezes mais rápido. Algo que originalmente poderia levar meio dia pode virar, em menos de uma hora, 100 linhas de código pronto para produção, com testes
Digo isso da perspectiva de alguém com 26 anos de experiência e que atua em papéis de principal/staff/lead desde 2012. Porém, não espero o mesmo ganho para quem tem experiência abaixo de sênior. Isso porque é preciso explicar com bastante detalhe o que se quer e, normalmente, pegar uma solução inicial funcional e refiná-la umas seis vezes até chegar a uma forma ideal e bem decomposta
Por exemplo, ao escrever IaC para AWS, há muita coisa para consultar. Quando pergunto à IA, obtenho respostas e exemplos muito rapidamente. Se estou aprendendo IaC de um serviço novo, vou olhar a documentação da AWS, mas quando só preciso de uma resposta rápida ou de uma revisão, a IA é muito mais rápida
Quanto mais você se apoia em padrões funcionais, projeta mônadas, faz entrada e saída apenas nas bordas e usa fluent programming, maior é o efeito
Para referência, essa é minha experiência em Java. Uso Java há 3,5 anos e dependo bastante de recursos do Java 8+. Quando se usa muitos genéricos em código de biblioteca, há mais espaço para o LLM fazer escolhas consistentemente corretas
Em designs mais rápidos e feitos de qualquer jeito, não se obtém tanto esse ganho. Gostaria de ouvir mais relatos de usuários de programação funcional de verdade, como Haskell, OCaml, F# e Scala
Ele foi útil para escrever boilerplate de testes unitários, especialmente testes baseados em tabela, mas não a ponto de justificar manter uma assinatura paga
Ele foi muito valioso quando eu trabalhava em uma linguagem com a qual não estava familiarizado ou em tarefas repetitivas nas quais era fácil avaliar se o código gerado estava bom
Por outro lado, fica fraco quando aquilo que quero fazer está muito claro e é parecido com uma implementação padrão, mas um pouco mais novo. Isso acontece com frequência em coisas como “reduce” ou em procedimentos mais ambíguos
Como engenheiro de plataforma, alterno entre vários espaços — Bash, Python, navegador, JS puro, TS, Node, GitHub Actions, fluxos de trabalho Java no Jenkins, Docker etc. —, e ele ajuda a descansar o cérebro e aquecer quando troco de domínio
Fico curioso se o estudo incluiu a dívida técnica que desenvolvedores menos experientes geraram ao contribuir com IA e que depois precisou ser tratada por desenvolvedores mais experientes. Digo isso porque passei muito por isso pessoalmente em uma das empresas citadas no estudo
Também vi pessoalmente que desenvolvedores com pouco interesse na tecnologia em si, mas muito interesse em entregar, demonstram mais entusiasmo por IA. PMs gostam desse tipo de pessoa, mas
O que tínhamos pedido era uma pequena alteração de umas 5 linhas e testes. Mas agora ficamos não só com uma nova dívida, como também com código que ninguém consegue explicar por que foi completamente alterado, parte dele sendo mudança pela mudança, e até código totalmente estranho para as pessoas que mantêm esse código
Vejo isso repetidamente entre usuários dessas ferramentas que não são engenheiros sênior. No fim, passamos a rejeitar esses PRs e mandar refazer, e o ganho de tempo que se achava ter obtido no começo desaparece
Isso não quer dizer que essas ferramentas sejam inúteis, mas as pessoas as usam sem entender o que é a saída gerada e sem entender o impacto de longo prazo na base de código
O dia em que perdi uma parte da minha alma foi quando perguntei a um desenvolvedor se eu podia dar feedback sobre o schema do banco de dados e, depois de ele dizer que sim, poucos minutos depois me interrompeu dizendo: “é, eu não tenho muito interesse em X”
Não tem interesse? Como especialista na área, estou dizendo o que pode ser melhorado, como fazer e por quê, e você não tem interesse?
A nuvem foi um erro. Ela colocou na cabeça das pessoas a ideia de que, como dá para escalar verticalmente/horizontalmente a qualquer momento, não há necessidade de buscar eficiência e otimização. Nem estou falando de microbenchmarks, mas de coisas muito simples, como “não seria melhor usar esta estrutura de dados em vez daquela?”
Também usamos internamente, e considero a dívida técnica uma ameaça enorme e mal dimensionada
É muito útil para aplicar em massa APIs e padrões desconhecidos ao código, mas, se você não tomar cuidado, gera uma quantidade enorme de duplicação de código e boilerplate difícil de lidar
Isso acontece por causa de dois vieses grandes. Primeiro, os dados de treinamento do modelo são exemplos no estilo StackOverflow, sem considerar contexto e restrições. Segundo, em vez de olhar para a base de código existente e sugerir refatorações, ele tende a copiar e repetir
O primeiro ponto acaba sendo mitigado quando você faz seu trabalho: revisar e editar o que o LLM cuspiu
O segundo só pode ser mitigado se diffs e histórico de commits entrarem nos dados de treinamento, mas esse conjunto de dados é muito mais difícil de tratar e rotular. Algumas mudanças são boas, como refatorações, mas outras podem ser bugs que serão corrigidos em commits posteriores, e as mensagens de commit são basicamente mentiras, então também não há uma distinção clara. Ninguém escreve “introdução de bug”
Além disso, merge, rebase e squash mudam, removem ou adicionam ruído ao significado do histórico, deixando tudo ainda mais nebuloso
Eu gosto de tecnologia e escrevo software por diversão, mas trabalhar com IA é objetivamente mais divertido. Minha produtividade aumenta muito mais e, acima de tudo, a procrastinação desaparece
Quando fico travado ou sem vontade de começar uma tarefa, começo a conversar com o Aider e, quando percebo, já terminei uma tarefa naquele dia que eu não teria feito sem IA
Graças a isso, projetos públicos/privados que antes levavam de meses a anos agora eu lanço a cada 2 semanas. É como ter ao meu lado uma equipe de desenvolvedores rápidos e experientes pelo custo de, no máximo, alguns dólares por dia
Antes de tirar conclusões, é preciso olhar o artigo um pouco mais a fundo. Acho que o próprio estudo poderia ter resumido melhor os resultados.
O resumo e a conclusão apresentam apenas um percentual como resultado: aumento de produtividade de 26,08%, mas parece ter casas decimais demais. Ao entrar um pouco mais nos detalhes, aparecem números de 27% a 39% para juniores e de 8% a 13% para seniores.
Indo ainda mais fundo, há grande variação não só por experiência, mas também por empresa. Na Microsoft, além de pull requests, outros indicadores de resultado como commits, builds e taxa de sucesso de builds parecem não ser estatisticamente significativos. O aumento de PRs também parece significativo na Microsoft, mas não na Accenture; e mesmo assim talvez apenas para juniores.
O resumo e a conclusão precisam resumir, claro, mas como os resultados variam demais conforme as variáveis, não sei se faz sentido dar um único número geral como resumo. Especialmente porque a significância estatística parece bastante irregular.
A Accenture é uma empresa que coopera e faz marketing conjunto com grandes organizações como a Microsoft. Um grupo de cerca de 300 desenvolvedores quase não move a amostra total e, como a empresa está criando divisões de marketing/consultoria em torno de fluxos de trabalho com IA, também é difícil presumir objetividade.
A terceira empresa anônima, na prática, não era um experimento controlado randomizado, então é difícil dizer como seus resultados deveriam ser combinados com os RCTs. Além disso, como provavelmente havia outras grandes empresas de tecnologia fazendo experimentos semelhantes e interessadas em saber a eficácia, dá para supor que existam outros dados além dos incluídos nos resultados.
Por que escolheram essas empresas dentro de um conjunto de amostras maior? Provavelmente porque Microsoft e Accenture têm incentivos para a adoção, e a terceira empresa foi escolhida por p-hacking.
Em especial, a frase do resumo “cada experimento individual é ruidoso, mas, ao combinar os três experimentos” é um sinal muito ruim. É praticamente admitir que, olhando cada empresa isoladamente, não há resultado estatisticamente significativo, mas que ao combinar esses três grupos ele se torna significativo. Isso não é ciência.
Desenvolvedores juniores podem estar fazendo tarefas que LLMs acertam com mais facilidade, ou cometer o erro de aceitar o primeiro rascunho só porque parece LGTM, o que pode fazer o throughput parecer maior.
Usar modelos de geração de código também exige habilidade, e essa habilidade é a mesma necessária para delegar trabalho a outras pessoas e integrar soluções de vários autores em um sistema coeso.
É só meu instinto, mas acho que codificação assistida por LLM é prejudicial para crescer como desenvolvedor. Parece que ela consegue elevar a produtividade só até certo nível, e esse nível pode ser uma repetição entediante para seniores, mas é formativo para juniores.
Pela minha experiência, LLMs não são usadas apenas para boilerplate simples; elas são acionadas quando um desenvolvedor júnior enfrenta uma tarefa bastante comum que ainda não entende o suficiente. O processo de experimentar, aprender e entender acaba sendo em grande parte substituído pela LLM, e a habilidade real passa a ser ajustar o prompt até parecer que funciona.
Ontem à noite configurei Linux RAID pela primeira vez. Não é algo muito difícil, mas exige várias ferramentas — mount, umount, fstab, blkid, mdadm, fdisk, lsblk, mkfs etc. — e, no meio do caminho, as coisas podem seguir de modo diferente dos passos exatos do guia, então olhar apenas tutoriais ou documentação não é particularmente útil.
Fiz dezenas de perguntas sobre cada ferramenta e etapa; antigamente eu teria simplesmente copiado, colado e rezado.
Dois dias antes, também consegui recuperar todos os dados de um SSD com defeito aprendendo pelo ChatGPT. Mesmo que 20% possa estar errado, foi muito bom lidar com uma tecnologia totalmente nova tendo um “guia” muito melhor do que a média da internet aberta.
Para quem gosta de aprender, parece uma bota de sete léguas em comparação com vasculhar lixo infinito na internet. Claro, como tudo na internet, é preciso desconfiar do que a IA diz, mas ela reduz enormemente o incômodo.
Tenho a mesma intuição e iria além: gostaria de chamá-la de uma opinião forte e embasada. Acho que a indústria vai pagar o preço daqui a alguns anos.
O pipeline de oferta de “desenvolvedores de software juniores com feeling” vai secar bastante e será substituído por uma enxurrada de “desenvolvedores de software juniores dependentes de IA”. Há um abismo profundo entre essas duas categorias.
Naturalmente, isso terá efeitos em cadeia também no número de desenvolvedores plenos com feeling e de desenvolvedores seniores com feeling.
Por outro lado, quem quer entender todo o código que usa provavelmente vai pesquisar as partes que não conhece daquilo que a LLM produziu.
Pelo menos é assim que eu uso. E, como contraexemplo à hipótese, às vezes a LLM usa funções ou componentes de bibliotecas que eu não conhecia, então ela economiza muito tempo ao aprender uma linguagem ou toolkit novo. Para mim, em vez de retardar o aprendizado, ela o acelera.
Mas, para pessoas que de qualquer forma teriam sucesso, é como fazer uma pergunta no StackOverflow e receber uma resposta imediata e sem julgamento; é um presente enorme.
Nem sempre estará certo, mas o StackOverflow também era assim. No fim, como sempre, depende da pessoa.
Quantos desenvolvedores de hoje sabem usar linguagem de máquina, algo que 50 anos atrás era praticamente indispensável para construir alguma coisa?
Talvez as LLMs estejam passando de mais uma muleta de abstração para um pilar sólido de abstração.
O ponto mais interessante deste estudo é que, ao segmentar por nível de carreira, desenvolvedores com tempo de casa acima da mediana não tiveram aumento estatisticamente significativo nesse proxy ruim chamado “produtividade”. O intervalo de confiança de 95% chega a descer bastante para o lado negativo em todas as métricas, embora fique apenas ligeiramente inclinado para o positivo
Isso bate com a minha experiência. O Copilot é bom no sentido de reduzir algumas tarefas tediosas e permitir usar o cérebro em perguntas mais profundas, mas não é algo que mude o mundo como alguns desenvolvedores juniores dizem
Além disso, ele frequentemente erra de forma sutil, de um jeito que um desenvolvedor menos experiente pode deixar passar. Eu preciso parar e ajustar a maior parte do que ele gera, e é bem provável que um desenvolvedor menos habilidoso não saiba como fazer esses ajustes
Depois de alguns anos usando, agora tenho uma boa noção de quando usar e quando não usar o Copilot, então acho que o efeito líquido é positivo, mas nem sempre foi assim
Também me pergunto se parte do motivo de a “produtividade” dos desenvolvedores seniores parecer ter diminuído não seria o aumento de produtividade dos juniores na empresa. Se os juniores criam mais PRs e eles têm mais erros, aumentando o tempo de revisão, o ganho de produtividade dos seniores pode diminuir proporcionalmente
Aumento de produtividade de 26% bate, em geral, com a minha experiência. Acho que uma dimensão a investigar mais é se a pessoa está lidando com uma tecnologia nova ou com uma tecnologia que já conhece. A IA é muito mais útil em linguagens ou frameworks que estou tentando aprender
Não lembro bem das peculiaridades e armadilhas de linguagens auxiliares, como exatamente qual feitiço de aspas é necessário para escrever condicionais em Bash. Por isso, no passado eu quase não escrevia scripts Bash para automação, e só fazia o esforço em tarefas que realizava com bastante frequência. O mesmo valia para processar JSON com jq ou fazer parsing com AWK
Agora, graças aos LLMs, crio muito mais scripts Bash e, por ter ficado fácil demais, também os uso com mais frequência para documentar processos. O que antes era um README estático passo a passo agora vem acompanhado de um script Bash interativo que recebe entradas do usuário
Em geral, vejo muitos programadores seniores discutindo por que as ferramentas de IA não funcionam. Os juniores simplesmente usam, sem preconceitos
Ele foi útil em quatro situações. Primeiro, para perguntas sobre frameworks/linguagens que não uso com frequência, mas que têm muito conteúdo de exemplo, como Qt ou CSS
Segundo, para perguntas muito específicas que antes eu teria pesquisado no Google Search ou no StackOverflow. Por exemplo, numa pergunta como “qual é a forma mais eficiente de obter o uso de CPU e RAM do Windows com Python”, ele aponta bibliotecas ou exemplos em vez de simplesmente gerar código para copiar e colar
Terceiro, para código boilerplate que eu já sei escrever, mas que economiza um pouco de tempo e reduz erros de digitação. Usando o plugin CoPilot para PyCharm, se escrevo a intenção em um comentário no arquivo, ele completa as próximas linhas. De novo, os resultados são melhores quando é algo muito curto e específico. Quando fica mais longo, é preciso iterar demais com o CoPilot e deixa de valer a pena
Quarto, como forma de pesquisar documentação rapidamente
Há quem diga que ele é bom para escrever testes unitários, mas para mim não foi. Pelo menos não o tipo de teste unitário que eu quero
Se eu fosse quantificar, diria que aumenta a produtividade em algo como 5% a 10%. É muito menos do que usar uma IDE completa como PyCharm em vez do Notepad, ou usar um bom cliente Git em vez de digitar comandos git diretamente na CLI. Ou seja, é apenas uma entre várias ferramentas de produtividade; eu não chamaria de “revolucionária”
Usei o Cursor por cerca de 10 dias em um projeto enorme de Ruby on Rails, stack que uso há mais de 13 anos
Não obtive ganho além do aumento de produtividade que o GitHub Copilot já proporcionava. Estimo que o ganho do Copilot seja de cerca de 25%
Mas, no caso de criar do zero um projeto novo como Node.js em uma pasta vazia, ele é estranhamente poderoso. Só com prompts, dá para criar em cerca de 5 minutos uma API que processa requisições a partir de um schema OpenAPI e fornece o schema OpenAPI via swagger
Porém, começar projetos novos do zero é algo raro para mim, então provavelmente vou voltar ao Copilot com o VSCode básico
Ele permite que as pessoas criem mais PRs. Uau, impressionante. Quem se importa
O número de itens que passam pelo QA aumenta? As coisas feitas com assistência de IA têm menos bugs encontrados depois do QA? São fáceis de estender ou modificar depois, ou têm um design rígido e inflexível?
Uma ferramenta que transforma desenvolvedores em macacos de código de qualidade desconhecida não é o que estou procurando. Quero uma ferramenta que ajude desenvolvedores a encontrar bugs ou falhas de design no que estão fazendo, ou que os ajude a escrever testes bem projetados
Contar apenas o número de PRs não diz nada de útil. Pelo contrário, mexe com a minha intuição de que mais código por unidade de tempo reduz a qualidade média
Copilot: “Claro, faço isso! Aqui estão os novos commits!”
Desenvolvedor sênior: “Por quê? A alteração é atômica. Se a gerência voltar com métricas idiotas como número mensal de mudanças, eu direi educadamente para eles irem se catar”
Isto provavelmente era o Copilot baseado no GPT-3.5
Microsoft: setembro de 2022 a 3 de maio de 2023
Accenture: julho de 2023 a dezembro de 2023
Empresa anônima: outubro de 2023 a ?
A atualização do Copilot Chat para GPT-4 foi em 30 de novembro de 2023: https://github.blog/changelog/label/copilot/
Para mim, a IA trouxe a documentação de volta à vida. Os frameworks novos têm documentação insuficiente demais. A última documentação boa para mim foram os livros de DOS. Acho que os desenvolvedores de hoje nem devem ter noção do que é uma boa documentação
Ainda assim, como a IA pode dar sugestões diferentes a cada vez, o julgamento ainda precisa ficar com um desenvolvedor experiente. No fim, a IA substitui a documentação e a digitação
Se for um projeto público, a documentação passou a fazer parte dos dados de treinamento dos LLMs, então é muito mais importante que ela seja completa e precisa. Porque muitos desenvolvedores vão obter respostas a partir desse sistema
Se for um projeto privado, é possível obter o mesmo efeito colocando a documentação em um dataset de fine-tuning ou em um sistema de RAG
Isso talvez explique por que nada é documentado
Então, na prática, isso também tem o efeito de forçar o desenvolvedor a documentar melhor o código
Não precisa ser necessariamente uma documentação moderna e viva; qualquer coisa serve. Quero ver o que era tão excelente no passado e que perdemos, e tentar incorporar parte disso à minha própria documentação