12 postagens marcadas com "GitHub Copilot"

Um amigo meu cancelou sua assinatura do Visual Studio Enterprise em janeiro. Ele tinha usado por anos, construiu múltiplos sistemas .NET de produção nele, e genuinamente valorizava as ferramentas. Mas ele tinha passado os últimos seis meses fazendo quase toda a sua programação dentro do VS Code com GitHub Copilot Agent Mode, e não conseguia justificar a renovação.

Três semanas depois, um serviço em segundo plano em produção começou a vazar memória. Ele tentou tudo na sua configuração do VS Code: logging, analisadores de diagnóstico, dumps de heap pela CLI. Nada dava uma imagem clara. Ele reinstalou sua licença Enterprise, abriu o Performance Profiler com .NET Object Allocation Tracking, identificou o vazamento em vinte minutos e corrigiu em dez. Depois voltou ao VS Code para todo o resto.

Essa história é a versão honesta da questão sobre IDEs em 2026. Não se os IDEs completos estão mortos, nem se continuam sendo o padrão. A pergunta real é mais precisa: para quais funções, quais tarefas e quais bases de código eles ainda fornecem capacidades que editores potencializados por IA não conseguem replicar? E quando você olha o panorama completo, incluindo o que vem junto com uma assinatura do Visual Studio além do IDE em si, a análise é mais matizada do que qualquer lado do debate costuma admitir.

Imagine o seguinte. Um agente de codificação do GitHub Copilot pega uma issue, cria uma branch, escreve a implementação em quatro arquivos, adiciona testes e abre um pull request. O CI passa. O escaneamento de código não reporta alertas. Um desenvolvedor revisa o diff, aprova e faz merge. A mudança vai para produção através de um pipeline de implantação automatizado.

Três semanas depois, um teste de penetração descobre que o código gerado pelo agente introduziu uma vulnerabilidade de falsificação de requisição do lado do servidor. O código era sintaticamente limpo, os testes cobriam o caminho feliz, e o revisor não detectou a falha porque a lógica parecia razoável isoladamente. Agora a equipe precisa responder uma pergunta para a qual seu modelo de segurança nunca foi projetado: quem é responsável pelo código que nenhum humano escreveu?

Existe uma contradição com a qual me deparo continuamente. Cada pesquisa em ciência cognitiva que li diz a mesma coisa: concentre-se em uma tarefa de cada vez. A multitarefa é um mito. Seu cérebro não consegue fazer duas coisas exigentes simultaneamente sem pagar um alto custo de desempenho.

E, no entanto, todos os dias me encontro revisando um pull request que o agente na nuvem do GitHub Copilot abriu, enquanto um pipeline de CI/CD roda em uma segunda branch com código gerado por IA. Mais fluxos de trabalho em paralelo do que jamais gerenciei antes da IA entrar no meu fluxo de trabalho, e de alguma forma parece menos caótico do que antes.

Algo não bate. Ou a ciência está errada, ou o que estou fazendo não é realmente multitarefa. Acho que é o segundo, e a distinção importa para todo engenheiro que se adapta a fluxos de trabalho agênticos.

A definição funcionava. Até que um quarto participante apareceu.​

DevOps sempre foi definido por uma equação simples e poderosa: Pessoas + Processos + Ferramentas. Essa fórmula capturou algo essencial sobre como o software moderno é construído e entregue. Ela derrubou barreiras entre desenvolvimento e operações. Deu às organizações um modelo mental para diagnosticar o que estava errado quando as coisas andavam devagar demais, falhavam com frequência demais ou criavam atrito demais.

Por mais de uma década, esse modelo de três pilares serviu bem à indústria. E o fez porque se apoiava em uma suposição que ninguém questionava: todo participante no ciclo de vida de entrega de software era humano.

Essa suposição não se sustenta mais.

O Problema de Fragmentação do Qual Ninguém Fala​

Os agentes de codificação com IA não são mais experimentais. As equipes estão usando GitHub Copilot, Claude Code, Cursor e outras ferramentas para gerar código, abrir pull requests, revisar mudanças e automatizar tarefas de engenharia de múltiplas etapas. Os resultados são impressionantes, mas um problema mais silencioso está crescendo por baixo dos ganhos de produtividade.

Cada desenvolvedor na equipe configura seus agentes de IA de maneira diferente.

Quando as Métricas Tradicionais Param de Funcionar​

O desenvolvimento assistido por IA não é mais um experimento. Faz parte do trabalho diário de engenharia em organizações de todos os tamanhos. Ferramentas alimentadas por modelos de linguagem grandes geram código, propõem refatorações, escrevem testes, resumem pull requests e coordenam tarefas de engenharia de múltiplas etapas.

Isso cria um desafio fascinante e desconfortável: a produtividade claramente está melhorando, mas tornou-se muito mais difícil medi-la com precisão.

Como os Grandes Engenheiros se Comunicam com a IA na Era Agêntica​

A IA mudou como escrevemos software. Mas, mais importante, ela mudou como comunicamos intenção.

As primeiras conversas sobre desenvolvimento assistido por IA focaram fortemente na engenharia de prompts. Desenvolvedores experimentaram com truques de redação, estilos de formatação e instruções criativas para extrair melhores resultados dos modelos de linguagem. Comunidades inteiras se formaram ao redor do "prompt perfeito."

Essa fase foi útil, mas nunca foi o destino.

Seu Repositório É Agora Sua Interface Mais Importante​

O papel do engenheiro de software está evoluindo rapidamente, não porque a IA pode gerar código, mas porque o desenvolvimento de software em si está se tornando um sistema colaborativo humano-agente.

Nos últimos anos, passamos da IA auxiliando com trechos de código, para gerar funções inteiras, para propor pull requests, e agora para agentes que navegam repositórios, raciocinam sobre arquitetura e executam tarefas de desenvolvimento de múltiplas etapas de forma autônoma.

A Colaboração Já Está Acontecendo — A Questão É Se Está Estruturada​

Se as bases de DevOps preparam o sistema e a evolução do Engenheiro de Software redefine o papel, a próxima pergunta lógica é:

Como humanos e agentes realmente colaboram na prática?

Não na teoria. Não em demos. Não em vídeos de marketing.

Mas em repositórios reais, IDEs reais, pull requests reais e sistemas de produção reais.

Escrever Código Nunca Foi o Trabalho — Entregar Resultados Sim​

Durante décadas, o papel do Engenheiro de Software evoluiu ao lado de ferramentas, plataformas e abstrações. Da programação de sistemas de baixo nível aos frameworks de alto nível, de waterfall a agile, de on-prem à nuvem, cada mudança transformou como o software é construído, mas não quem o constrói em última instância.

A ascensão do desenvolvimento assistido por IA e mais recentemente, a engenharia de software agêntica representa um tipo fundamentalmente diferente de mudança. Os engenheiros de software não são mais os únicos produtores de código. Eles estão cada vez mais se tornando designers de sistemas que produzem código, operadores de colaboradores autônomos e guardiões da qualidade, segurança e intenção.