- Com o GitHub e a Microsoft anunciando a prévia pública do GitHub Copilot Agent, testes estão sendo conduzidos no repositório do .NET Runtime em que esse agente gera PRs automaticamente
- Porém, esses PRs incluem alterações fracas ou desnecessárias, fazendo os revisores passarem sufoco, e usuários do Reddit estão tratando isso como uma cena trágica e cômica ao mesmo tempo
- Exemplos de PRs:
- PR #115762 – adiciona outra checagem desnecessária em código onde a verificação de null já havia sido feita em uma chamada de
string.Concat - PR #115743 – propõe um refatoramento de condicional sem efeito algum
- PR #115733, PR #115732 etc. seguem uma linha parecida
- PR #115762 – adiciona outra checagem desnecessária em código onde a verificação de null já havia sido feita em uma chamada de
- O autor diz que, “se esse é o futuro do setor, eu estou pronto para descer”, expondo seu cansaço e ceticismo com a adoção de IA
- Mas ao mesmo tempo ele enfatiza que “sente compaixão pelos funcionários encarregados das revisões”, acrescentando que essa situação provavelmente é o peso de uma diretriz de adoção do Copilot vinda de cima
Meu “schadenfreude (prazer)” é direcionado aos executivos da Microsoft que alimentam o hype da IA. Por favor, respeitem os desenvolvedores.
- schadenfreude é uma palavra de origem alemã que, em tradução literal, significa “alegria vinda do dano”. Ou seja, “a sensação secretamente prazerosa diante do azar alheio”
Resumo dos principais comentários
1. PRs escritos por IA são imprecisos e apenas repetem 'chutes' sem entender o contexto
- Propõem mudanças sem entender o que o código do PR realmente faz
- Corrige erro repetidamente → o código continua errado → corrige outro erro… num loop sem fim
- Teve até quem dissesse que o processo “corrigi” → “ainda está errado” → “agora sim corrigi de verdade” parece um padrão de dev júnior
2. Resolver problemas complexos acaba consumindo ainda mais tempo
- Ajuda em correções simples, mas não serve para os problemas complexos em que você realmente quer economizar tempo
- Entender o problema → entender o Copilot → comparar → verificar → fazer ajustes manuais
- Na prática, é mais rápido eu mesmo resolver
3. O 'AI solves everything' dos líderes corporativos está afastando os desenvolvedores
- A mensagem de que “usar Copilot evita que você fique para trás” está descolada da realidade dos devs que trabalham de verdade
- O tempo gasto revisando PRs aumenta, e a responsabilidade é empurrada para os desenvolvedores
- Há preocupação com um 'loop de treino de IA para IA', em que IAs treinadas com código gerado pelo Copilot pioram ainda mais a qualidade do código
4. A IA só entrega respostas erradas com confiança; não tem convicção de que 'isso está certo'
- Mesmo após receber feedback de que está errado, responde “corrigi!” → e propõe alterações ainda mais estranhas
- Não faz o julgamento de “isso já é um código aceitável, não precisa mexer”
- Também há quem aponte que isso pode ser um design pensado para evitar responsabilidade legal
5. A pressão contínua para adotar IA está desgastando a experiência dos desenvolvedores
- Experimentos de adoção de IA continuam por causa de ordens da gerência ou metas de desempenho
- Desenvolvedores relatam o cansaço de sentir que viraram babás da IA
- Há também a visão pessimista de que, se isso continuar, “os desenvolvedores vão se cansar da IA e sair do setor”
Frases de destaque
- “A IA parece um estagiário que fica repetindo palpites errados, mas com plena confiança no que está dizendo”
- “Em vez de perder tempo revisando código do Copilot, é melhor eu escrever tudo de novo”
- “Isso é um estado de 'reverse centaurs', em que o desenvolvedor ajuda a máquina”
- Termo usado por Cory Doctorow para dizer que “não somos humanos recebendo ajuda das máquinas, mas humanos sendo forçados a ajudar as máquinas”
- “O Copilot é como quando um desenvolvedor aplica um remendo improvisado ruim, só que automatizado, então isso vira milhares de remendos incômodos”
- “LLMs parecem ter como padrão ‘posso estar errado, mas não estou em dúvida’”
12 comentários
A produtividade aumentou bastante com um fluxo de trabalho assíncrono em que você joga o problema e, se a resposta estiver errada, descarta, mas isso não é parecido com uma ferramenta estática? Se você pensar nisso como uma ferramenta de análise estática extremamente evoluída, é uma boa companheira. Sinceramente, a análise também é rápida e sabe mais do que um engenheiro júnior.
Eu uso IA, mas ela é burra, então se você não conseguir corrigir o que ela faz, não consegue implementar direito. Quando vejo esse tal de vibe coding, é tudo código cheio de erros...
Sempre passo por isso quando uso LLM. Nas partes que ele não consegue fazer, por mais que você aponte infinitamente, ele continua sem conseguir.
No fim, você se cansa e acaba analisando e corrigindo por conta própria. Quando esse tipo de experiência se acumula, dá vontade de achar que LLM e tudo mais é simplesmente lixo e de não usar mais.
Isso me faz lembrar um webtoon em que a IA faz reverse prompting para que os humanos programem.
https://comic.naver.com/bestChallenge/detail?titleId=818158&no=21
Parece que isso vai continuar acontecendo, a menos que a IA realmente passe a resolver problemas e aprender ao mesmo tempo como uma pessoa.
Desde que você cumpra bem os prazos e os requisitos, na hora de programar não importa tanto se usou IA ou se, de forma machona, nem usou IDE e escreveu tudo só no Bloco de Notas.
Quando eu achava que isso era só uma nova tecnologia, eu olhava com curiosidade,
mas agora que os empregadores estão de fato promovendo cortes de contratação e de salários por causa desse tipo de tecnologia, isso já não me faz sentir muito bem..
Acho que, como ainda estamos em uma fase de transição, várias situações inusitadas acabam acontecendo.
Daqui para frente pode melhorar ainda mais, ou continuar assim, então também vai ser divertido ver como isso muda kkk
Estou usando o Gemini no GitHub para receber revisão de PR, e às vezes acontece exatamente isso.
Tipo quando eu já fiz a checagem de
nullna linha logo acima, mas ele revisa dizendo para adicionar exatamente a mesma linha logo acima porque eu estaria usando sem checarnull.Não dá para colocar tudo em prompts — o conhecimento de contexto, os padrões de trabalho, os resultados esperados e seus formatos, que uma pessoa naturalmente aprende ao trabalhar.
E, mesmo que desse para escrever tudo isso, também fico pensando que, em vez de um AI complexo como um LLM, talvez fosse mais realista automatizar isso com algoritmos tradicionais de antes do deep learning.
Quando você usa, dá para ver que vibe coding e agentes de código realmente têm seus lados convenientes, mas para serem convenientes de verdade é preciso enviar prompts extremamente detalhistas, e, desde o início, também há muitos projetos que simplesmente não funcionam bem dependendo do perfil do projeto. Quando as funcionalidades estão bem divididas em partes pequenas e objetivas, como em um servidor web com arquitetura MSA, eles trabalham bem; mas, se você tentar corrigir com IA uma lógica complexa com muitos módulos interligados em um grande monólito, precisa montar um plano de tarefas extremamente minucioso e enviar prompts muito bem elaborados.
Opinião no Hacker News
Compartilhando o fascínio da situação em que todos os comentários vêm com a mensagem "Help improve Copilot by leaving feedback using the or buttons", mas na prática nunca se viu nenhum feedback de fato anexado; relato de que esse tipo de coisa acontece com frequência ao usar LLMs quando a configuração do system prompt não está bem feita; o exemplo de PR mais engraçado é quando, para "corrigir" a falha nos testes, ele simplesmente apaga ou comenta os casos de teste, ou então só troca a
assertion; a suposição é que os modelos da Google e da Microsoft parecem mostrar esse tipo de comportamento com mais frequência do que os da OpenAI e da Anthropic, e que as diferenças nos processos internos de cada empresa parecem aparecer no resultado; apresentação do processo em que, num PR real, uma pessoa aponta o problema mais três vezes e depois desiste; é difícil até imaginar o estado de espírito de quem revisa esses PRs, parece lidar com um desenvolvedor júnior que não escuta, mas que na verdade é uma entidade sem qualquer compreensão de contexto; exemplo de um PR específico em que 90% do conteúdo é "Check failure", dificultando até verificar o código/o diff, e a tristeza de um teste unitário descrito apenas como "Test expressions mentioned in the issue"; opinião sincera de que, se essa situação não fosse tão dolorosa para os humanos, seria realmente muito engraçadaA comparação com desenvolvedor júnior é exagerada demais; eu também trabalho com juniores, mas eles não cometem erros estranhos com tanta frequência quanto um LLM, não exigem tanto trabalho extra e aprendem rápido; LLM é uma ferramenta auxiliar razoável se usada com cuidado, ajuda a ganhar velocidade e também serve bem como parceira de brainstorming, mas não pode substituir estagiários nem desenvolvedores de verdade
Quando entrei em engenharia de software no fim dos anos 80, havia diversão nisso, mas hoje o ambiente mudou para algo tóxico, com processos de entrevista, pequenas e médias empresas imitando big tech e agora esse experimento de PRs com IA; um sentimento de ceticismo sobre se ainda resta alegria no trabalho de ser desenvolvedor profissional nos dias de hoje
Pelo menos para um desenvolvedor júnior dá para dizer que rode os testes localmente antes de enviar o PR; há preocupação de que, em algum momento, os desenvolvedores humanos simplesmente desistam, fechem os PRs de "lixo de IA" e joguem tudo fora, deixando só o que funciona; a sensação de que, depois de aguentar continuamente os experimentos da máquina, chegará um dia em que todos estarão tão exaustos que simplesmente vão parar
Dúvida sobre a necessidade de um sistema de feedback explícito; do ponto de vista de desenvolvimento, sucesso é um PR aprovado no primeiro envio, e fracasso pode ser entendido como a deterioração acumulada no número de correções solicitadas ao agente; exigir feedback manual é ineficiente, e seria melhor medir desempenho por métricas como cycle time, taxa de aprovação e change failure rate, do mesmo jeito que com desenvolvedores
Relato da experiência de conversar com o suporte da Microsoft e sentir como se estivesse falando com uma parede; mesmo abrindo vários casos, nunca houve uma resolução satisfatória; dá para entender a Microsoft usar a própria tecnologia, mas o pedido é que ela não force isso nos outros; opinião de que a Microsoft não deveria lançar produtos que não estão prontos para suporte
Experiência recente de assistir a um vídeo em que Eric, do Google, fala sobre IA; ele argumenta que a IA está subestimada no momento; citação de sua fala ao enfatizar que "não é especialista" ao falar do motivo de ter comprado uma empresa de foguetes e de desafiar áreas fora da própria especialidade com IA, como Deep Research; eu também não odeio IA, mas a IA generativa atual, baseada em restauração de padrões da geração presente, é muito boa em provocar o "encantamento do iniciante"; se você não conhece a área, o resultado parece incrível, mas, quando passa a entender mais profundamente, a decepção com as falhas vem rápido; quem trabalha na linha de frente, como na Microsoft, vê claramente qual é o problema, mas a liderança executiva, especialmente figuras como Eric, tem a fraqueza de se deixar enganar facilmente quando a IA só fala de forma espalhafatosa; ainda existe a expectativa de que um dia a IA consiga escrever código que funcione de verdade de forma direta, mas a visão é de que isso ainda está longe
Minha forma de usar IA é com muito cuidado e de modo bastante limitado; já esses bilionários do tipo "comprei uma empresa de foguetes" ficam empolgados com IA e a usam até em decisões de investimento para continuar aumentando a própria fortuna; mesmo que sofram um grande fracasso, o que perdem é só no nível de alguns acessórios, sem grande impacto na sua posição social; enquanto isso, os empregos de TI na linha de frente parecem ameaçados por resultados ruins em ambos os lados
Junto da situação em que líderes que não são especialistas se impressionam facilmente com IA, imaginar o que aconteceria se o Google colaborasse com o exército dos EUA e colocasse Gemini em drones autônomos em larga escala
Fica a dúvida sobre que confiança isso passa para empresas que construíram produtos sobre .NET, ao ver funcionários da Microsoft passarem horas discutindo com LLMs em vez de resolver problemas reais
Antes mesmo da adoção de LLMs, já se via no GitHub Issues usuários incapazes de explicar bem o problema e mantenedores cada vez mais irritados; agora nem é mais preciso ter o usuário final irritado
Na verdade, esse resultado é o desfecho natural de uma gestão ruim e de instruções mal feitas; desta vez já não dá mais para culpar um júnior, só a si mesmos
Ênfase na dor de ver até Stephen Toub, conhecido especialmente pelo famoso blog de performance de .net, participando desse processo
Não se quer impedir que experimentem essas novas tecnologias, a diferença é apenas que agora o experimento está exposto publicamente para todo mundo
Afirmação cínica de que a Microsoft sempre teve uma cultura de, quando surge um problema, empurrar com "é só ignorar o erro" e marcar como Will Not Fix, alimentando a autossatisfação dos gerentes, então no fim provocou tudo o que está acontecendo agora
Explicação do contexto a partir do comentário deixado no primeiro PR: estão se preparando para o futuro ao descobrir os limites da ferramenta por meio de vários experimentos, e a responsabilidade pelo merge continua com o mantenedor, como em qualquer PR; nada será mesclado antes de cumprir os padrões de qualidade
O funcionário da Microsoft que escreveu esse comentário também disse que quem não pensar em usar IA vai ficar para trás; a atmosfera na Microsoft é de ansiedade/empolgação com a ideia de que a IA vai virar a engenharia de software de cabeça para baixo; isso parece menos um esforço para entender os limites da ferramenta e mais uma adesão apressada para proteger o próprio emprego, o que acaba reduzindo ainda mais a confiança
É preciso entender que os gerentes ainda não chegaram a uma conclusão definitiva sobre as capacidades do modelo, e que se trata de um experimento racional para identificar pontos fortes e fracos em contexto de mundo real
Já é estranho por si só atribuir um PR que nem passou no CI a alguém; o normal seria no mínimo só atribuir PRs aprovados, e a sensação é de que o sistema está tão bagunçado que nem isso consegue fazer; cinismo de que, se estivesse funcionando direito, esse nível básico deveria ser possível
Espera-se que nem tudo seja interpretado sempre pelo pior cenário possível; na prática, os humanos envolvidos provavelmente sabem que é um experimento e já ajustaram suas expectativas; sem esse tipo de abordagem experimental, é difícil fazer o sistema evoluir, então pode ser que estejam apenas ajustando e testando em ambiente real; na minha empresa também fizemos exatamente o mesmo experimento no começo da adoção de ferramentas de apoio de IA para programação, e a qualidade do código foi pior do que quando humanos codificavam diretamente, mas aprendemos muito com o processo; com uma linha de base, ficou claro acompanhar a evolução das melhorias
Houve explicação nos comentários de que, por causa de um problema de firewall, não estavam conseguindo verificar se os testes passavam, e que, resolvendo só isso, o funcionamento normal seria possível
Mesmo que se substitua agentes de IA por outra nova tecnologia, isso ainda parece o retrato típico de uma empresa assim: experimentação aberta (
dogfoodingno estilo big tech), contribuição real para o avanço técnico do setor e, se der problema, o dano fica totalmente limitado à equipe interna; coloca-se a pergunta sobre por que exatamente não apoiar esse tipo de experimentoEstranhamento com o clima em que todos só despejam críticas sobre esse tipo de experimento aberto; em vez de esconder em um fork privado, é muito mais útil expor de forma transparente a capacidade real, e isso parece melhor do que fanfarronice de vendas e marketing
Há controvérsia em fazer esse tipo de experimento numa infraestrutura central de frameworks de desenvolvimento de software
Dúvida sobre por que, como e o que exatamente "nós" deveríamos apoiar ou deixar de apoiar; pessoalmente, ver a MS fracassar de forma espalhafatosa é simplesmente engraçado
Crítica de que é difícil chamar isso de verdadeiro "progresso"; expor problemas do sistema para fora sem um POC interno prévio foi, na verdade, irresponsável; questiona-se por que não validaram antes o ambiente básico, como firewall, ou por que não tentaram primeiro em outros codebases internos; código de infraestrutura exige padrões mais altos, e mesmo sob a justificativa de
dogfooding, o certo seria começar por projetos de menor importância; crítica de que isso nem sequer éstate of the art; cinismo de que o resultado é tosco demais para o custo investidoÉ problemático fazer esse tipo de experimento num projeto popular do qual inúmeros desenvolvedores dependem; há receio de queda de qualidade por causa de código ruim gerado por IA, de acúmulo de código inútil ou de só corroer a produtividade da equipe
Se a ideia fosse obediência passiva a alguma coisa, a sugestão irônica seria simplesmente aprovar todos os pedidos sem revisão e, quando a stack tecnológica da Microsoft quebrar mundialmente, sair da empresa e virar consultor ganhando o triplo
Eu não gostaria de trabalhar com essa postura sarcástica; não entendo essa moldura hostil de "nós contra eles" em relação à liderança da empresa, nem a abordagem de sabotar de propósito; reclamar da imperfeição não combina, na minha consciência, com atrapalhar ou atacar a organização como um todo
Resposta cínica de que, na prática, a stack tecnológica da Microsoft já está quebrada(?) mesmo
Apontamento de que, na realidade, o próprio PR gerado pelo CoPilot foi enviado diretamente pela liderança
Piada de que um dia o CoPilot vai sobrescrever o codebase inteiro e, sem código, também não haverá mais falhas de teste
Opinião de que, como qualquer um pode ser alvo de layoff a qualquer momento (como no caso de quem fez o compilador de TypeScript em Go), não haveria motivo para ser leal a esse tipo de organização
Abrir PRs é pelo menos uma forma segura de experimentar, porque, se não servir, dá para descartar na hora; toda tentativa nova sempre traz tentativa e erro e fracassos, mas essa experiência em si é importante; espera-se que, ao treinar a ferramenta de forma dura em código real e problemas reais, ela possa evoluir rapidamente; por exemplo, no futuro pode haver melhorias como aprendizado iterativo até os testes passarem ou verificações para impedir a exclusão de testes; no fim, prevê-se um futuro em que tarefas repetitivas e simples do processo de desenvolvimento ficarão com a IA, enquanto os desenvolvedores poderão se concentrar no trabalho essencialmente criativo
Ainda assim, seria mais seguro fazer esse tipo de experimento em um fork privado, não num repositório público; fica a dúvida se, do ponto de vista de vendas, foi realmente uma boa decisão deixar esse caso visível; quando um tomador de decisão interno vir o CoPilot numa revista e quiser tentar a mesma coisa, esses casos reais podem servir de referência; a maioria das empresas tende a esconder ao máximo exemplos de falhas em aplicações e a mostrar só a parte mais acabada e polida
Mesmo PRs que parecem aceitáveis na superfície podem esconder problemas pouco visíveis e, por isso, ser ainda mais perigosos
Relato de que revisar código de IA pode ser ainda mais irritante do que tarefas simples e repetitivas, especialmente quando há bugs escondidos e o desenvolvedor sofre mais para encontrá-los
O simples ato de abrir PRs já adiciona carga e complexidade ao gerenciamento do projeto; experimentar em um fork separado deixaria um exemplo melhor para a comunidade; muitos projetos open source acabam abandonados porque os mantenedores se esgotam gerenciando PRs acumulados, ou então alguém faz um fork e leva só os PRs que ainda prestam; preocupa a possibilidade de esse tipo de prática aumentar ainda mais o número de projetos abandonados e forks
Se realmente se acredita que um LLM pode aprender a programar adequadamente mesmo estando cheio de bugs, então depois seria necessário montar um dataset com quase nenhum bug; na prática isso não acontece, e a realidade foi simplesmente raspar todo tipo de dado sem critério
O GitHub gastou bilhões de dólares para criar uma IA que falha com frequência até em lint de espaços em branco num dos repositórios mais maduros do mundo; como experimento de hobby, tudo bem, mas vender isso como "produto inovador" com preço real é motivo de controvérsia
Do ponto de vista de pesquisador, claro que é um experimento natural, mas o problema é a postura da empresa de vender esse estado inacabado desde já
Piada sobre o antigo CEO Nat Friedman: "ele deve ter morrido... não, ainda está vivo"
O verdadeiro problema é a falta de métricas objetivas para medir o desempenho de desenvolvedores de software; a situação fica limitada a avaliações subjetivas, como revisão de fim de ano, e é difícil saber de que lado está de fato a eficiência ou ineficiência do uso de IA; pode parecer mais barato do que um júnior, mas desperdiça tempo de sêniores e não segue instruções, e, combinado com culto ao CEO, aprofunda divergências internas na organização; a resistência dos desenvolvedores é ignorada como "medo de ser substituído", enquanto o lado do CEO maximiza os resultados políticos de empurrar a iniciativa; como não existe um padrão industrial com o qual todos concordem, a verdade não pode ser determinada; numa extrapolação extrema, a organização poderia até exigir que se baixassem os critérios de revisão para aumentar a quantidade de PRs de IA