O profissional insubstituível

Uma mentira que alimentamos...

Segunda-feira, 09h da manhã. Deploy em produção. Todos os devs na call e alguém solta: "Ninguém é insubstituível mesmo.". Todo mundo fica em silêncio... e a pessoa continua: chegou o e-mail do desligamento de um brother do time. Aquele silêncio pesado.

Pois é, e eu achava esse colega essencial no time. O problema é que dois meses depois, ninguém mais lembrava o nome dele...

Ora ou outra, ouvimos essa frase. E, sinceramente, em algumas situações ela nos faz acreditar nela. O principal setor que alimenta essa narrativa de que "ninguém é insubstituível" é o mercado de trabalho, porque não importa o quanto você atue, execute múltiplas tarefas, seja o primeiro a chegar e o último a sair: sempre haverá outra pessoa que consegue entregar o mesmo que você, ou até mais.

Um erro que eu cometi foi achar que, quando eu saísse de uma empresa (principalmente por falta de reconhecimento), ela iria sentir de alguma forma. E vamos ser sinceros: lá no fundo, existe um desejo de descobrir que a empresa passou por dificuldade depois que você saiu. E isso é puro ego. A verdade que dói é que não somos insubstituíveis no mercado de trabalho, e possivelmente a empresa nem sentiu a nossa falta. Com o tempo, a maturidade chega, e percebemos que, se a empresa não reconhecia nosso valor, talvez fosse simplesmente uma questão de alinhamento. Não é pessoal. É mercado.

Essa sempre foi a regra do jogo. Até que veio a inteligência artificial e reescreveu tudo.

O cenário assustador

Hoje, em tech, quem não usa IA está ficando pra trás em produtividade. Uma pessoa com conhecimento básico usando IA, possivelmente vai conseguir entregar mais do que um dev júnior que não usa IA.

Ao mesmo tempo, tem gente perdendo o emprego pelo mesmo motivo: uso da IA. Então fica a dúvida: como ser um bom profissional nesse cenário?

A lógica é simples: se eu não uso IA, fico para trás em produtividade e competitividade. Mas se eu me encosto nela de forma excessiva e sem critério, o risco de adquirir preguiça cognitiva e virar um simples copiador de prompts é gigante.

E qual o resultado prático disso no dia a dia? Sistemas sem integridade. Começa a entregar blocos de código que até rodam na superfície, mas que ignoram a arquitetura e atropelam as regras de negócio. No curto prazo, isso gera um ecossistema frágil e todo remendado. No longo prazo, você decreta a própria perda de relevância.

Pensa bem... se eu entrego um componente que não entendo a fundo e não sei explicar como funciona, minha mão de obra passa a ser facilmente substituível. Afinal de contas, fazer perguntas aleatórias para a IA qualquer um faz... agora, fazer as perguntas certas exige conhecimento técnico. Não tem atalho para isso.

Relutar contra a IA é fazer igual aquele cara da infra, de dez anos atrás, que se recusou a aprender Cloud. Aquele cara que dizia que configurar servidor na mão via SSH era o jeito ‘certo’, enquanto o mercado migrava pra infraestrutura como código. Hoje, ele leva uma semana pra fazer o que um pipeline resolve em minutos.

Relutar contra a IA é repetir esse erro. Não importa o quanto você seja bom ou rápido no teclado, você não vai ultrapassar a produtividade de uma IA, por mais básica que ela seja. Atualmente, velocidade virou pré-requisito, não diferencial.

Tá, mas se eu não posso relutar contra a IA, terceirizar o cérebro pra ela é a solução? Longe disso. E é exatamente nesse ponto que o mercado separa o profissional genérico e o profissional com diferencial real.

O que a IA não consegue fazer

Raciocínio sistêmico. A capacidade de enxergar o todo, e não só a parte. De entender que cada componente de um sistema está conectado aos outros, e que uma ação em um ponto pode gerar consequências em cadeia em lugares que você nem estava olhando.

