Só o Cleiton consegue dar manutenção nessa tralha!

Tem uma frase que eu ouço no mundo da tecnologia há anos e que, toda vez que aparece, aluga um triplex na minha cabeça e passa alguns minutos me convencendo de que eu talvez não seja capaz de resolver aquilo:

“Só o Cleiton consegue dar manutenção, porque foi ele que fez.” Coitado desse Cleiton, virou desculpa para tudo.

Eu sei que, muitas vezes, a frase nasce sem maldade. Às vezes é só uma tentativa rápida de explicar que o sistema é complexo, que falta contexto ou que a pessoa que desenvolveu conhece atalhos que os outros ainda não conhecem. Mas o efeito que ela provoca em mim é quase sempre o mesmo. Por alguns instantes, eu me sinto incapaz de atravessar aquele território, como se existisse uma senha secreta que só o Cleiton recebeu.

Depois passa. E quando passa, vem uma pergunta que me acompanha há anos. Por que continuamos tratando isso como algo normal?

Porque, se só quem criou consegue dar manutenção, a dificuldade não está apenas em quem está tentando entender. Pode ser que quem vai assumir ainda esteja aprendendo a ferramenta, claro. Pode ser que o contexto tenha se perdido. Pode ser que a entrega tenha acontecido sob pressão, com prazo curto, cliente cobrando, documentação ficando para depois e todo mundo fingindo que depois existe.

Claro que existe pressão de prazo. Claro que, em alguns momentos, chamar quem desenvolveu é o caminho mais rápido. Também não dá para fingir que a solução é simplesmente jogar qualquer pessoa em qualquer código e esperar que ela resolva tudo na marra. Confiança sem critério pode virar irresponsabilidade, e ninguém deveria ser colocado para dar manutenção em algo crítico sem contexto, apoio ou alguma chance real de entender o terreno onde está pisando.

A distorção começa quando esse atalho vira modelo de gestão. Quando ninguém mais recebe tempo, contexto ou confiança para aprender a manter aquela solução, a liderança que repete essa frase não está protegendo o sistema. Está normalizando uma dependência.

E é aí que a frase começa a me incomodar de verdade. Porque urgência sempre existiu e, em muitos ambientes, parece até fazer parte do mobiliário. A questão é usar essa urgência como desculpa permanente para manter uma solução técnica presa à cabeça de uma única pessoa.

Compartilhar conhecimento não é só fazer uma reunião de passagem. É dar chance real para que outra pessoa toque, erre com supervisão, entenda o raciocínio e ganhe intimidade com aquilo. Sem essa confiança, a frase “só o Cleiton consegue” deixa de ser diagnóstico e vira profecia autorrealizável. E, dependendo de como isso é dito, ainda desmotiva quem poderia aprender, porque antes mesmo de tentar a pessoa já recebeu o recado de que aquele território não é para ela.

Mas também pode ser que a solução tenha nascido complexa demais, acoplada demais, dependente demais da cabeça de uma única pessoa. E aí a frase deixa de ser uma explicação técnica e vira um alerta de risco.

Não estou falando de quem ainda está aprendendo e escreve um código torto porque está tentando sobreviver à própria curva de aprendizado. Todo mundo já fez coisa deselegante. Eu certamente já fiz, ainda faço às vezes, reviso, melhoro e provavelmente só percebo algumas escolhas ruins quando preciso voltar nelas meses depois ou quando algum colega percebe e me dá um toque. Quem trabalha com tecnologia por tempo suficiente tem um cemitério particular de decisões que prefere não revisitar.

O meu incômodo é outro. É quando a dependência de uma pessoa vira argumento de autoridade. É quando alguém diz “só o Cleiton mexe nisso” como se estivesse protegendo o sistema, quando na verdade pode estar apenas admitindo que a solução não foi construída para sobreviver ao próprio autor.

Para mim, uma boa solução técnica precisa deixar rastros. Não precisa ser óbvia para qualquer pessoa em cinco minutos, porque isso seria ingenuidade. Mas precisa ter alguma clareza de intenção, alguma organização, algum caminho possível para que outro profissional consiga entrar, entender, questionar, corrigir e evoluir sem precisar fazer arqueologia emocional no código dos outros.

Durante muito tempo, carreguei como mantra aquela frase: “qualquer idiota consegue escrever código que o computador entende. Bons programadores escrevem código que humanos entendem”. Para mim, essa frase nunca foi só sobre código bonito. Era sobre responsabilidade. Era sobre não transformar conhecimento técnico em propriedade privada. Era sobre lembrar que alguém, em algum momento, vai precisar voltar naquela solução para corrigir, adaptar, auditar, reaproveitar ou simplesmente entender o que foi feito.

Por isso essa discussão fica ainda mais importante agora. Com IA gerando código, fluxo, script, consulta, expressão e automação, fazer algo funcionar tende a ficar cada vez menos raro. Mas isso não elimina o desafio da manutenção. Em alguns casos, pode até aumentar.

Porque o Cleiton já está mudando de forma. Antes, era a pessoa que escrevia o sistema e levava o conhecimento embora na cabeça. Agora, cada vez mais, pode ser uma IA gerando uma solução aparentemente funcional, mas que ninguém da equipe entende direito. Nem quem pediu. Nem quem copiou. Nem quem ajustou. Nem quem colocou em produção.

E aí a situação deixa de ser apenas “só o Cleiton consegue dar manutenção”. Pode virar algo ainda mais estranho. “Ninguém sabe exatamente por que isso funciona, mas está funcionando.”

Então o mantra não está sendo abandonado. Está amadurecendo. Qualquer IA consegue gerar código que funciona. Bons profissionais usam IA para criar soluções que podem ser compreendidas, mantidas e evoluídas. E bons líderes criam ambientes onde esse conhecimento circula, onde a confiança é construída com critério e onde “só o Cleiton consegue” não vira destino, nem é substituído por “a IA fez assim”, mas tratado como um risco a ser reduzido.

Para quem lidera equipes, quando você diz “só o Cleiton consegue dar manutenção”, está descrevendo uma situação temporária ou aceitando uma dependência que deveria estar tentando reduzir?

Para quem já ouviu essa frase, quantas vezes você deixou de tentar entender, aprender ou assumir uma solução porque alguém já tinha decretado que aquele território pertencia ao Cleiton?

#Software #CodigoLimpo #CleanCode #GestaoDeConhecimento #LiderancaTecnica #DesenvolvimentoProfissional #Automacao #Tecnologia