Se um sênior é só alguém que decorou sintaxe e comando de bash, o que sobra dele depois que a IA faz isso mais rápido e sem reclamar?
A resposta dessa pergunta vai explicar muitos sintomas que estamos vendo no mundo do desenvolvimento, e agora em especial no open source. Estamos tentando ficar sem falar de IA, mas ela está no centro de uma briga que tá rolando agora, com direito até de um artigo do DHH que eu quero destrinchar com você. Porque ele tocou num ponto que precisava ser dito.
Tem diversos projetos sérios colocando regras pra barrar contribuição feita com ajuda de agentes de IA. NetBSD, Zig, Flathub são alguns exemplos. A “nobre” justificativa é sempre a mesma: é pela qualidade, é pela atribuição, é pra proteger quem tá aqui há mais tempo.
Na contramão, o DHH deu um nome pra esse movimento: neoludismo. Segundo ele, isso é ressentimento disfarçado de princípio, quase um “como você ousa fazer software sem penar o que eu penei pra aprender. Você não entende o valor de um software de verdade”. É como cravar um portão no meio do campo aberto. Não há o que proteger. Esse controle não segura código ruim, não segura código malicioso, só obriga quem contribui, de boa fé, a parar e se curvar a vontade de um petit-comité. Uma medida de proteção que não protege coisa alguma.
Aquela pergunta lá do começo — o que sobra de um dev sênior quando a IA faz o trabalho ‘braçal’ — não é apenas retórica. Pra muita gente, ver a contribuição com IA, com aquela assinatura de ‘Made with’, crescer e se espalhar pela internet dói quase como uma ofensa pessoal.
Pra alguns o que é “ser programador”, em sua essência, é um aglomerado de várias coisas meio banais, que passamos durante anos aprendendo: decorar comandos, saber sintaxe na ponta dos dedos sem olhar a documentação, ou até aquele truque que aprendemos num momento de sufoco, navegando entre páginas pouco referenciadas em fóruns da internet. Anotamos isso num bloco de notas pra não esquecer e falamos disso para nossos amigos como se fosse uma medalha.
Isso pode até ter seu valor como parte da trajetória, mas dizer que isso é o que faz “o prazer de ser programador” é forçar a barra. Eu preciso aqui falar o óbvio: ser programador não é ser um mero digitador com boa memória e fidelidade ao contexto. Você não é a sua capacidade de escrever código.
Agora que a IA entrega algo similar com um prompt curto, usando um modelo bom e barato como o Sonnet ou o Grok 4.5, o jogo muda de figura. O valor sai da quantidade de código e vai pro critério por trás dele, e quem tem critério só tende a valer mais. Mas talvez, pra esses alguns devs, o que esteja em perigo seja a própria identidade como desenvolvedor: “Se qualquer um consegue o que eu levei anos pra ter, o que é que eu sou agora?”
Ninguém vai admitir isso publicamente, claro. Alguns podem até dar outros argumentos que validam esse ponto de vista: o de qualidade, da propriedade intelectual (já que uma ferramenta consegue escrever um código IGUAL ao escrito por um engenheiro sênior), ou da resistência contra uma suposta precarização do trabalho de desenvolvedor, e simplesmente fecham o portão. Esse tipo de dev, que torce pra bolha da IA estourar e tudo voltar a ‘ser como era antes’, vê um baita apoio em medidas assim.
Agora, pra não soar hipócrita ou coach de marketing (nesse contexto, praticamente sinônimos), eu sei que o problema que esses mantenedores apontam, a tal falta de critério, é real. Existe muito dev sem critério, contribuidor sem contexto e gente atrás de quinze minutos de fama abrindo PRs replicados, como se cada um tivesse repetido o feito do Mythos no FFmpeg. Rodar um agente não é nem de perto atingir esse tipo de resultado. E isso enche o saco de quem mantém projetos open source: cada PR repetido é tempo perdido, resposta repetida, agora de forma acelerada.
O próprio Linus Torvalds concorda com esse argumento. Ele reclamou que a lista de segurança do kernel virou quase ingerenciável de tanta duplicata: todo mundo achando o mesmo bug com a mesma ferramenta. O curl encerrou o programa de recompensa; o slop de IA foi um dos motivos, junto com relatórios humanos piores e incentivos ruins do bounty. Não estamos falando aqui de teoria da conspiração. A fila de trabalho de quem mantém disparou.
O mantenedor tem o direito de recusar, e ainda bem. Recusar código ruim é o trabalho de quem mantém qualquer projeto sério. O que não se sustenta é culpar uma ferramenta sem nem olhar o código entregue. Para entendermos melhor sobre isso podemos fazer um paralelo: como os Estados Unidos passaram anos comprando mel “falsificado” sem nem desconfiar, e como isso tem tudo a ver com código gerado por IA.
No começo dos anos 2000, os Estados Unidos apertaram o cerco ao mel chinês, com tarifas antidumping pesadas e, pouco depois, um alerta do FDA por antibiótico proibido em parte das cargas. Isso não resolveu o problema e só piorou. O mesmo mel passou a chegar pela Índia, pelo Vietnã, com rótulo trocado e até tambor repintado. Para rastrear a origem, o pólen é a principal pista de onde o mel veio. Então a China passou a ultrafiltrar o mel pra tirar todo o pólen. Sem pólen, provar a origem virava quase impossível. Cada vez que a fiscalização achava um jeito de rastrear, o esquema achava um jeito mais elaborado de apagar o rastro.
Regra contra “código feito por IA” faz exatamente isso. A impressão digital aqui são os vestígios de um modelo. Quem quer burlar dá um jeito: reescreve, limpa, entra invisível. Quem é pego é o contribuidor de boa fé que declarou o uso. O próprio Linus já falou isso: quem produz slop não vai carimbar o patch como slop.
Mas repara na saída que o Linus deu. Ele não fechou o portão pra quem usa IA, muito pelo contrário. Como maintainer-chefe do kernel, ele bateu o pé do lado oposto: o Linux não é um desses projetos anti-IA, e quem não estiver satisfeito que faça um fork ou siga seu caminho. Pra ele, IA é uma ferramenta como qualquer outra, e das mais úteis. Quem ainda duvida disso é porque não usou de maneira séria e profissional. Ele mesmo usa: gerou código com um assistente num projeto pessoal.
A régua proposta é simples: rejeite código ruim por ser ruim, não por ter nascido de um modelo. Quem aperta o Criar Pull Request responde pelo que enviou.
“O Linux não é um projeto anti-IA. Quem tiver problema com isso que faça um fork. Ou vá embora.” (Linus Torvalds, na lista do kernel)
Eu vivi isso na pele. Mandei um PR pro RubyLLM feito com o Claude, testado e com critério, achando que tava bom. O Carmine Paulino olhou e viu que ali precisava de uma mudança mais séria do que eu tinha proposto: fechou o meu PR, agradeceu a iniciativa e escreveu uma solução própria, menor e específica pro protocolo. Ninguém me acusou de usar IA. E o que valeu ali não foi o código ter entrado, porque não entrou. Foi o caminho: achei um problema real, formulei uma hipótese, testei, submeti, levei um não bem fundamentado e vi nascer uma solução melhor por causa disso. É contribuir, no melhor sentido da palavra, e não colecionar achievements pessoais por ter escrito cada linha na mão.
No fundo, só há dois caminhos. Ou você mantém o padrão e recusa código ruim venha de onde vier, ou você bane a ferramenta. Não existe terceira via: barrar um dev que usou IA é o mesmo que barrar apenas a IA, mas com um verniz de curadoria por cima.
Tem uma frase pedante que todo marketeiro adora repetir pra vender curso: “um grupo seleto não quer que você saiba disso”. Isso me dá preguiça de ouvir. Mas dessa vez, que ironia, é quase verdade, só que esse segredo não é nenhum conhecimento escondido. Uma mera reserva de mercado, pura e simples, e bem sem-vergonha.
O acesso difícil à informação guardava uma coisa só: a sensação de ser um dos poucos que dominavam ‘a arte de escrever um bom código’. Quando a IA baixou drasticamente o custo da entrada, essa vaidade de ter sido raro foi embora. A competência continua valendo exatamente o mesmo, ou até mais. Como o designer que torcia o nariz pro Canva uns anos atrás e hoje reclama de imagem gerada por IA, incomodado apenas com o fim da própria raridade.
Esse apego ao que poderíamos facilmente classificar como “propriedade intelectual” quase sempre não quer dizer nada. O Stephan Kinsella tem um argumento que eu gosto muito.
A propriedade existe pra resolver brigas por coisa escassa: se eu como a sua maçã, você não come. Mas uma ideia, ou habilidade, não é assim. Usar a sua ideia não a tira de você: os dois ficam com versões completas dela. Logo, cercar uma ideia é inventar uma escassez que não existe no mundo real. Um exemplo real e atual: a SpaceX provou que dava pra pousar e reusar um foguete; dez anos depois, a China fez o mesmo e virou o segundo país a recuperar um propulsor orbital. Aprenderam com o caminho percorrido, e a SpaceX não perdeu nada com isso: segue lançando e reusando num ritmo que ninguém nunca alcançou.
Sintaxe, comando de bash, o padrão que você decorou. Tudo isso é copiável, e nunca foi de fato seu. O que é escasso mesmo, o que ninguém clona, é o seu julgamento: achar o problema que vale a pena resolver, ler o contexto do produto, escolher entre soluções que parecem todas funcionar, aceitar revisão e jogar fora o próprio código quando precisa, e responder pelo que foi pro ar. Isso não sai em nenhum diff, e nenhum prompt mágico vai gerar no seu lugar.
E é por isso que a democratização do pensamento só assusta quem não tinha senso crítico, apenas uma decoreba ou livro de estimação. Quem tem critério não perde nada quando a sintaxe vira commodity. Qualquer ferramenta só amplia o que já estava ali. É o que aconteceu com a chegada da Internet, mas num nível ainda maior de acesso.
Podem copiar o seu código, com ou sem IA. Copiar o que você sabe, copiar o jeito que você faz. Mas, ser você, ter as suas ideias, isso não dá pra clonar.
Eu escrevi um tempo atrás que os deuses desceram do Olimpo: que engenharia nunca foi coisa de divindade, sempre esteve aqui embaixo, com a gente. O DHH acabou de provar isso de fora, sem querer. Deixo o link pra quem quiser o argumento inteiro.
Até a próxima!
Ainda não há comentários. Seja o primeiro a comentar!