Vou te dar um exemplo prático: recebi um alerta crítico de latência alta numa aplicação em produção. A primeira reação de quem depende 100% de IA seria colar o log no chat. Ela devolveria o óbvio: otimize a query, ajuste o índice, escale a máquina. Mas o problema estava fora do radar dela.

Foi fazendo as perguntas certas, como "Isso começou quando?", "Teve deploy hoje?" e "Quem mais compartilha recursos com esse banco?", cheguei na raiz do problema. Um pipeline rodando em background travou as conexões do pool. Não era a query, era contenção de recurso causada por outra peça da infraestrutura. A IA não faz essa correlação sozinha. Ela não tem o contexto do todo. E com a pressão do sistema caindo, você não tem tempo de explicar isso pra ela.

Nesse cenário, o melhor foi não usar IA. Porque simplesmente não era necessário. Eu precisei somente me questionar com o básico para encontrar o problema raiz. Depois de entender a causa, se precisasse de algo mais minucioso, aí sim eu usaria a IA.

Esse tipo de raciocínio é o que responde a perguntas que a IA não sabe formular:

• Por que o sistema está se comportando assim na raiz do problema?

• Onde as falhas vão surgir quando escalar? Qual a previsibilidade?

• Como uma alteração mínima pode gerar um efeito dominó e causar um outage?

No fim das contas, o segredo é usar IA com profundidade técnica suficiente para saber quando ela está errando.

Quantas vezes você já jogou o erro no chat da IA sem nem ler a mensagem antes? É automático: deu erro, cola lá.

O profissional que se diferencia é o que para, lê, entende o contexto e só depois decide se precisa de ajuda. Ele percebe quando a IA está alucinando, presa em loop, ou dando uma volta ao mundo para algo que se resolve com um único comando. A primeira pergunta que ele se faz é: 'Isso faz sentido?'. Ele domina a regra de negócio e a arquitetura, conhece os gaps e não sai executando código às cegas.

O que mudou na minha cabeça

Essa clareza sobre IA e diferencial técnico é só metade do problema. A outra metade, que demorei mais para aceitar, é entender o meu real tamanho perante o mercado.

Trabalho como DevOps, tenho projetos bacanas. Mas sei que ainda tem um nível acima do que eu sou hoje e chegar lá exige mais. Durante muito tempo, caí na armadilha da "síndrome do protagonista", aquela ilusão de que somos o alecrim dourado, a exceção à regra, e de que o sucesso virá por atalhos ou de forma mágica. Mas quando você olha para a complexidade da nossa área, para a arquitetura dos sistemas e para a velocidade com que a IA evolui, a ficha cai: não há espaço para quem acha que sabe tudo.

Existe uma sensação silenciosa que assombra muitos profissionais de tech: por fora, tudo certo. Entregas acontecendo, reconhecimento vindo, destaque no time. Mas por dentro, uma pergunta que não sai da cabeça: o quanto disso fui realmente eu? Essa dúvida se intensifica com o uso da IA. Porque quando a ferramenta entrega rápido demais, fica difícil separar onde termina a IA e onde começa o seu raciocínio.

Perceber que não existe atalho, milagre ou ‘hack’ pra salvar a carreira é libertador. Isso elimina a ilusão de que você já sabe o suficiente e deixa apenas um caminho inevitável: estudar. Isso não é autopiedade, é autoconsciência.

Como já dizia o filósofo Clóvis de Barros Filho: 'Você tem brio?'. Aquele brio de olhar para um problema e pensar: 'Como pode alguém ter criado isso e eu não dar conta de entender? Não tem como'. E então sentar, ler, refazer uma, duas, três vezes até dominar. Sem atalho. Sem plano B.

