Código com cicatriz: craftismo no desenvolvimento na era da IA

Outro dia abri o PR e não soube dizer quem tinha escrito

Era um PR meu. Eu sabia que era meu porque o autor no GitHub era eu. Mas se você tirasse o avatar e me mostrasse o diff sem contexto, eu juraria que era de qualquer outra pessoa do time. Ou de ninguém. Porque a verdade é que metade daquilo eu tinha aceitado da sugestão do Claude sem nem ler direito. Tava cansado, o teste passou, segui em frente.

E ali eu percebi uma coisa meio estranha de admitir: faz tempo que eu não escrevo código que parece meu.

Não que eu tenha parado de programar. Eu programo o dia inteiro. Mas o que sai do outro lado é cada vez mais... genérico. Funciona. Passa no CI. Segue o style guide. E poderia ter sido escrito por qualquer pessoa, em qualquer empresa, em qualquer linguagem com a mesma popularidade no GitHub.

Provavelmente foi.

Não é plágio. É algo mais sutil. É código que entrega o resultado certo e não conta nada sobre quem o produziu. Vou tentar explicar com três expressões que venho usando comigo mesmo.

Código de catálogo

Pensa no móvel de IKEA. Cumpre a função, é razoável, está em milhões de salas. E é exatamente igual em todas elas.

Existe um equivalente disso em software. Funções, controllers, hooks que vieram inteiros do scaffold, do snippet, do completion. Cobrem o caso, passam no lint, atravessam o review sem comentário. E poderiam estar em qualquer outra base de código sem ninguém perceber.

Esse é o código de catálogo. Não é ruim. É só impessoal de um jeito que dá pra reconhecer de longe quando você presta atenção. Não tem nenhuma decisão visível ali porque nenhuma decisão difícil precisou ser tomada. O caminho do meio venceu por andar primeiro.

A IA produz esse tipo de código por padrão, mas não inventou o problema. Antes de IA, a gente já entregava muito código de catálogo escrito à mão. Só era mais lento e a gente conseguia fingir que tinha pensado.

Caligrafia

Se você lê código de gente que conhece bem o domínio, dá pra perceber a pessoa antes de olhar o git blame. Tem alguma coisa no jeito de nomear, no jeito de quebrar a função em duas, no que vira tipo e no que vira string. É caligrafia.

Caligrafia em código não é vaidade autoral nem firula de senior. É o subproduto de alguém ter pensado no problema antes de escrever a primeira linha. A escolha estava lá antes do código existir, e o código carrega o eco dela.

Quando uma equipe inteira começa a escrever no mesmo estilo, dois caminhos são possíveis. Ou aquele estilo é uma decisão coletiva tomada com cuidado, com nome e razão (e aí virou cultura técnica), ou todo mundo está copiando o template do create-app e chamando isso de padronização. Os dois resultados são idênticos olhando de fora. A diferença é se alguém consegue explicar.

Cicatriz

A palavra que eu mais gosto de usar pra isso vem da cerâmica japonesa. Kintsugi é a técnica de consertar peças quebradas com ouro: em vez de esconder a fenda, ela é destacada. A peça não volta a ser nova. Vira outra coisa, com história visível.

Em código, a cicatriz é o trecho onde a decisão difícil ficou registrada. O comentário curto que diz "fizemos assim porque a alternativa óbvia tinha problema X". O ADR de duas páginas que documenta por que a equipe escolheu fila em vez de chamada síncrona. O nome de função meio esquisito que faz sentido depois que alguém te conta a história do bug que originou aquilo.

Cicatriz não é gambiarra. Gambiarra é a remenda escondida que envergonha. Cicatriz é a remenda assumida. A primeira você esconde no git stash da memória; a segunda fica como aviso pro próximo que passar por ali.

Toda base de código que envelhece bem tem cicatriz. As que envelhecem mal tentaram parecer novas a vida inteira.

Sobre usar IA sem ser usado por ela

Em 1928, Oswald de Andrade escreveu um manifesto curto e raivoso defendendo que cultura brasileira boa não é a que copia a europeia, nem a que finge que não foi influenciada por ela. É a que come, digere e cospe outra coisa. Antropofagia.

Acho que é uma das poucas posturas honestas pra quem programa em 2026.

Eu uso Claude Code todo dia. Tenho o Zed aberto. Não vou voltar a digitar tudo na mão por princípio, e quem faz isso pra parecer puro tá mais preocupado com a estética da resistência do que com o trabalho em si. A IA é absurdamente boa nos 80% chatos do código. Recusar isso por orgulho me parece desperdício.

