15

Minha resposta honesta é: IA destrói sua capacidade de raciocinar.

Na semana em que descobri o Claude Code em novembro do ano passado, eu quase não consegui dormir. E não sou o único. O Armin Ronacher, criador do Flask, descreveu Claude Code como “catnip for programmers” por que passou pela mesma coisa. O Simon Willison repetiu essa frase ao falar de agentic coding. É exatamente essa sensação: você fica energizado, confuso, viciado em transformar ideias em código funcional.

Eu comecei com o plano de 20. Durou 15 minutos. Nem pestanejei e passei para o de 200. Durou três dias e eu estourei o limite da semana. Ainda tentei me segurar. Aí teve um dia em que simplesmente não consegui: fui lá e paguei o de 1000. Droga pesada, passe longe se puder...

Desde então eu uso IA pesada para programar, com fluxo 100% autonomo com multiplos agentes em paralelo.

Descobri que a IA não é uma ferramenta de produtividade, mas uma máquina de criar dívida cognitiva.

Você ganha velocidade hoje e paga depois tentando entender o que foi gerado, por que foi gerado, onde quebrou, por que a arquitetura ficou torta, por que aquele arquivo agora tem 800 linhas, por que o teste passa mas o bug aparece, por que a solução funciona mas você não conseguiria explicar como.

O pior: muitas vezes vale a pena.

O problema é que a IA transforma ideia em protótipo rápido demais. Rápido demais para seu cérebro de primata acompanhar.

Tem prototipo que eu fiz naquela primeira semana e até hoje estou pagando o débito cognitivo. Mas a verdade é que, sem o agente, eu nem teria tirado a ideia do papel.

Então minha visão hoje é mais ou menos assim:

Em quais etapas do desenvolvimento a IA realmente ajuda vocês?

Todas, menos pensar por você.

Ela ajuda a explorar repositorios, escrever código, gerar teste, ler log, fazer refactor gigantes, escrever documentação. E Debugar. Essa vejo pouca gente falando e é onde mais brilha, porque não cria débito cognitivo.

Vocês usam mais para estudar, debugar, escrever código, revisar PR, criar documentação, pensar arquitetura ou gerar ideias?

Para gerar lixo.

E isso não é necessariamente uma crítica.

Todo software começa como lixo. O problema é esquecer que é lixo. IA é ótima para produzir massa bruta: código inicial, rascunho, primeira versão. Ela te dá matéria-prima.

O trabalho do programador continua sendo transformar aquilo em software.

Em projetos web, mobile, apps ou games, onde a IA mais economiza tempo?

Não sei opinar muito sobre web/mobile/games porque so tenho usado para ferramentas CLI: automação e compiladores.

E aí a vantagem é brutal, porque CLI é o tipo de coisa que agente usa bem: entrada clara, saída clara, teste rápido, erro visível, loop curto. O agente roda comando, vê falha, corrige, tenta de novo.

Quanto mais fechado, determinístico e testável for o ambiente, melhor a IA trabalha.

Como vocês validam se o código gerado faz sentido?

Gastando até 40x (medidas minhas) o tempo que a IA levou para gerar o lixo, refatorando aquilo até virar algo meu.

A IA gera um programa inteiro de 10k linhas de código em segundos. Entender aquilo vai levar semanas.

Minha validação é: leitura linha por linha: simplificação agressiva, remoção de abstração inútil, apagar metade, reescrever a parte que presta, rodar em casos estranhos, remover dependências. E principalmente perguntar: “eu conseguiria manter isso daqui sem IA?”.

Se a resposta é não, ainda é apenas uma sugestão da maquina e não código meu.

Vocês têm alguma regra pessoal para não perder prática?

Sim: um dia por semana fazer tudo sem IA. Zero. Sem autocomplete inteligente, sem ChatGPT, sem agente.

É musculação cognitiva. Você descobre muito rápido como seus músculos mentais atrofiaram.

Acham que IA acelera o aprendizado ou pode atrapalhar se for usada do jeito errado?

As duas coisas.

Para quem já trabalha na área: o uso de IA mudou a forma de codar, pesquisar ou resolver problema?

Sim e não.

Mudou tudo, mas não mudou nada.

Tem uma máxima antiga (1983) no mundo de software:

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.

Só que agora, com IA, a proporção mudou. Não é mais 90/10. É mais perto de 99/1. Você olha e pensa: acabou. Não acabou.

Depois que você vira vibe coder, você entra no jogo de perseguir a dívida cognitiva. Essa passa a ser sua vida.

Você cria mais. Você testa mais.
Você refatora mais. Você apaga mais.
Você entende menos no começo. Você precisa entender muito mais no final. É maravilhoso. E é meio miserável também.

Carregando publicação patrocinada...
2
1
1

Excelente comentário, mas trago aqui algumas reflexões/provocações:

  1. Será que o código gerado via vibe coding precisa ser realmente lido por um dev?
  2. No caso de vibe coding, ao invés de comsertar o código gerado não seria o caso de verificar/corrigir as especificações para que a IA gerede um código mais próximo do seu gosto?
  3. Não seria o caso de passar seu padrão para a IA seguir ao invés de deixar ela livre e depois correr atrás do prejuízo?

Código virou commodity, já arquitetura ainda continua um trabalho cognitivo e de valor.

1

Acho que aqui mora uma ilusão perigosa: achar que esses monstros idiotas seguem especificação de verdade. rs

Eles seguem o suficiente para parecer que seguiram.

Código gerado via vibe coding não precise ser validado por um humano em todos os contextos. Se é um script descartável, uma automação pessoal, uma landing page sem consequência, uma PoC para testar ideia, beleza. Gera, roda, funcionou, vida que segue.

Mas se aquilo vai para produção, mexe com dinheiro, vidas ou qualquer coisa minimamente séria, alguém precisa entender o que esta acontecendo.

Porque, se der problema, não é o CPF do Claude que vai pagar. É o seu.

O ponto não é “validar código gerado” como se isso fosse o fluxo ideal. O provlema é que código gerado vira software. E software tem custo de manutenção e suporte.

E nem para por aí, se é para fazer um prompt decente para a IA, você precisa entender o código que já existe. Precisa saber o que proibir, onde simplificar, onde abstrair, onde o que testar, onde isolar, onde apagar.

Se você não entende o código, você também não entende o prompt que iria extrair o máximo da ferramenta.

“Código virou commodity” é uma frase incompleta. Código ruim virou commodity. Código plausível virou commodity. Código que compila virou commodity. Código que passa em teste feliz virou commodity.

Software bom não virou commodity.

E aqui vale lembrar o Linux.

O Linux não deu certo porque qualquer um joga patch no kernel e torce para compilar. Deu certo porque o Linus conhece o bicho que mantém. Ele sabe onde mexer, onde não mexer, que tipo de gambiarra é aceitável e que tipo de “solução elegante” vai virar um gargalo daqui seis meses depois.

Ele já deixou claro: não importa se o patch veio de humano ou de IA. O que importa é que ele (ou alguém de sua confiança) revise, entenda e assine embaixo.

Essa é a parte que muita gente ignora “código virou commodity”.

Gerar código é barato. Colocar código em produção ainda é caro.

E muito provavelmente daqui a cinco anos isso nem seja mais relevante. Talvez o custo de escrever qualquer solução do zero seja menor que o custo de manter um software bom legado.

Mas hoje ainda não é assim.

1

Quem entedeu isso aqui, entendeu o futuro da programação com IA: "Quanto mais fechado, determinístico e testável for o ambiente, melhor a IA trabalha."