O blog do GitHub publicou em 18 de setembro de 2026 uma análise assinada por GPS sobre o episódio mais recente do GitHub Podcast. O texto parte de cinco "hot takes", frases curtas e confiantes que circulam sobre inteligência artificial, para mostrar que o valor dessas afirmações não está na reação imediata, mas nas perguntas que elas levantam.
Segundo o autor, um bom hot take serve para ser desmontado. Em que condições ele é verdadeiro, qual contexto falta, que premissas ele carrega e o que muda quando é aplicado ao trabalho real.
Código gerado por IA continua sendo responsabilidade de quem assina
A primeira afirmação analisada é a de que não seria necessário ler código gerado por IA. A resposta do post é direta: sim, é necessário, porque a responsabilidade continua sendo de quem entrega o código.
O que muda é a distribuição da atenção. Uma refatoração de autenticação em produção merece um processo de revisão diferente de um experimento de CSS.
Um repositório mantido por dez anos desperta instintos distintos de um aberto naquela manhã.
Tratar toda alteração como se tivesse o mesmo risco não é rigor, e sim mau uso do tempo. A regra sugerida é revisar até conseguir explicar e assumir o resultado.
Em alguns casos, o trabalho começa antes de o agente escrever qualquer linha: ler a implementação atual, mapear dependências, identificar casos de borda e montar um plano. Em outros, a atenção vai quase toda para o código produzido: tratamento de erros, permissões, acesso a dados, desempenho, acessibilidade e testes.
A IA desloca o esforço, não o elimina. A habilidade real está em saber onde mora o risco.
Contratação: julgamento pesa mais que entusiasmo
Sobre a ideia de que empresas não contratariam quem não usa IA, o texto enxerga mais nuance. Cada vez mais times perguntam aos candidatos como eles usam IA, o que faz sentido diante da presença dessas ferramentas no desenvolvimento de software.
Ainda assim, ninguém espera que todo desenvolvedor adote o mesmo fluxo de trabalho, as mesmas ferramentas ou o mesmo nível de empolgação. O sinal mais forte, segundo o autor, é o julgamento.
Saber explicar quando usa IA e quando trabalha manualmente, descrever como revisa código gerado e falar com honestidade sobre velocidade, qualidade, segurança e manutenibilidade. Dependência total e recusa total raramente são boas respostas.
O que se valoriza é a clareza sobre o próprio processo e sobre onde o profissional mantém o controle.
Skills, mcp e rag: ferramentas complementares, não rivais
A terceira afirmação, "Skills matou o MCP", é rejeitada. O Model Context Protocol oferece aos agentes uma forma padronizada de se conectar a ferramentas e dados, o que importa quando se quer que sistemas funcionem juntos de maneira confiável.
Já as Skills funcionam como conhecimento empacotado: explicam como um time trabalha, como um projeto deve ser alterado, como usar uma ferramenta ou quais convenções importam. Como costumam ser escritas em Markdown, podem ser lidas por pessoas, e essa legibilidade é parte do valor.
Na prática, o MCP fornece acesso e as Skills explicam como usar esse acesso bem. O autor recomenda padrões para interfaces compartilhadas e skills para contexto, processo e boas práticas.
A combinação seria mais interessante do que a disputa.
O mesmo raciocínio vale para o quarto hot take, de que RAG estaria morto. A geração aumentada por recuperação segue relevante porque entrega ao modelo informações que não estão no treinamento, como documentação, histórico de suporte, detalhes de produto, conhecimento interno e contexto de código.
Sem boa recuperação, o modelo depende apenas do que já sabe ou gasta tempo extra procurando contexto. Isso consome tokens, atrasa o trabalho e favorece respostas incompletas.
Agentes, skills, MCP e RAG podem coexistir no mesmo fluxo.
Manutenção como teste de pressão
O quinto hot take afirma que precisar de fine-tuning para o próprio código significa que o código é ruim. O texto reconhece que existem motivos válidos para ajustar um modelo, mas lembra que modelos modernos já viram uma enorme variedade de frameworks, padrões, convenções de nomes e arquiteturas.
Se o modelo não consegue entender o repositório, há boa chance de uma pessoa recém-chegada também ter dificuldade. Nessa leitura, a IA vira mais um teste de pressão para a manutenibilidade, ao lado de revisão de código, testes, onboarding e da pessoa que vai depurar aquele trecho seis meses depois.
Estrutura clara, nomes consistentes, testes legíveis, abstrações úteis e documentação atualizada ajudam o agente. Mas, sobretudo, ajudam humanos.
Fontes e links
- GitHub Blog — Should you read the code, is RAG dead, and did Skills kill MCP?
- GitHub Podcast
- Perfil do autor GPS no GitHub Blog
