- Ferramentas de IA para programação, ao automatizarem a tarefa fácil de escrever código, acabam criando um problema estrutural em que para os desenvolvedores restam apenas as tarefas difíceis: investigar, entender o contexto e validar
- O fenômeno de desenvolvedores dizerem que "a IA fez por mim" sem entender diretamente a saída da IA é um sinal de alerta semelhante ao velho copiar e colar do StackOverflow
- O vibe coding é útil para prototipagem, mas em ambientes reais de produção há casos em que a IA consome mais tempo em vez de economizá-lo
- Quando algo é implantado rapidamente uma vez graças à IA, isso vira uma nova linha de base, gerando pressão contínua por sprints e levando ao burnout como problema de gestão
- O ponto-chave é usar a IA não como fornecedora de soluções, mas como ferramenta de investigação, e manter a responsabilidade do desenvolvedor sobre todo o código
O problema da frase "a IA fez por mim"
- No passado, desenvolvedores liam respostas no StackOverflow, artigos ou issues do GitHub e tiravam suas próprias conclusões depois de validar o contexto
- Ninguém dizia que "o Google escreveu o código" ou que "está certo porque é o primeiro resultado da busca"
- Recentemente, começou a surgir a expressão "a IA fez por mim"
- Isso exagera o que realmente aconteceu ou significa que o desenvolvedor não chegou à própria conclusão
- Nos dois casos há um problema, com a mesma preocupação de quando se copiava e colava código do StackOverflow: você realmente entendeu o código colado?
Os limites do vibe coding
- O vibe coding é divertido no começo e útil para prototipagem ou projetos pessoais de baixo risco
- Mas no trabalho real, cada linha de código tem consequências
- Em um projeto pessoal, ao pedir a um agente de IA que adicionasse testes a um arquivo específico, um arquivo de 500 linhas foi reduzido a 100 linhas
- A IA afirmou que não havia apagado mais nada e depois passou a afirmar que o arquivo original nem existia
- Quando viu o histórico do git, pediu desculpas e admitiu que deveria ter verificado primeiro se o arquivo existia
- Nesse caso, o suporte da IA consumiu mais tempo em vez de economizá-lo
- Discutir com o agente e recuperar o arquivo levou mais tempo do que escrever os testes manualmente
- Se a mesma coisa acontecer em um ambiente como uma base de código de saúde, as consequências podem ser graves
- É importante usar a IA não como fornecedora de soluções, mas como ferramenta de investigação, e é preciso prática para perceber quando a IA está errada
A estrutura em que a parte difícil fica mais difícil
- Escrever código sempre foi a parte fácil do trabalho de desenvolvimento
- A parte difícil é investigar, entender o contexto, validar hipóteses e saber por que uma determinada abordagem está correta
- Ao passar a parte fácil para a IA, o trabalho não diminui; sobram apenas as partes difíceis
- Se a investigação é pulada porque a IA já deu a resposta, então falta justamente o contexto necessário para avaliar a saída da IA
- Ler e entender o código de outra pessoa é muito mais difícil do que escrever código
- Código gerado por IA é, em essência, código de outra pessoa
- O desenvolvedor entrega para a máquina a parte em que normalmente é bom (escrever) e fica só com a parte mais difícil (ler e revisar)
- E precisa revisar sem o contexto acumulado ao escrever o código diretamente
Expectativas de sprint e burnout
- Quando algo é entregue rapidamente uma vez com ajuda da IA, isso vira uma nova linha de base e passa a existir cobrança para manter sempre a mesma velocidade
- A conversa muda de "como você conseguiu fazer isso?" para "por que você não consegue fazer isso sempre?"
- Isso não é um problema de engenharia, mas de gestão
- Engenheiros exaustos deixam passar edge cases, pulam testes e colocam bugs em produção
- Mais incidentes → mais pressão → mais sprints, em um ciclo vicioso
- Sobre a afirmação de que "a IA cria produtividade 10x", na prática pode ser que um engenheiro de 0,1x tenha virado 1x
- Tecnicamente é 10x, mas a pergunta importante é se isso realmente é ganho de produtividade ou apenas a exposição de quanto a investigação antes não era feita
- Burnout e lançamento de código de baixa qualidade anulam os ganhos de produtividade trazidos pela IA
Habilidade de sênior, confiança de júnior
- Agentes de IA para programação têm capacidade de escrever código em nível sênior, mas o nível de confiança em sua saída deve ser tratado como o de um engenheiro júnior
- O código parece bom e provavelmente funciona, mas como falta experiência, é preciso verificar com mais cuidado
- Em analogia, um agente de IA para programação é como alguém que lê muito rápido e acabou de entrar no time
- Pode ajudar na investigação e escrever código, mas não participou das reuniões em que o contexto e os antecedentes importantes da semana passada foram discutidos
A importância da propriedade do código
- O desenvolvedor deve ter responsabilidade real sobre o código, não apenas o que escreveu diretamente, mas também o que foi gerado pela IA
- Se a saída da IA for copiada e colada por causa de metas irreais de velocidade, o problema aparece quando um novo integrante do time tentar entender esse código dali a 6 meses ou quando houver uma falha às 2 da manhã
- Dizer "foi a IA que escreveu" não ajuda em situação nenhuma
Como a IA pode ajudar na parte difícil
- Caso de bug em produção: logo após um grande release, usuários relataram um bug de edge case na exibição de fuso horário
- O desenvolvedor responsável precisava sair para uma aula em 30 minutos, e o restante do time já havia encerrado o expediente
- A IA foi usada para conduzir a investigação, indicando que era um bug baseado em mudanças recentes e explicando como reproduzi-lo
- O problema era que alguns métodos deprecated tinham precedência sobre métodos atuais com reconhecimento de fuso horário, o que fazia a conversão de timezone falhar
- Em 15 minutos, a causa raiz, ideias de solução e notas da investigação foram organizadas em uma issue no GitHub
- O desenvolvedor responsável confirmou a correção, e outro membro do time concluiu os testes e o deploy
- O problema foi resolvido sem urgência extrema e sem precisar virar a noite
- A principal lição desse caso é a estrutura de colaboração em que a IA faz o trabalho repetitivo da investigação, enquanto a pessoa fornece contexto e valida
- A IA deve ser usada para fortalecer investigação, validação e compreensão de contexto; caso contrário, se consolida uma estrutura em que a parte fácil fica mais fácil e a difícil fica mais difícil
3 comentários
> A IA não torna o desenvolvimento mais difícil
> Pelo contrário, ela expõe as partes realmente difíceis que as pessoas vinham ignorando até aqui
> Nos últimos 15 anos, os desenvolvedores já vinham fazendo uma “versão humana de vibe coding” — copiando e colando do Stack Overflow, refatorando sem planejamento e trabalhando com a mentalidade de “se roda no meu notebook, tá bom”
> Agora que a IA faz isso, de repente todo mundo quer planejar e escrever testes
> Se a qualidade melhora, mesmo que o processo fique mais lento, isso é progresso de verdade
Na minha visão, os desenvolvedores que viviam no copia e cola continuam fazendo copia e cola mesmo usando LLM,
e parece que os desenvolvedores que já se preocupavam bastante com a qualidade agora se preocupam ainda mais
Opiniões no Hacker News
Programar com ferramentas de assistência de IA é uma nova habilidade completamente diferente da programação tradicional centrada em humanos
As linguagens, frameworks e princípios de desenvolvimento que temos existem para superar limitações humanas, mas a IA tem limitações diferentes
Ao resolver problemas complexos, em vez de apenas dar um prompt e receber um resultado, foi útil explorar o espaço do problema por meio de conversa e design iterativo
Os erros ou alucinações da IA acabam funcionando como um sinal de que eu talvez não esteja entendendo o problema corretamente
Eu tentei fazer um emulador retrô e um assembler no estilo de vibe coding, e consegui bons resultados com poucos prompts
Mas quando tentei reproduzir uma parte proprietária de um app industrial específico que eu havia feito antes, o resultado foi péssimo não importava quantos prompts eu desse
Há milhares de exemplos de emuladores no GitHub, mas para o que eu queria fazer não havia exemplo nenhum
A conclusão é simples — algumas coisas são fáceis, e outras simplesmente não saem
Se há muitos exemplos no GitHub, então isso também existe no espaço latente do LLM, e ele pode puxar isso a qualquer momento
O que você tentou só não tinha exemplos assim
Frameworks especializados para a indústria são difíceis de lidar com vibe coding, mas se você simplifica o problema a IA ajuda muito mais rápido
Se você adotar o vibe coding por completo, pode conseguir resultados incríveis, mas a dívida técnica cresce tanto que no fim parece que você vira escravo da máquina
Quando a IA escreve milhares de linhas de código por você, fica muito difícil entender ou revisar a estrutura disso
No fim, acho que vamos ver mais código e software descartáveis — apps para resolver problemas específicos serão fáceis de fazer, mas para um SaaS sustentável isso traz um risco enorme
A IA é uma ferramenta com um forte efeito multiplicador (force multiplier)
Se a base do codebase é ruim, a IA simplesmente replica esse estilo
Por outro lado, se a base é limpa e consistente, a IA mantém essa qualidade e funciona surpreendentemente bem
No fim, o ponto central é a fundação (foundation)
A maioria dos codebases tem uma estrutura difícil de manter e expandir, então a IA só deixa esse problema mais visível
Como na construção civil, se a fundação é fraca, até a melhor ferramenta tem limite
Fazendo isso, até o próximo desenvolvedor conseguiu entender completamente o contexto (context) do projeto
No fim, é preciso acertar primeiro as abstrações centrais para a IA funcionar direito
Os requisitos mudam o tempo todo, e surgem concessões em nome da eficiência
No fim, tempo e custo de oportunidade acabam tendo prioridade sobre a qualidade — porque humanos não conseguem seguir o plano perfeitamente
A IA torna as partes chatas menos chatas
Mas discutir com um LLM é perda de tempo
O mais eficiente é mudar em unidades pequenas, fazer commit quando dá certo, e quando não dá, descartar e tentar de novo
A IA não é solução para tudo, e escolher a ferramenta certa é importante
Se for brincar com uma criança armada, melhor vestir colete à prova de balas
Costumam dizer que ler o código dos outros é mais difícil do que escrever, mas isso me soa estranho
Mesmo uma função que eu levaria meio dia para escrever pode ser lida e revisada em 10 a 15 minutos
Verificar que um código está correto é muito mais fácil do que criá-lo
Simplesmente ler é fácil, mas editar, entender a estrutura e encontrar melhorias exige muito mais esforço
Isso porque o contexto (context) que existia na hora de escrever já desapareceu
Na verdade, não é que ler seja mais difícil; é que as pessoas preferem escrever algo novo
A mentalidade correta é: a IA deixa tudo mais fácil, mas isso em si é uma nova habilidade e é difícil de aprender
Estamos na era ENIAC da IA, e ainda não existem conceitos equivalentes a linguagens de alto nível ou sistemas operacionais
No futuro vai surgir uma disciplina chamada engenharia de contexto (context engineering), e o jeito atual vai parecer primitivo
Se você estruturar bem as coisas, a capacidade da IA parece praticamente ilimitada
Dizer que foi “feito com IA” significa, na prática, “usei em massa recursos de CPU de uma empresa externa”
Até eu ter um agente de IA que eu realmente possua, isso me parece menos progresso real e mais algo próximo de roubo de recursos em escala planetária
A IA não torna o desenvolvimento mais difícil
Na verdade, ela só expõe as partes realmente difíceis que as pessoas vinham ignorando
Nos últimos 15 anos, os desenvolvedores já faziam uma espécie de versão humana do vibe coding — copiando e colando do Stack Overflow, refatorando sem planejamento e trabalhando no estilo “se roda no meu notebook, está bom”
Agora que a IA faz isso, de repente todo mundo quer planejar e escrever testes
Mesmo que fique mais lento, se a qualidade melhorar, isso já é progresso de verdade
A cultura atual de “sprints dentro de uma maratona” está sendo acelerada ainda mais pela IA
Mas a IA sai dos trilhos rapidamente se for usada sem supervisão, e ler código escrito por outra pessoa é muito mais cansativo do que corrigir o próprio código
Pedi para a IA “adicionar testes neste arquivo”, e um arquivo de 500 linhas virou um de 100 linhas
Quando perguntei por quê, ela respondeu que “o arquivo original não existia”
Mostrei o histórico do git, ela pediu desculpas e disse que “deveria ter verificado antes se ele existia”
Ontem eu disse “esqueça esse arquivo”, e ela realmente apagou o arquivo
Um pequeno custo de rollback é aceitável perto do valor que a IA entrega