Mas dominar a técnica através do estudo é só a base. O seu verdadeiro diferencial em relação a uma IA entra no passo seguinte: a sua capacidade de pensamento e tomada de decisão no mundo real. Infelizmente, não conseguimos mais criar um cluster Kubernetes mais rápido que uma IA. No entanto, nós temos o raciocínio sistêmico, a mentalidade de engenharia e, principalmente, o contexto vivido. A IA não sabe que aquele microsserviço de pagamento não pode ser reiniciado durante o fechamento do mês porque derruba a conciliação inteira. Ela não sabe que um cliente em particular não tolera nem 30 segundos de indisponibilidade. Ela não carrega o histórico de decisões ruins que o time tomou há dois anos e que assombram a arquitetura até hoje. Esse contexto não se prompta. Ele se constrói com tempo, atenção e presença. E é exatamente isso que te mantém no jogo.

A conclusão

"Ninguém é insubstituível." Eu comecei esse artigo com essa frase. E continuo acreditando nela. No mercado de trabalho, ninguém é. Mas descobri que a pergunta certa nunca foi "como ser insubstituível?". A pergunta certa é: "o que eu preciso dominar pra que me substituir custe caro demais?"

E a resposta não está em trabalhar mais horas, nem em abraçar a IA cegamente, nem em fingir que a IA não existe. Está em construir um raciocínio que a IA não replica, uma profundidade técnica que não se copia com prompt, e uma autoconsciência que te impede de estagnar.

Domine as tecnologias como pré-requisito. Mude sua forma de pensar como diferencial.

O caminho pra ter esse diferencial é mais simples do que parece. Você simplesmente precisa estudar e se colocar em problemas... Pensar fora da caixa em DevOps não é usar a ferramenta mais nova ou montar o pipeline mais elaborado. É questionar o que todo mundo aceita como verdade. Por que esse processo existe? Ele ainda faz sentido? Existe uma forma mais simples de resolver isso? O DevOps que pensa assim não espera o problema virar incidente, ele enxerga o atrito antes, propõe a solução antes, e entrega antes. Essa antecipação é o que nenhuma IA faz sozinha, porque ela responde a perguntas. Você formula as perguntas certas.

E caso você que está lendo precise de uma direção, eu tenho uma sugestão simples:

ESTUDA → DOCUMENTA → ENSINA → PUBLICA

1. Estuda. Tanto tecnologias quanto métodos. Se não sabe por onde começar, siga um roadmap.

2. Documenta tudo o que você aprende. O conhecimento que não está registrado se perde.

3. Ensina antes de se sentir pronto. Ensinar expõe as lacunas que você nem sabia que tinha e, como bônus, fixa o que aprendeu. Inclusive, esse artigo é o meu passo 3. Escrevi antes de me sentir pronto. E foi exatamente isso que me forçou a organizar o que eu realmente sabia e expôs o que eu ainda precisava entender melhor.

4. Entrega publicamente o que você está aprendendo. Compromisso público vira combustível. Posta. Mostra o seu trabalho. Porque essa é a única prova que você pode dar para o mercado de trabalho de que você realmente sabe o que diz que sabe. Ensine. Tem gente que só vai entender tal conceito com a sua forma de explicar. Poste vídeos, artigos, posts, suba projetos no GitHub, mas publique o que você anda fazendo.

Bom, esse é o meu primeiro artigo. E ele nasce exatamente do ponto onde eu parei de me enganar e comecei a construir de verdade, sem plano B, sem saída. Se algo aqui te incomodou, ótimo. Incômodo é o primeiro sinal de que você está prestando atenção.

Os próximos artigos vão ser diferentes desse. Menos reflexão, mais terminal. Cada tópico que eu estudar vira conteúdo aqui: com os comandos que rodei, os erros que cometi e o raciocínio que usei pra resolver. Se você quer aprender DevOps, sem filtros, pode me acompanhar nessa caminhada. Vai valer o seu tempo.

Vinicius Aguilar — DevOps Engineer