Uma publicação no GitHub Blog discute cinco hipóteses populares sobre o uso da inteligência artificial no desenvolvimento de software, entre elas a ideia de que o código gerado não precisa ser lido, de que o RAG chegou ao fim e de que as Skills eliminaram o Model Context Protocol (MCP). O autor considera que o valor dessas afirmações não está na sua validade em forma resumida, mas na decomposição de suas condições e limites quando aplicadas ao trabalho real.
A responsabilidade pelo código não é transferida para o modelo
A regra básica apresentada pelo artigo é que o desenvolvedor deve revisar o código até o ponto em que consiga explicar o resultado e assumir a responsabilidade por ele. Isso não significa examinar cada linha com a mesma profundidade; uma alteração em um sistema de autenticação em produção merece uma revisão diferente da de um experimento simples em CSS.
A revisão pode começar antes que o agente escreva qualquer código, por meio da compreensão da implementação atual, da identificação das dependências e dos casos extremos e da elaboração de um plano. Em outras situações, o código resultante precisa de uma auditoria direta no tratamento de erros, nas permissões, no acesso a dados, no desempenho, na acessibilidade e nos testes. Segundo o artigo, a inteligência artificial muda o lugar onde o esforço é empregado, mas não elimina o trabalho em si.
A habilidade mais importante é o bom julgamento
A publicação rejeita a ideia de que as empresas não contratarão pessoas que não usem inteligência artificial de forma alguma, mas reconhece que um número crescente de equipes pergunta aos candidatos como eles usam essas ferramentas. O sinal mais forte, segundo a proposta, não é o entusiasmo pela ferramenta em si, mas a capacidade de explicar quando o desenvolvedor a utiliza e quando trabalha manualmente, como revisa seus resultados e como equilibra velocidade, qualidade, segurança e capacidade de manutenção.
Evitar a inteligência artificial pode se tornar um obstáculo em uma empresa que desenvolve seus produtos ou depende intensamente dela, mas depender completamente dela não é uma solução melhor. O necessário é manter o ser humano no circuito e ter uma explicação clara do que o desenvolvedor considera confiável e do que não considera.
MCP, Skills e RAG desempenham papéis complementares
O artigo apresenta uma distinção entre as três ferramentas. O MCP oferece uma forma padronizada para que os agentes acessem e invoquem ferramentas e dados, enquanto as Skills fornecem conhecimento empacotado sobre a forma de trabalho da equipe, as regras para modificar o projeto ou as convenções adotadas. Como as Skills geralmente são escritas em Markdown, sua legibilidade para humanos faz parte de sua utilidade.
Já o RAG, ou geração aumentada por recuperação, traz para o sistema informações relevantes externas aos dados de treinamento do modelo, como documentação, histórico de suporte, detalhes de produtos, conhecimento interno e contexto da base de código. Uma boa recuperação ajuda o modelo a começar o trabalho a partir de um contexto mais próximo da resposta, reduzindo o espaço de busca e a probabilidade de fornecer uma resposta incompleta.
Por isso, o autor não considera que as Skills tenham matado o MCP ou que o RAG esteja morto; o agente pode usar o MCP para acessar uma ferramenta, seguir uma Skill para aplicar instruções específicas do projeto e recorrer à recuperação para obter o contexto de apoio. O conflito entre esses componentes ignora a maneira como eles podem se integrar em um único fluxo de trabalho.
A capacidade de manutenção sob um novo teste
A publicação também discute a ideia de que a necessidade de treinar o modelo em uma base de código específica significa necessariamente que o código é ruim. Existem razões legítimas para o treinamento personalizado, mas a incapacidade do modelo de compreender a base de código pode revelar um problema que um novo colega também enfrentaria.
Uma estrutura clara, nomenclatura consistente, testes legíveis, abstrações úteis e documentação atualizada tornam o código mais fácil de entender tanto para agentes quanto para humanos. A leitura editorial aqui é que as ferramentas de inteligência artificial não isentam as equipes das práticas de engenharia de software; elas podem, na verdade, tornar mais visíveis as deficiências de capacidade de manutenção.
Da discussão à experimentação
O artigo termina defendendo que as opiniões sejam testadas na prática, em vez de cada opinião ser substituída por uma opinião contrária. Ele cita o projeto Pollinations AI, no qual os contribuidores podem ganhar créditos chamados pollen ao melhorar o projeto, e o projeto Avian Visitors, que documenta uma tela de tinta eletrônica que escuta os pássaros e transforma suas visitas em quadros variáveis usando um microfone, um Raspberry Pi, componentes impressos em 3D e imagens geradas.
Esses projetos não resolvem todos os debates sobre inteligência artificial, mas produzem evidências e revelam os compromissos envolvidos. A principal limitação do material é que ele apresenta um quadro geral de orientação e exemplos, não resultados de medições comparativas que comprovem a superioridade de um fluxo de trabalho específico. Portanto, suas recomendações devem ser tratadas como pontos de teste para a prática, não como regras definitivas.