Me preocupo que nosso Copilot esteja deixando alguns passageiros para trás
GitHub Copilot e assistentes de codificação por IA semelhantes são elogiados por alguns engenheiros experientes como ferramentas de autocomplete poderosas, mas criticados por outros por encorajar código inchado, inacessível ou sutilmente incorreto que os colegas depois precisam desembaraçar. Os comentaristas temem que a dependência excessiva de código gerado por LLM, especialmente por desenvolvedores menos experientes e em áreas como segurança e acessibilidade, acelere um declínio de longa data na qualidade de software e aprofunde as pressões de “enshittification”. Muitos argumentam que essas ferramentas são melhores quando usadas com testes fortes, revisões e normas claras: tratá-las como colaboradores juniores ou tradutores, não como substitutas de entendimento, design e manutenibilidade de longo prazo.
Normas da equipe e uso indevido de ferramentas de geração de código
- Vários descrevem colegas que colam mudanças grandes, geradas por LLM, com código irrelevante, não conseguem explicá-las e esperam que os colegas depurem e corrijam o estilo.
- Muitos argumentam que isso deve ser tratado como qualquer outra má engenharia: rejeitar PRs, exigir explicações, exigir conformidade com as normas da base de código; alguns acham que terceirizar habitualmente o raciocínio é motivo para demissão.
- Há preocupação de que “desenvolvedores de LLM” transfiram o esforço do autor para os revisores, o que é visto como desrespeitoso.
Onde o Copilot ajuda vs. atrapalha
- É visto como mais útil para: boilerplate, estruturas repetitivas, traduções entre formatos (por exemplo, JSON → tipos), consultas rápidas de documentação, scaffolding de testes e depuração estilo “rubber duck”.
- Alguns o deixam desligado por padrão e só o habilitam quando sabem exatamente o que querem.
- Outros relatam que ele piorou ou ficou inconsistente, muitas vezes retornando palpites com pouco contexto ou nenhuma solução.
- Padrões de uso eficazes: tratá-lo como autocomplete poderoso, parear com ele como se fosse um dev muito júnior, aceitar apenas o que você já pretendia.
Qualidade de código, acessibilidade e segurança
- Muitos concordam que o Copilot espelha a qualidade (muitas vezes ruim) do código público: HTML em div-soup, acessibilidade fraca, Bash ruim etc.
- Há receio de que código gerado por LLM normalize más práticas (acessibilidade, segurança, internacionalização) que “parecem funcionar” e, assim, sejam lançadas sem serem percebidas.
- Alguns acham que esses problemas podem ser mitigados com dados de treinamento melhores e integrando linters, verificadores de acessibilidade e testes no ciclo de geração.
Aprendizado, contratação e dependência excessiva
- A ferramenta é considerada um impulso para especialistas (que conseguem identificar erros) e uma armadilha para iniciantes (que não conseguem).
- Há preocupação de que juniores terceirizem o pensamento, aprendam padrões errados e nunca construam fundamentos.
- Contratação: entrevistadores veem candidatos usando IA secretamente em testes remotos; contramedidas incluem compartilhamento de tela em tela cheia, tarefas apenas em pseudocódigo ou foco no raciocínio em vez de codificação mecânica.
Indústria mais ampla e direções futuras
- Vários associam LLMs à “enshittification”: eles podem acelerar incentivos que já são ruins (ir rápido, nunca limpar, aceitar UX/desempenho medíocres).
- Outros argumentam que aplicativos ruins são impulsionados por mercados, não por ferramentas; LLMs podem até ajudar pequenas equipes a competir com sistemas ruins e entrincheirados.
- Alguns imaginam fluxos de trabalho mais ricos: modelos específicos da organização, geração limitada por compiladores/gramáticas, sugestões de refatoração e geração em múltiplas passagens validada por testes e linters.