A questão pra mim não é mais se eu uso IA. É quem assina embaixo do que sai.

Eu venho prestando atenção em três jeitos diferentes de receber uma sugestão dela:

O primeiro é aceitar porque funciona. A IA escreveu, o teste passou, o PR foi. Eu fiz isso semana passada e vou fazer de novo amanhã. Não tem nada de errado com isso pra código de plumbing, pra teste de regressão, pra glue code. O problema é quando vira default em código de domínio, no lugar exato onde sua opinião deveria estar visível.

O segundo é aceitar porque coincide. A sugestão chega, eu leio, e reconheço como o caminho que eu mesmo escolheria. A IA não decidiu por mim, ela só escreveu mais rápido a decisão que eu já teria tomado. Esse é o ganho real do dia a dia. Eu economizo trinta minutos pra brigar com um problema que valia trinta minutos de briga.

O terceiro é o que eu acho mais raro e mais importante. A sugestão chega, é razoável, talvez até "melhor" em algum eixo abstrato (mais idiomática, mais curta, mais Stack-Overflow-aprovada), e ainda assim eu rejeito. Porque sei alguma coisa sobre aquele domínio que ela não sabe e talvez nunca vá saber: o histórico do bug que vai surgir, a próxima feature na fila, a manha do banco de dados, a opinião do PO sobre o fluxo. Aí eu reescrevo, deixo um comentário curto explicando, e fica a cicatriz.

Os três jeitos são válidos em momentos diferentes. O problema não é nenhum deles isoladamente. É só ter o primeiro, e ele virar o default sem você perceber.

Como uma cicatriz se parece na prática

Não é nada elaborado. Geralmente é um comentário no lugar onde a maioria das pessoas (e quase toda IA) não escreveria nenhum:

// Retornamos Result<User, AuthError> em vez de lançar exception
// porque autenticação falha o tempo todo no fluxo normal.
// Não é caso excepcional, é caso de domínio. Queremos forçar
// o caller a tratar a falha no fluxo, não no catch lá em cima.
async function authenticate(
  credentials: Credentials,
): Promise<Result<User, AuthError>> {
  // ...
}

Repare no que esse comentário não faz. Não explica o que o código faz, porque o tipo já explica. Não cita caller específico, porque caller muda. Não pede desculpas pela escolha. O que ele faz é registrar que houve uma escolha, qual era a alternativa rejeitada, e o porquê em uma frase só.

Daqui a dois anos, quando alguém (humano ou IA) propuser refatorar pra usar exception "porque é o pattern padrão", o comentário responde antes da pergunta. Sem ele, o pattern padrão vence por inércia. E a caligrafia some.

A parte que pode irritar quem lê: comentário desse tipo não aparece em código gerado por IA, nem em code review feito às pressas. Ele aparece quando alguém parou trinta segundos pra pensar "se eu sumir, alguém vai entender por que isso está aqui?". Trinta segundos.

A obra é a cicatriz

A obra da Lina Bo Bardi não impressiona pela perfeição. Impressiona porque você vê a decisão dela em cada material exposto. Concreto bruto que outro arquiteto teria revestido. Vão estrutural que alguém com menos coragem teria fechado. Nada ali é resultado de "aceitar a sugestão padrão".

Software bom funciona do mesmo jeito. Quando você lê o código de uma equipe madura, dá pra ouvir as conversas que aconteceram pra chegar naquilo. As escolhas estranhas têm explicação. As abstrações têm donos. As decisões têm peso.

Código de catálogo é o oposto. É código sem ninguém dentro.

E daí?

Não estou pregando que você escreva menos código, nem que rejeite IA, nem que volte a usar vim puro pra mostrar serviço. Tudo isso é teatro.

Estou dizendo que existe um custo escondido em aceitar a primeira sugestão que funciona, e ele não aparece no PR de hoje. Aparece daqui a um ano, quando ninguém mais sabe por que o sistema é do jeito que é, porque ninguém decidiu que ele fosse assim. Ele só foi convergindo pra média.

Agora que a IA escreve código que compila, passa em testes e segue patterns, sobrou uma única coisa que ainda diferencia um engenheiro de outro: gosto técnico. Saber por que esse caminho e não o outro. Saber qual default aceitar e qual cicatrizar.

Se não for isso, francamente, o que mais é?

---

Referências

• Manifesto Antropófago, Oswald de Andrade, 1928
• Kintsugi, a técnica japonesa de assumir a fratura
• Lina Bo Bardi, Instituto Bardi | Casa de Vidro, arquitetura como decisão visível
• Architecture Decision Records, onde cicatrizes maiores moram