O discurso de produtividade em torno dos assistentes de código com IA sempre foi um pouco impreciso. Linhas de código por hora, tempo para fechar um ticket, taxa de aceitação de sugestões de autocomplete: todas são métricas reais, mas descrevem um efeito superficial. Elas deixam passar a mudança mais interessante, que acontece quando um engenheiro experiente integra uma dessas ferramentas ao seu trabalho diário ao longo do tempo. A velocidade é um subproduto. A mudança mais significativa é cognitiva: o que você precisa manter na cabeça, o que pode delegar e para onde acaba indo a sua atenção como resultado.
Isso não é um argumento de que os assistentes de código com IA são transformadores num sentido que muda o que é a engenharia na sua essência. É uma observação mais concreta: os engenheiros que tiram mais proveito dessas ferramentas não são os que menos digitam. São os que aprenderam a usar o assistente para comprimir as partes de baixo valor do trabalho, de modo que as partes de alto valor recebam mais atenção de verdade. Essa é uma proposta de valor diferente da produtividade, e exige um modelo mental diferente para ser bem aproveitada.
O enfoque de carga cognitiva é mais útil do que o enfoque de velocidade
Quando você está escrevendo software não trivial, boa parte da sua memória de trabalho em qualquer momento está ocupada por coisas que não são o problema central. A sintaxe específica de uma API que você usa pouco. A estrutura de boilerplate de um arquivo de testes. A assinatura exata de uma função três arquivos adiante. O formato de mensagem de erro que o framework de logging do seu time espera. Nada disso é interessante, mas tudo ocupa espaço, e esse espaço tem um custo: atenção que poderia estar na decisão de arquitetura, no edge case, na interação que não está coberta pelo spec.
Um assistente de código com IA bem integrado lida com boa parte dessa camada inferior. Não perfeitamente, e não sem exigir atenção própria, mas o suficiente para mudar, com o tempo, a textura do trabalho. Você gasta menos da sua cognição disponível em recuperação mecânica e mais nas partes do problema que realmente exigem seu critério e contexto específico. Para engenheiros cujo trabalho principal é exatamente esse critério, a mudança se acumula.
Tudo isso só vale se a ferramenta for confiável o suficiente, no seu contexto específico, para que monitorar o output dela não custe mais atenção do que ela economiza. Um assistente que gera código plausível mas sutilmente incorreto num domínio com o qual você está menos familiarizado cria uma carga de verificação que pode facilmente superar o benefício. O enfoque de carga cognitiva funciona nas duas direções.
Como a relação com a ferramenta realmente evolui
Há uma diferença significativa entre como alguém usa um assistente de código com IA no primeiro mês e como usa depois de seis meses de trabalho constante no mesmo codebase. A fase inicial é marcada por uma experimentação hesitante: aceitar sugestões em completions simples, pedir ocasionalmente para gerar uma função a partir de um comentário, se surpreender quando funciona e desconfiar quando não funciona. A ferramenta parece uma entidade separada, que faz sugestões que você avalia à distância.
A fase posterior, quando essa relação amadurece, é diferente. O modelo mental de quando a ferramenta é confiável foi construído pela repetição. O fluxo de trabalho se adaptou para se apoiar no assistente nos cenários em que ele é consistentemente forte e para evitá-lo onde consistentemente falha. A interação deixa de ser uma avaliação de sugestões individuais e passa a se parecer mais com trabalhar ao lado de um colega cujos pontos fortes e pontos cegos você já conhece, que é mais ou menos como engenheiros experientes pensam em qualquer membro do time.
Os padrões que costumam aparecer nesse uso mais amadurecido incluem:
- Recuperação de contexto: voltar a uma parte do codebase que você não toca há meses e usar a ferramenta para reconstruir o contexto relevante mais rápido do que conseguiria lendo o código sozinho.
- Rascunho e refinamento: deixar o assistente produzir uma primeira versão de algo estruturalmente previsível e depois aplicar seu critério nas partes que exigem decisões de design de verdade.
- Rubber duck com memória: usar o chat para pensar em voz alta sobre um problema, não para obter a resposta, mas para externalizar o raciocínio e detectar brechas que não ficam visíveis quando tudo está só na sua cabeça.
- Geração dirigida em terreno desconhecido: usar o assistente para produzir algo numa biblioteca ou framework que você conhece menos, aceitando que vai precisar verificar, mas ganhando um ponto de partida que reduz o tempo até algo funcional.
Nenhum desses padrões trata a velocidade como um fim em si mesmo. Todos têm a ver com direcionar a atenção de forma mais deliberada.
O que não muda e não deveria mudar
As partes da engenharia que exigem critério contextual profundo não ficam mais fáceis só porque você tem um assistente de código com IA. Entender por que um sistema se comporta de forma inesperada em produção exige conhecer o sistema. Decidir se uma arquitetura proposta vai aguentar quando os requisitos mudarem exige experiência com arquiteturas que não aguentaram. Reconhecer que uma solução tecnicamente correta vai criar problemas de manutenção para o time daqui a seis meses exige conhecer o time. O assistente não tem nada desse contexto, e dar a ele contexto suficiente para produzir algo útil nesses problemas costuma custar mais esforço do que pensar o problema por conta própria.
Também existe um risco real quando engenheiros param de exercitar as habilidades de recuperação e reconhecimento de padrões de baixo nível porque a ferramenta cuida disso. A familiaridade com sintaxe e APIs parece trivial, mas a internalização profunda dessas coisas é parte do que permite o pensamento fluido de alto nível sobre problemas complexos. Externalizar a mecânica por completo, em vez de seletivamente, é um trade-off que vale a pena fazer conscientemente, principalmente no início da carreira ou num domínio novo.
Os engenheiros que usam bem essas ferramentas são os que continuam claramente no comando do trabalho. O assistente gera opções; o engenheiro toma as decisões. Essa é uma postura diferente de simplesmente aceitar o que o assistente produz, e mantê-la exige mais participação ativa do que o discurso de produtividade sugere.
O sinal que isso envia num contexto de contratação
A forma como um engenheiro fala sobre o uso desses assistentes numa entrevista ou conversa de contratação é cada vez mais um sinal relevante, nas duas direções. Engenheiros que têm uma visão nuançada e baseada em experiência sobre onde essas ferramentas agregam valor e onde não agregam demonstram o mesmo tipo de pensamento crítico que se aplica a qualquer decisão sobre ferramentas. Engenheiros que se recusam a usá-las por completo, ou que descrevem seu fluxo de trabalho principalmente em termos de quanto a ferramenta escreve por eles, estão mostrando, de formas diferentes, algo sobre como pensam o próprio trabalho.
Os times que vale a pena entrar tendem a ter pensado nisso em nível de time: quais ferramentas estão em uso, para que tipos de tarefa, com que expectativas em relação a revisão e verificação. Essa conversa, quando existe, é evidência de que a cultura de engenharia levou a pergunta a sério, em vez de simplesmente adotar uma política padrão. É um sinal pequeno, mas costuma correlacionar com outras coisas que importam: investimento em developer experience, respeito pelo critério de engenharia e uma visão realista do que o bom trabalho exige.
Na Howdy trabalhamos com engenheiros sênior de toda a América Latina que entram em times de produto nos EUA, onde esse tipo de cultura de engenharia intencional é a norma, não a exceção. Se esse é o ambiente onde você faz seu melhor trabalho, a conversa começa em howdylatam.com.
Para se aprofundar nessa mudança cognitiva, aqui você encontra táticas concretas sobre como usar IA para ser um developer melhor, não só mais rápido.
Se você ainda está avaliando qual ferramenta agrega mais ao seu workflow, aqui analisamos as principais opções na perspectiva de engenheiros que as usam em produção.
