Menos CV, mais PRs: evidências valem mais que promessas

A real é que qualquer um consegue montar um CV bonito. Evidência pública de entrega mostra quem realmente faz acontecer.

Linus Torvalds e a tese central

No dia 25 de agosto de 2000, Linus Torvalds escreveu uma frase que ficou famosa:

Talk is cheap, show me the code

Link para a mensagem original do criador do Linux: https://lkml.org/lkml/2000/8/25/132

Essa ideia sempre foi simples: falar é fácil; mostrar evidências é outra história.

Hoje, 26 anos depois, com IA gerando código cada vez mais rápido, o papel humano ficou ainda mais sobre direcionar, revisar e definir o que é bom. Falar continua fácil. CV continua fácil. Post no LinkedIn continua fácil. O que me chama atenção é outra coisa: issue bem escrita, PR mergeada, bug corrigido, docs atualizadas, discussão pública e a forma como a pessoa lida com críticas.

A definição de "dev fera" mudou?

Até pouco tempo atrás, muita gente tentava provar valor discutindo linguagem A versus B, "clean code" e outras bandeiras técnicas.

Eu vejo menos valor nisso hoje. A sensação é que entrou IA no jogo e veio junto a voz do Galvão Bueno gritando: "Acabooooooooooou, acabôôôôôôôôôôôôôôô, acabô pros dev que só digitava código!!!!!"

Ferramenta ajuda. IA ajuda bastante. Mas o que separa um dev que faz diferença de um dev que só faz barulho não é quem digita mais rápido, nem quem economiza mais tokens, nem quem está com a ferramenta da moda.

O que faz diferença é saber revisar, orientar, decidir e tirar obstáculo do caminho até a entrega final, em produção e aprovada pelo usuário final.

Tenho orgulho de ser um dev preguiçoso. E, paradoxalmente, isso me levou a ser workaholic por alguns períodos, porque eu queria muito ajudar outras pessoas a desperdiçarem menos tempo em tarefas repetitivas.

Automatizar e comunicar o que foi feito, e o porquê de cada decisão, sempre me pareceu mais importante do que o ato mecânico de programar.

Nunca foi sobre código

Escrevi milhares de linhas de código ao longo da minha carreira, mas meu valor nunca foi só esse. Pelo menos não na forma como eu enxergo meu trabalho. O que sempre me importou foi o conjunto da obra:

• entender o problema
• alinhar expectativa com o time
• tomar decisão boa o suficiente
• entregar
• repetir até o usuário ficar satisfeito

Meu foco sempre foi sucesso do cliente.

E eu acho curioso como muita gente ainda tenta transformar IA no vilão da vez. Se a IA "não presta", às vezes o problema não é a IA. Pode ser o repo, a arquitetura, o harness, ou só a velha mania de culpar a ferramenta da vez.

Antes culpavam PHP, Java ou JavaScript. Agora é Cursor, Claude ou Codex. Muda o nome, mas a cena é parecida.

IA facilita gerar código, não substitui responsabilidade

Hoje qualquer um gera pull request, commit e até um repo inteiro com IA.

Mas a responsabilidade continua humana.

Por isso, comunicar de forma clara e acionável importa ainda mais para usar e coordenar agentes de IA. Quem não consegue deixar o objetivo claro tende a coordenar mal.

Como revisor, eu sinceramente não ligo se a PR foi escrita com Claude, Cursor, Codex, gh cli, GitHub REST API ou GitHub.com no navegador. O meio não me interessa. O que me importa é a qualidade do artefato:

• o problema está claro?
• a solução faz sentido?
• a mudança está bem explicada?
• o review básico foi feito pelo autor?
• regras da equipe, repo, CI, foram validadas?
• a decisão está documentada

Quando alguém me pede review, eu valorizo muito mais quando dá pra ver que a pessoa já revisou o próprio trabalho antes de chamar a equipe. Não precisa estar perfeito. Mas precisa parecer que alguém pensou antes de apertar o botão de "pedir review".

Eu gosto quando a pessoa chega segura da própria entrega e com orgulho do que fez. Antes de pedir revisão, a melhor postura me parece ser: "já revisei, acho que isso aqui está bom, mas talvez eu ainda tenha deixado passar alguma coisa; vou ficar atento ao review".

Código não basta para reputação

Pull request mergeada com nova feature, bug reportado com passos para reproduzir, issue resolvida e documentação melhorada na branch principal: isso é entrega.

E, do mesmo jeito que comentário bom de código explica intenção e decisão em vez de narrar o óbvio, um dev também é julgado pela comunicação:

• título da PR
• descrição da PR
• como responde a revisores
• documentação atualizada
• README e demais .md alinhados com a decisão tomada

E se eu for júnior ou só tiver trabalhado em repos privados?

Se eu estivesse nessa situação, eu não perderia muito tempo com site bonitinho ou postagem aleatória em rede social. É difícil ganhar atenção e fazer a diferença assim, em um mundo onde há tanto ruído pela web.

Eu iria para contribuição real. Se der, também acho bom fortalecer OSS BR. Tem lista boa aqui: https://awesomeyou.io/

Mas open source não é trabalhar de graça pros outros?

É uma troca, como quase tudo nessa vida. Tem gente que vê open source assim. Eu entendo. Mas eu acho uma visão curta demais.

Você amplia repertório e para de achar que o mundo é só o que apareceu dentro das empresas onde trabalhou.

De quebra, ganha evidência pública de que sabe entregar algo de ponta a ponta, comunicar bem, defender seu ponto de vista, lidar com sugestões e não largar o trabalho no meio do caminho.

Em muitos casos, a revisão de PR vira mentoria na prática: você aprende com o feedback, melhora seu padrão e constrói algo verificável publicamente.

Se você vira mantenedor, aprende outro jogo: mentorar, dar feedback, ter paciência, sustentar qualidade e saber dizer não quando uma PR é boa, mas não encaixa nos objetivos do projeto.

Conclusão

Eu vejo muita gente boa sendo encontrada por empresas, founders e tech leads justamente por ter rastro público de entrega.

Às vezes isso vira freela.
Às vezes emprego.
E já vi isso se tornar algo maior para colegas meus, como convite para virar sócio ou co-founder de uma startup, porque o founder ou CEO gostou da forma como a pessoa se comunicava em PRs, GitHub discussions e Discord.

No fim, eu sugiro que candidatos pensem como quem contrata: não interessa tanto o que a pessoa diz que quer aprender. Interessa o que ela já consegue provar.

Se você estivesse contratando, você não escolheria alguém só porque "quer aprender".
Você não pagaria salário só porque alguém quer entrar na sua empresa ou equipe, ainda mais se essa pessoa nem saiu da zona de conforto e talvez nem tenha aprendido a usar uma das partes mais úteis do GitHub: pull request.
Você olharia para evidência de entrega, autonomia e capacidade de trabalhar com gente de verdade.

E, claro, você também estaria disposto a treinar e ajudar a pessoa a evoluir.
Mas ainda esperaria ver iniciativa, comunicação, disciplina e trabalho em equipe demonstrados de algum jeito.
Isso raramente aparece de verdade em duas ou três videochamadas rápidas.

Se em poucos minutos você consegue mandar links de PRs, issues, docs ou discussões públicas que provem isso, você já está à frente de muita gente que só tem CV, pose e promessa.

E, claro, se você prefere viver de recruiter call, vaga em empresa grande e promessa de crachá bonito, tudo bem também.

Só não confunda isso com o discurso de que "IA acabou com os devs".
O que ela acabou com muita força foi com a ilusão de que só saber codar já bastava para encontrar trabalho e manter uma boa remuneração.