- O autor diz que o principal motivo para não usar ferramentas de programação com IA é que elas não o tornam mais rápido
- Ele considera que o tempo gasto para revisar e entender o código gerado pela IA pode ser maior do que escrever o código por conta própria
- Como a qualidade do código e a responsabilidade continuam sendo do próprio desenvolvedor, usar código de IA sem revisão é arriscado
- Em resposta ao argumento de tratar a IA como um estagiário, ele critica que, como a IA não aprende, ela seria como um estagiário com amnésia
- Ao explicar a diferença entre contribuições open source e código gerado por IA, ele destaca que a interação com pessoas traz novas ideias e, por isso, tem valor
Introdução
- Muitas pessoas me perguntam se uso ferramentas de programação com IA generativa e o que penso sobre isso
- Neste texto, deixo de lado posições a favor ou contra e organizo apenas minha experiência técnica pessoal
- Explico por que a IA não ajuda na minha programação do ponto de vista técnico
A IA não é mais rápida
- Mesmo usando ferramentas de programação com IA generativa, meu ritmo de trabalho não fica mais rápido
- Mesmo que a IA escreva o código, a responsabilidade pelo código continua sendo minha; só posso incorporá-lo ao projeto depois de revisar tudo com cuidado e entender completamente
- Revisar código exige tanto tempo e concentração quanto escrevê-lo, e há até o velho ditado da área de que “ler código é mais difícil do que escrevê-lo”
- Confiar no código escrito pela IA como se fosse uma “caixa-preta” é uma escolha muito irresponsável. Se houver falhas no código, a responsabilidade legal e financeira também recai sobre o programador
- Sem queda de qualidade e aumento de risco, não há como obter mais produtividade ou mais retorno com IA
A IA não é uma ferramenta de alavancagem
- Algumas pessoas afirmam que ferramentas de programação com IA multiplicam a eficiência, mas isso não passa de uma impressão subjetiva
- Alguns usuários economizam tempo usando o código gerado pela IA sem revisão ou com revisão parcial, mas eu não posso pular essa etapa, então isso não me ajuda
- Também não concordo com a ideia de que usar IA para aprender novas linguagens ou tecnologias seja eficiente. O próprio processo de aprender algo novo é parte da diversão de programar
- Na prática, estudo diretamente várias linguagens, como Rust, Go e TypeScript, e não delego esse tipo de experiência à IA
- Isso acontece porque a responsabilidade por todo o código, no fim das contas, é minha
Código de IA é diferente de código humano
- Frequentemente me deparo com a pergunta: “Contribuições open source também são código que eu não escrevi; então por que tratá-las de forma diferente do código de IA?”
- Na verdade, também invisto tempo para revisar cuidadosamente PRs de open source. Mas a colaboração com outras pessoas gera novas ideias e motivação
- Há quem diga que executar vários agentes de IA para receber PRs que resolvem issues de bugs é algo revolucionário, mas no fim o gargalo da revisão de código continua sendo humano, então isso acaba até tornando tudo mais lento
- Com a popularização das ferramentas de IA, PRs de baixa qualidade têm sido gerados com frequência. O código de IA costuma ter uma estranheza sutil e, ao fazer perguntas ao autor do PR, muitas vezes não há resposta
- Contribuições de código responsáveis e a comunicação dentro da comunidade open source são diferenciais importantes do código humano
A diferença entre IA e estagiário
- Há também quem compare a IA a um estagiário, mas as duas coisas são fundamentalmente diferentes
- O código inicial de um estagiário exige muita revisão e tempo, mas ele cresce rapidamente com feedback
- Ao investir nesse crescimento, no fim ele se torna um colega importante, capaz de assumir tarefas com independência
- Ferramentas de IA esquecem o conhecimento e recomeçam do zero a cada nova tarefa, sem conseguir evoluir nem acumular know-how
- Isso é como um estagiário que nunca melhora, e por isso não pode contribuir para aumentar a produtividade
Conclusão
- Com este texto, o autor busca deixar claros os problemas técnicos de aplicar ferramentas de programação com IA generativa
- Na programação com IA, não existe “almoço grátis”
- Alegações de que a IA traz mais velocidade ou produtividade decorrem de baixar o padrão de qualidade e aceitar riscos adicionais, ou do interesse de quem vende IA
- Programadores devem sempre lembrar que são os responsáveis finais
5 comentários
Já me estabeleci totalmente no modo agent com copilot (claud) + codex (o3/4o/codex-mini, 3 modelos simultâneos via mcp), mas acho que a eficácia disso varia enormemente conforme o perfil de quem usa e do projeto.
Eu costumo disparar trabalho ao mesmo tempo em 5 ou 6 workspaces e vou conferindo na ordem em que terminam; como o modelo consegue até olhar dentro de código open source e fazer toda a validação, acho isso bem interessante. Se eu deixo uma tarefa rodando na hora do almoço, uma ou duas já estão prontas quando volto. Às vezes também deixo rodando durante a noite, mas esse tal de copilot rate limit é uma caixa-preta...
Ele também dá conta, se você passar bons prompts e objetivos, de tarefas como kernel de alto desempenho, simplificação de call stack inteiro e garantir legibilidade — coisas que para humanos levam tempo por exigirem muita troca de contexto (afinal, ele consegue manter mais código na memória do que uma pessoa). Aí, revisar patches nesse tipo de código fica fácil... E para quem já passou por incidentes causados por erro no uso de API ou por bug no próprio projeto open source, fazer o Agent validar isso com firmeza também faz bem para a saúde mental...
Mas, no fim das contas, o desenvolvedor que usa isso precisa ser capaz de entender os patches. E também precisa saber escrever prompts. Porque só dá para começar de verdade quando você consegue, com base na experiência, formular o problema rapidamente e jogá-lo para o modelo. Como é impossível desenvolver kernel de alto desempenho sem fórmulas. Entender se o problema está no nível do chip/OS, no nível da aplicação ou em um recurso remoto ainda me parece ser papel de sênior.
Na perspectiva de quem já usou bastante coisas como Copilot, ChatGPT e Cursor, elas combinam bem com o papel de templates ou snippets em ferramentas de desenvolvimento, mas não chegam a ser um agente ou colega de trabalho.
Estou usando o Cursor.
No modo de chat, prefiro o
askaoagent, porque quero revisar antes e depois aplicar ao meu código, e no geral concordo com as desvantagens mencionadas no texto.Mesmo assim, pretendo continuar usando IA generativa, porque muitas vezes ela gera ideias ou códigos nos quais eu não tinha pensado, então considero que ela tem valor suficiente como referência.
Pela minha experiência pessoal, é bem parecido com o que sinto ao usar ferramentas de codificação generativa.
Comentário do Hacker News
Algumas pessoas costumavam, sempre que aprendiam uma nova linguagem ou tecnologia, ter dúvidas e antes faziam buscas no Google ou postavam perguntas no Stack Overflow e esperavam por respostas. Hoje, perguntam diretamente ao ChatGPT ou ao Gemini, recebem respostas muito mais rápido e a produtividade melhora bastante. Quero destacar que só o fato de obter respostas rápidas para perguntas já acelera o processo de aprendizado.
O motivo de ChatGPT e Gemini conseguirem apresentar respostas corretas é que foram treinados com conhecimento que já existia na web, incluindo o Stack Overflow. Se todo mundo passar a usar apenas IA para fazer perguntas, no fim as fontes públicas e confiáveis de conhecimento podem se esgotar. Isso lembra um retorno à era das enciclopédias, quando coletar e vender informação era caro. Além disso, o que o autor critica são ferramentas de IA para escrever código diretamente, e isso deve ser explicado separadamente das ferramentas que apenas respondem perguntas.
No passado, usei uma API com a qual não estava familiarizado e o programa travou. Colei o stack trace no Gemini e imediatamente obtive uma pista sobre a causa, corrigi só duas linhas e resolvi o problema. Só por experiências assim já dá para sentir o valor da IA. A grande vantagem é não precisar ficar perdido por muito tempo por causa de erros bobos em áreas desconhecidas.
A busca tem priorizado cada vez mais spam de blog, e por isso é mais educativo aprender pela base com documentação oficial bem feita ou guias de usuário. Quando você lê uma boa documentação de API, acaba aprendendo naturalmente o design geral e até recursos adicionais. Exemplos de blog ou tutoriais até resolvem o problema imediato, mas não ajudam no ganho real de habilidade. É como apenas fazer a lição de casa por você, então não acho que o ChatGPT realmente promova autoaprendizado genuíno.
Em problemas difíceis, é indispensável validar os resultados da IA. Também desliguei o autocompletar de IA porque, na prática, o ganho de eficiência não era grande e havia muitas correções desnecessárias. Curiosamente, até modelos locais totalmente offline conseguem fornecer bastante material de referência. Os resultados do Gemini embutido do Google também não são muito bons. A principal preocupação que tenho é que, se as pessoas passarem a obter informação só via IA, repositórios reais de conhecimento como o Stack Overflow podem desaparecer.
Para pequenas ferramentas boilerplate, a IA é perfeita. Coisas simples como extensões de navegador ou scripts do Tampermonkey podem ser iniciadas quase sem ler documentação. A IA também é bem útil para autocompletar código pouco complexo ou fazer correções triviais. Dá para resolver rapidamente pequenos projetos que normalmente eu nem começaria.
Um benefício potencial de escrever código diretamente é deixar no cérebro um modelo mental forte do problema. Depois, isso pesa muito na resolução de problemas ou na integração de novas funcionalidades por causa desse aprendizado “inconsciente”. A habilidade real só melhora de verdade quando você acumula a experiência de ter feito com as próprias mãos. Nas organizações que vi, mesmo após a adoção de LLMs, não houve um ganho real de produtividade em múltiplos. Às vezes me pergunto se não estamos apenas confundindo poupar esforço mental e buscar o caminho fácil com produtividade.
Acho que isso resume muito bem o fenômeno de as pessoas se acostumarem a resolver problemas gastando menos energia mental e confundirem essa sensação com produtividade. Em um experimento de 2024 do Google Research sobre o efeito dos LLMs na produtividade, o grupo que usou LLM levou mais tempo do que o grupo que estudou por livro, e só os iniciantes, não os mais experientes no conteúdo, tiveram uma leve melhora na pontuação. Mesmo assim, muitos participantes acharam que estavam sendo mais rápidos e mais precisos, e os pesquisadores interpretaram isso como efeito da “redução da carga cognitiva”. Link do artigo: https://storage.googleapis.com/gweb-research2023-media/pubtools/7713.pdf
Se você conseguir gastar menos energia mental e trabalhar por mais tempo, talvez de fato consiga dar conta de um volume maior de trabalho. Mesmo hoje, tarefas de alta dificuldade têm um limite de 3 a 4 horas. A ideia é que, se fosse possível correr uma maratona andando, o resultado total poderia aumentar.
Concordo com a ideia de que programação tradicional e programação com IA são habilidades diferentes. Eu também sou bastante cético em relação à afirmação de que a IA vai substituir a programação. Mas vejo que a própria “programação com IA”, com coisas como gestão de prompts e manutenção de contexto, também tem uma curva de aprendizado considerável, e acho que muita gente subestima seu valor nesse ponto. É como desenho manual e fotografia: os objetivos buscados podem ser diferentes. A forma que prefiro é “a IA cuida do trabalho pesado, e eu fico responsável pelo design geral e pela coordenação”.
Programar com base em LLM se parece menos com simples autocompletar e mais com terceirizar trabalho em um ciclo repetido de definir tarefa, dar feedback e iterar. A diferença é a velocidade de execução, em que o LLM leva vantagem, e a confiabilidade, em que humanos levam vantagem, mas no longo prazo essa fronteira deve ficar cada vez mais tênue. O importante é que eu sou, por natureza, o tipo de pessoa que quer lidar diretamente com os detalhes do trabalho. Escolhi essa carreira porque gosto de aprender e me aprofundar em infraestrutura e programação. Por isso, evito papéis de gestão e insisto em construir diretamente, mesmo ganhando menos. Talvez eu volte a me interessar quando a AGI chegar ao ponto de ser uma colega de trabalho. Também é bem possível que o próprio nome “IA” deixe de parecer algo tão especial no futuro.
Mesmo que a curva de aprendizado da programação com IA seja maior do que parece, ainda é diferente de piano, em que você precisa investir anos. Os programadores com IA mais experientes que existem hoje têm no máximo uns 3 anos de experiência, e os modelos continuam mudando, então muita coisa aprendida no passado nem se encaixa nos modelos atuais. Também há a limitação de não existir uma estrutura clara para aprender com um mestre.
Será que a habilidade de programar com IA tem valor no longo prazo? Sou cético quanto a quanto o conjunto de habilidades das ferramentas atuais de IA vai se transferir para as próximas gerações. Mesmo que a eficiência aumente agora, é preciso considerar a possibilidade de que tudo isso fique inútil quando os modelos e ferramentas mudarem.
Acho que dá para aprender programação com IA em poucos minutos ou talvez em uma hora. Metaforicamente, não parece uma área para estudar um livro inteiro como GDB ou UNIX. Assim como desenho e fotografia têm princípios e objetivos totalmente diferentes e não se confundem, programar com IA também é uma atividade completamente diferente da programação tradicional.
Não concordo com a confiança de quem acha que a preferência por programar diretamente existe apenas por falta de habilidade com programação por IA. Só o ROI que observei até agora usando pagamentos pequenos e testes grátis já é suficiente para tirar uma conclusão.
Na prática, surgiu uma cultura em que, em vez de fazer code review de IA ou revisar os resultados, as pessoas simplesmente colocam o código gerado por IA no PR e empurram a revisão para os outros. Nessa situação, a GenAI não parece tanto uma ferramenta realmente útil, mas sim algo que está sendo usado com o efeito colateral de adiar trabalho.
Eu também passei por isso. Quando a gerência tem pouca capacidade, não consegue distinguir quem realmente está criando valor. Eu obtenho muito valor de agentes de código, mas acho um problema grave quando organizações sem competência recompensam entregas mal feitas.
Se o autor do PR continuar enviando resultados crus de IA, o certo é acumular feedback e o líder da equipe precisa necessariamente levantar o problema.
Como alguém que usa Claude Code com frequência, concordo 100% com a afirmação de que, ao revisar código escrito por outros, quase não há diferença de tempo em relação a escrever você mesmo. LLMs são até úteis, mas quanto mais controle você entrega, mais tempo acaba levando até o release de verdade. Foi bom para aliviar sintomas de RSI, mas o efeito de economia de tempo muitas vezes é mais exagerado do que parece.
Quando me perguntam se é realmente necessário revisar o código, normalmente digo que faço mais spot review em resultados de IA, peço para a IA escrever o documento de especificação e depois eu mesmo faço a revisão final e os testes com cuidado. Na verdade, a maioria do código de bibliotecas open source eu também não reviso do zero.
Aqui existe a premissa de que “o código que eu mesmo escrevi não precisa ser revisado de um ponto de vista separado”. Na prática, o meu eu do futuro também é um potencial leitor do código. Programar com IA força esse mindset: estabelecer critérios claros de aceitação e validar com testes e regras consistentes. No fim, isso incentiva uma cultura de desenvolvimento mais robusta e mais bem documentada.
Para depurar bugs com Claude Code, se você escrever os testes primeiro, virou rotina a IA corrigir em poucos minutos. Depois da introdução do novo recurso de busca, até tarefas complexas podem ser resolvidas em 5 minutos. Nesse ponto, a economia de tempo é muito claramente perceptível.
Como solução para sintomas de RSI, também recomendo sempre manter os braços aquecidos.
Foi levantada a dúvida: “eu não quero resolver tudo por uma interface conversacional; existe algum caso de adoção de UI híbrida?”
Ferramentas de programação com IA generativa só aceleram as partes fáceis do trabalho e, em compensação, tornam as partes difíceis ainda mais difíceis. Na prática, o tempo gasto com o ato de programar em si não é tão grande, então mesmo que só essa parte fique 100 vezes mais rápida, a produtividade total não muda tanto assim. Por isso, não quero gastar tempo com isso.
Se você já é um engenheiro que domina totalmente uma stack específica e um certo domínio de problema, não precisa de ferramenta nenhuma, nem de aprendizado. Mas essa lógica tem pouca utilidade no mundo real. No fim, a escolha de ferramentas é uma otimização pessoal.
Eu peço para a IA escrever algoritmos, explicar a causa do código, fazer chamadas de API ou implementar funções específicas. Mesmo sem pedir o código completo, tenho usado isso cada vez mais junto com o debugger.
Uma pergunta em tom de brincadeira: por acaso você é encanador?
A parte em que o autor diz que “revisar código escrito por outros pode levar tanto tempo quanto, ou até mais, do que escrever código diretamente” me pareceu muito válida; eu mesmo tenho experiência com code review detalhado, como em auditoria de segurança. Mas, se a IA ficar muito boa em tarefas rotineiras extremamente simples, talvez baste uma validação abrangente, como um verificador eBPF, sem necessidade de inspecionar o código em detalhes. Se houver algum problema complexo demais, basta rejeitar o PR. Em código simples e repetitivo, talvez realmente seja menos necessário que humanos façam uma revisão minuciosa.
Ainda assim, questiono se isso é mesmo eficiente. Se você vai abrir dezenas de PRs e aprovar só um, então seria muito mais confiável simplesmente usar código de um colega. Uma estrutura que só desperdiça tempo, dinheiro e recursos ambientais não me parece desejável.
Se for realmente uma “função Go repetitiva”, fica a dúvida se havia necessidade de escrever esse código. Se é um código ineficiente, pouco reutilizável, e uma ou duas linhas de uma biblioteca comum resolveriam, não vejo motivo para usar IA para criá-lo.
Para quem lê código mais rápido do que escreve, GenAI é útil; para quem escreve mais rápido do que lê, não há tanta necessidade de usar.
Foi levantada a dúvida sobre por que o código escrito por IA deveria ser revisado de forma diferente do código escrito por humanos.
Em tarefas repetitivas e simples, bindings de template da IDE e recursos de autocompletar variáveis já cobrem o suficiente, com a vantagem de serem gratuitos.
Na discussão comparando estagiários com assistentes de programação por IA, o estagiário aprende o código real, o negócio e o histórico do sistema, enquanto para a IA é preciso explicar repetidamente o contexto. Essa limitação continua existindo.
Há a visão de que, se o contexto importante for salvo em arquivos
mdc, o próximo responsável também poderá consultar essa informação, o que pode até melhorar a documentação e a persistência do conhecimento.Em alguns LLMs, isso acaba sendo a razão de os system prompts ficarem com 14k de comprimento.
Estagiários muitas vezes realmente se importam.
Também é possível simplesmente colocar o contexto importante de negócio no system prompt.
Os modelos atuais de IA, em essência, aprendem apenas padrões de dados existentes. Eles combinam templates de casos de sucesso, mas não são estruturados para induzir soluções realmente novas a partir dos fundamentos. Diante de um problema, tendem a buscar a resposta na experiência mais parecida, em vez de partir de uma abordagem baseada em princípios desde o começo. Especialistas humanos são bons em first principles, isto é, no raciocínio lógico a partir de princípios fundamentais, algo que a IA tem dificuldade em fazer. A IA prioriza similaridade e acaba propondo soluções padronizadas; essa limitação fica especialmente evidente em áreas que exigem inovação ou em problemas onde as convenções não funcionam. Até para lidar com context poisoning, humanos respondem de forma muito mais eficiente.
Não sou alguém que espere muito da IA em geração de código, mas para trabalhos repetitivos e tediosos de boilerplate a IA é N vezes mais rápida, com uma diferença percebida como muito grande. Em uma experiência real, joguei no ChatGPT um exemplo de modal com React Context e ele gerou na hora a estrutura completa, com hooks, provider e tudo mais. Isso me poupou uns 30 minutos na hora, e para esse tipo de trabalho repetitivo os 20 dólares por mês passam longe de parecer desperdício.
Nesses casos, muitas vezes também dá para pegar exemplos da documentação da biblioteca, e em 5 minutos implementar você mesmo o mínimo necessário. Mas código gerado costuma trazer uma solução completa moldada para a situação atual e, depois, fica mais incômodo fazer melhorias estruturais graduais e refatoração.
Eu também uso IA principalmente para boilerplate ou scripts ad-hoc. Ainda acho difícil delegar completamente problemas reais e complexos à IA. Principalmente em problemas que exigem mergulhar fundo no sistema, a pessoa precisa fazer isso diretamente, e os insights obtidos no processo são importantes. Sinto que, quanto maior o projeto e quanto mais elementos integrados houver, maiores ficam as limitações da IA.