- Agentes de programação com IA estão aumentando dramaticamente a velocidade de escrita de código, mas a parte mais importante do desenvolvimento continua sendo entendimento e resolução de problemas
- É possível criar código rapidamente com LLMs, mas a falta de compreensão do contexto geral faz com que pós-processamento e entendimento consumam mais tempo
- Isso cria uma lacuna entre a expectativa de produtividade e a eficiência real, além de levar desenvolvedores a gastar tempo com tarefas repetitivas e desgastantes, como testes, refatoração e documentação, em vez do trabalho criativo que desejam
- Assim como no passado com o ‘dilema do tech lead’, concentrar trabalhos complexos em IA ou em profissionais seniores para obter resultados de curto prazo pode causar queda da capacidade da equipe e crises no longo prazo
- É preciso enxergar os LLMs como um engenheiro júnior muito poderoso e aplicar processos de desenvolvimento comprovados à colaboração com IA para construir uma estrutura de entrega sustentável de software
Reconhecendo o problema: o que importa mais do que programar
- O desenvolvimento de software é um trabalho centrado em resolver problemas
- A programação em si corresponde apenas à parte final de todo o raciocínio e reflexão do desenvolvedor
- Além do código, o desenvolvedor também lida com entendimento do domínio, detalhamento de requisitos, abstração, consideração de efeitos colaterais, testes incrementais e correção de bugs
- Fluxo tradicional de desenvolvimento: pensar o suficiente antes de escrever código
- Na era da programação com IA: mudança para o padrão código primeiro, entendimento depois
A mudança trazida pela programação com IA: um paradigma em que o código vem primeiro
- Agentes de programação com IA como o Claude Code geram código rapidamente, mas não conseguem compreender completamente o contexto do sistema como um todo
- O processo humano de revisão, teste e integração é indispensável, e muito tempo é gasto para entender depois o código escrito pela IA
- O marketing destaca o aumento da velocidade de programação, mas o ganho real de produtividade na entrega de software funcionando é pequeno
- Desenvolvedores passam mais tempo em tarefas repetitivas e difíceis, como testar, remover duplicações, documentar e gerenciar infraestrutura do resultado produzido pela IA
- A diversão real de programar diminui, enquanto o trabalho repetitivo aumenta
O velho dilema dos líderes técnicos
- Quando um engenheiro assume o papel de tech lead, ele passa a carregar a responsabilidade pela entrega técnica da equipe
- Quando a experiência da equipe fica concentrada em uma única pessoa, surge um desequilíbrio de produtividade
- Há conflito entre duas estratégias: distribuição equilibrada (priorizando o crescimento da equipe) e concentração de trabalho (focada em desenvolvimento rápido)
- Concentrar o trabalho traz grande ganho no curto prazo, mas provoca riscos de longo prazo para a equipe por causa da concentração de experiência, como ausência de pilares, burnout e dificuldade de substituição
- Para uma cultura de equipe saudável, é preciso encontrar um equilíbrio entre crescimento e eficiência
O núcleo da boa liderança: equilíbrio entre processo e crescimento
- É necessário aplicar vários princípios de desenvolvimento e frameworks para que toda a equipe absorva o know-how dos engenheiros mais experientes
- Exemplos: Extreme Programming, code review, deploy incremental, design modular, desenvolvimento orientado a testes, pair programming, documentação e integração contínua
- Objetivo final: minimizar retrabalho, maximizar colaboração e promover crescimento individual
Colaboração com agentes de IA: um novo papel de liderança de equipe
- Agentes de programação modernos baseados em LLM se parecem com um desenvolvedor júnior absurdamente rápido
- Diferentemente de um júnior tradicional, o LLM tem duas diferenças claras: não aprende e não tem limitação de velocidade
- A IA continua focando em aumentar velocidade em vez de melhorar qualidade, e carece do entendimento humano de contexto e domínio
- Dois padrões de colaboração:
- Engenharia baseada em IA: busca um trabalho em equipe mais lento, porém eficiente e sustentável
- Vibe coding: foca em resultados rápidos, mas acumula aos poucos um caos irrecuperável
- Isso lembra um ponto cego tradicional do crescimento de código no Vale do Silício: depois do ganho de curto prazo, chega-se a uma barreira de limite de crescimento
Formas práticas de sobreviver à armadilha da programação com IA
- O LLM não conhece sua situação específica e produz código indiscriminadamente
- O engenheiro precisa fornecer à IA estrutura, padrões e processos claros para transformar a saída bruta em um serviço real
- É necessário um novo playbook que aplique de perto as melhores práticas do ciclo tradicional de desenvolvimento ao ambiente de colaboração com IA
- Formas de usar IA em cada etapa principal:
- Definição de especificação: análise de edge cases, foco no escopo do objetivo
- Documentação: garantir guias e evidências reutilizáveis
- Design modular: melhorar a compreensão ao limitar o contexto
- Desenvolvimento orientado a testes: gerar casos de teste antes da implementação, evitando regressões
- Padrões de código: manter estilo e qualidade
- Monitoramento: análise automática de logs e geração de insights
Conclusão
- A entrega de software não acontece apenas escrevendo código, e é essencial estabelecer uma estrutura eficiente de colaboração entre IA e humanos
- É preciso tratar o LLM como um desenvolvedor júnior em velocidade extrema e aplicar processos de desenvolvimento comprovados para entregar software de alta qualidade com escalabilidade
2 comentários
Comentários no Hacker News
Quero ver um argumento anti-AI que não se baseie simplesmente na ideia de que “a tecnologia deixa as pessoas preguiçosas”. Quem já tentou seriamente produzir código com LLM sente que o ciclo de planejar-estruturar-testar-revisar continua sendo muito importante. Se você só roda sem cuidado, quebra muito fácil. Quando aplico bem esse ciclo, consigo gastar bastante tempo com o que eu gosto: projetar arquitetura e testar a experiência do resultado. Como o LLM resolve rápido as partes fáceis, no fim o que sobra para nós são as tarefas menos interessantes e menos reconhecidas. Nas áreas em que a AI realça a especialidade, aparece com clareza a diferença de visão entre quem gosta do trabalho em si e quem gosta da experiência de pensar. Quem gosta de pensar pode, graças à AI, se concentrar quase totalmente nisso. Já para quem gosta de digitar e manipular diretamente, a AI acaba tirando justamente a parte de que a pessoa gosta
Em relação à geração de código por AI, considero mais importante a crítica de que ela tira a compreensão profunda do código gerado, e não tanto a ideia de que a tecnologia deixa as pessoas preguiçosas. O núcleo do trabalho de um engenheiro de software não é gerar código, mas desenhar o sistema como um todo. O que importa aqui é o modelo mental de como o código funciona e a especialização no domínio; o código é um resultado derivado desse modelo mental. Em projetos de certo porte, é difícil conhecer completamente um código se você não foi o autor que o escreveu. Sem construir esse modelo mental, outros problemas também aparecem. Agentes de codificação baseados em LLM têm limitações de raciocínio no nível sintático, então mostram fraquezas de escalabilidade
Para dar minha opinião, eu uso às vezes ferramentas de AI como Cline, mas aos poucos estou aumentando a proporção de vezes em que codifico digitando eu mesmo. O motivo é que, na maioria dos casos, isso só substitui a programação pela escrita de prompts. Se o tempo de escrever o prompt e esperar o raciocínio for menor que o tempo de eu programar com as próprias mãos, uso AI, mas em geral isso só vale quando o gargalo é algo como refatoração. Na maior parte das tarefas, se eu fizer direto levo 10 minutos; com AI, gasto 8 minutos escrevendo prompt e executando. Se der certo de primeira, economizo 2 minutos, mas se houver correção ou re-prompt, acaba levando 10 a 12 minutos, ainda por cima gastando créditos de AI, ou seja, é o pior cenário. Fazendo essas contas, cheguei à conclusão de que, considerando tanto a qualidade do código quanto o tempo gasto, o trabalho manual é mais seguro
Sobre a ideia de que a tecnologia deixa as pessoas descuidadas, em geral também há muitos casos em que a tecnologia torna as pessoas mais cuidadosas. O problema é que essa tecnologia de AI tem grande potencial de induzir o usuário à falta de cuidado. Meu interesse não está na parte divertida de codificar; eu prefiro o design em si, a arquitetura. Se eu pudesse refletir a intenção diretamente no código, usaria esse caminho. Mas a interface de chatbot transmite a intenção de forma indireta e imperfeita, então, quando eu a uso para construir código de alto nível, o modelo que tenho na cabeça e a compreensão real do código se afastam rapidamente, deixando uma base instável. Dá para revisar linha por linha com cuidado, mas isso vai contra a proposta da ferramenta. A codificação com AI, por passar a sensação de ser “10 vezes mais rápida”, incentiva a distância entre a implementação detalhada e a compreensão macro. Na prática, pensar menos nas partes estruturais é um dos principais benefícios vendidos da codificação com AI, mas essa lacuna de entendimento causa problemas depois. Uma boa automação é confiável e previsível, de modo que basta entender os invariantes de nível superior, mas o código de chatbot não oferece essa garantia e acaba criando uma estrutura em que tudo precisa ser verificado manualmente. Aqui, segurança e confiabilidade parecem ainda mais difíceis
Vejo com tanta frequência essa lógica de “foque na parte de pensar” que já acho batida. A questão é: será que alguém que não passou anos fazendo trabalho prático de verdade consegue realizar uma atividade profunda só pensando? No fim, sem a experiência de colocar a mão na massa, até o próprio pensamento corre o risco de ficar cada vez mais superficial
Minha opinião é a seguinte: como depurar é mais difícil do que escrever, é melhor eu mesmo escrever do que ter de depurar código que eu não escrevi
Sempre que leio esse tipo de discussão, fico pensando se o autor está usando as mesmas ferramentas que eu. Com Claude Code, consigo gerar quase tudo, desde boilerplate simples até algoritmos complexos, mesmo dentro de codebases grandes e muito confusas. Claro que não acerta 100%, mas chega muito perto. Além disso, frequentemente sugere algoritmos em que eu não tinha pensado. Essas ferramentas me fazem economizar pelo menos 10 vezes mais tempo
O texto é bom, mas vejo duas premissas equivocadas. Primeiro: mesmo quando um desenvolvedor experiente usa LLM, ainda são indispensáveis investigação suficiente, reflexão prévia e design. Na verdade, para usar LLM direito, é preciso pensar mais do que o normal, comparar várias opções de design e desenhar a estrutura inteira. Antes eu não documentava esse processo, mas agora deixo isso registrado em documentos de design. Segundo: a afirmação de que LLM é como um júnior que não evolui, mas os dois são totalmente diferentes. Um desenvolvedor júnior humano é uma pessoa; LLM é uma ferramenta. O argumento costuma ser que, trabalhando com um júnior, existe valor acumulado, enquanto com LLM não, mas isso também não está certo. Mesmo que o LLM não aprenda, eu me torno muito mais eficiente em treiná-lo e aproveitá-lo melhor. Estamos no começo da fase de aplicar LLM bem em produtos, então é natural que apareça um valor de crescimento composto
Concordo com “mesmo que o LLM não aprenda, eu aprendo”, mas ainda assim queria que o LLM realmente aprendesse com a interação com o usuário. O que eu quero é poder salvar/carregar o conteúdo da sessão em arquivo, para que o LLM compreenda sem falhas todo o contexto aprendido antes. Algumas UIs de frontend permitem salvar/restaurar sessões, mas o ponto importante é que a) esse “reaprendizado” não afete a current context window do LLM (idealmente esse conceito nem existiria), e b) isso aconteça de uma forma absolutamente sem perdas. Já existem métodos como resumir e continuar, ou RAG, mas todos eles têm limitações fundamentais, como perda de informação ou a necessidade de a restauração ser acionada apenas pela interação atual. Por exemplo, se ontem eu expliquei ao LLM uma certa função e salvei a sessão, quero que hoje, depois de restaurar a sessão, mesmo fazendo uma pergunta sem relação aparente, o LLM ainda responda levando em conta todo o contexto antigo. Também acho necessário um modo em que, quando eu quiser um recomeço limpo, isso possa ser feito explicitamente
É isso mesmo. Como, na produtividade total de software, o tempo de pensar ocupa uma parcela muito maior do que o tempo de realmente escrever código, mesmo que o LLM acelere a parte de codificar, isso não gera uma mudança dramática na produtividade total nem na demanda por pessoas
Começar com o prompt
DO NOT WRITE ANY CODE YETtambém é meu padrão. É a forma de primeiro entender o que o LLM pretende fazer e garantir meu controle. Eu me divirto mais com a lógica, a resolução de problemas e a integração de sistemas, ou seja, com o design em si, do que escrevendo códigoExistem recursos como o modo Ask do Copilot e os modos Plan/Chat do GPT-5 Codex, que permitem planejar sem alterar arquivos de código. Usei o Codex por alguns dias e, se você der instruções suficientes, ele é excelente
Eu também prefiro, na maioria das vezes, pedir ao LLM primeiro um plano antes da execução, algo como “me diga o plano primeiro”
Este texto cita apenas material de marketing da Microsoft para afirmar um ganho de produtividade de 10%, mas em um estudo de Harvard foi registrada na prática uma queda de produtividade de 10%. Eu preferiria um texto que citasse antes resultados de pesquisas independentes, e não divulgação de uma empresa específica
Um dos pontos centrais que este texto não transmite completamente é o que Casey Muratori disse: “se você programa com uma mentalidade centrada no aprendizado, a AI acaba sendo sem sentido”. Pessoalmente, sinto que geradores de código por AI só são úteis para código descartável, de uso pontual. Em áreas nas quais quero aprender seriamente, senti que maximizo o aprendizado quando não deixo a AI gerar o código. Sem dúvida existe gente para quem “engenharia guiada por AI” faz sentido, mas pelo menos para mim é mais divertido escrever os blocos de código com as próprias mãos e, no fim, também sinto que o resultado fica melhor. Vídeo relacionado, 5 minutos
Usando Claude Code, passei a gastar muito mais tempo pensando. Antes eu não descrevia a funcionalidade que queria em 400 a 600 palavras, mas agora organizo muito mais informação com cuidado. Essa reflexão de fato traz resultados mais rápidos e melhores, mas ao mesmo tempo minha compreensão do código ficou um pouco menor do que antes. Ainda assim, não consigo concordar com a afirmação de que desenvolvedores experientes pensam menos quando usam Claude Code. Talvez muita gente esteja usando agentes de forma ineficiente, escrevendo praticamente só prompts, mas não acho que isso seja culpa do agente
Quando vejo essas discussões, penso que ainda estamos numa fase intermediária ambígua. Acho que, por volta do ano que vem, discussões como as de hoje serão vistas como “pensaram demais”. Parece semelhante à época em que, antes e depois da popularização da internet, havia muitas dúvidas do tipo “é só uma moda passageira” ou “foi um investimento errado”
O que esses textos frequentemente deixam passar é o seguinte
Gostaria de ver um texto que organizasse de forma sistemática apenas os prós, contras e trade-offs da assistência de código por AI. É preciso discutir isso sem julgamento moral de valor (bom/ruim). Reconheço que é especialmente difícil abordar friamente o tema quando “habilidade de programar” faz parte da minha identidade
Todos os dias eu me incentivo dizendo: “é só aguentar mais 30 anos e me aposentar”. Já estou há 10 anos em machine learning, cansado de ficar na frente do computador e cansado do trabalho. Só queria rolar na grama
O gráfico “pensar & programar vs pensar & corrigir” é interessante. Recentemente, usando Codex, eu de fato esperava que a AI fosse me fazer alterar muito o meu código. Na prática, quando a causa do problema não tem absolutamente nada a ver com o código, o tempo vai embora de forma brutal. Recentemente passei um tempão olhando só para o código por causa de um problema de autenticação, e depois descobri que a causa era uma falha na configuração de ipv6 da VM
Concordo plenamente. Quando usei IA para programar, havia trabalho demais de pós-processamento, então ficou muito difícil aplicar isso ao negócio real e fazer a manutenção.
Mesmo avançando com muita troca, como se estivéssemos desenvolvendo juntos, como parte do código não foi escrita diretamente por mim, muitas vezes ela acaba sumindo da cabeça.
Acho que limites são absolutamente necessários.