1
rodrigofreire
4 min de leitura ·

A vaga não é mais pra quem escreve código. É pra quem sabe o que a IA fez depois

Teve um relatório saindo essa semana falando que o gasto mundial com IA deve bater 2,52 trilhões de dólares em 2026. Número grande desse jeito costuma passar batido, mas o motivo dele importa mais que o valor em si: a fase de brincar com chatbot acabou. Agora é empresa exigindo retorno financeiro claro, e projeto que não mostra economia ou receita mensurável tá perdendo espaço rápido.

E dentro desse relatório tem uma frase que eu fiquei martelando: segurança e governança viraram prioridade obrigatória antes de escalar qualquer sistema de IA. Não depois. Antes.

Isso não é detalhe técnico de rodapé. É a virada de chave que separa quem vai ter emprego bom daqui a um ano de quem vai ficar competindo com o próprio modelo que substituiu ele.

Por que "antes de escalar" muda tudo

Pensa no seguinte: quando IA generativa virou modinha, todo mundo focou em "o que ela consegue fazer". Escreve código, gera imagem, monta relatório. A pergunta era só sobre capacidade.

Só que capacidade sem controle é aposta, não produto. E empresa grande não aposta trilhão de dólar sem saber o que acontece quando o agente que ela colocou pra tomar decisão autônoma erra, vaza dado, ou faz algo que ninguém pediu. Teve caso rodando as manchetes recentemente de ferramenta de agente mandando repositório inteiro de cliente pra servidor de outra empresa, sem ninguém ter pedido isso, só porque a configuração padrão permitia. Não foi ataque de hacker. Foi a própria ferramenta, funcionando exatamente como configurada, do jeito errado.

Isso é o que muda a pergunta de "o que a IA faz" pra "quem garante que ela só faz o que devia". E aqui mora a virada de mercado real: empresa não tá contratando mais gente só pra treinar modelo ou plugar API. Tá contratando quem sabe auditar, conter e responder pelo que o sistema autônomo fizer.

O dev que só senta e escreve código é o primeiro a sobrar

Vou ser direto nisso porque acho que ninguém tá falando com essa clareza. Se o teu valor profissional é "eu escrevo função que funciona", você tá competindo de igual pra igual com o próprio modelo que a empresa contratou. E nessa corrida, o modelo ganha em velocidade sempre.

O relatório mesmo aponta que empresa de tecnologia grande já tem uns 30% da própria produção apoiada em IA. Isso não é ameaça distante, é fato presente. A parte que sobrevive nesse cenário não é quem digita mais rápido. É quem sabe orientar o que o modelo constrói, entender o que pode dar errado, e principalmente provar que o resultado é confiável antes de colocar em produção.

Isso vai muito além de saber usar spec-driven bonitinho. Ter uma spec bem escrita ajuda o agente a construir certo, mas não responde a pergunta que o mercado tá cobrando agora: quem valida que aquilo que foi construído não tem falha, não vaza dado, não faz nada fora do escopo quando ninguém tá olhando? Spec organiza a intenção. Não garante o resultado.

Eu vivi isso na prática outro dia. Um cliente pediu pra eu integrar um sistema que ele mesmo tinha feito com ferramenta de vibe coding, achando que ia ser rapidinho. Antes de tocar em qualquer integração de pagamento ou dado sensível, parei pra ler o código inteiro. Achei centenas de falha. O sistema funcionava, no sentido de "roda sem erro na tela". Só que funcionar não é a mesma coisa que ser seguro pra colocar dado real de gente real. A distância entre essas duas coisas é exatamente onde o mercado começou a pagar bem.

O que a empresa quer contratar agora

Reparando no que esse tipo de relatório de mercado descreve, dá pra puxar um fio bem prático. Empresa quer gente que saiba guiar sistema autônomo sem deixar ele agir sem supervisão de verdade. Quer gente que entenda de FinOps aplicado a IA, porque rodar modelo caro sem medir custo virou irresponsabilidade financeira, não só descuido técnico. E quer, cada vez mais, gente que saiba pensar em contenção: o que acontece quando o agente tenta fazer algo que não devia, e como o sistema reage antes que vire prejuízo ou vazamento.

Isso não é nicho raro de segurança da informação separado do resto. Virou parte do trabalho de qualquer dev sério que constrói algo que roda sozinho, decide sozinho, ou toca dado que não é dele. A habilidade de escrever código bom continua importando, só que sozinha ela virou commodity. O diferencial migrou pra quem entende o que roda por baixo, o que pode falhar, e como provar isso pra quem paga a conta.

O que eu levaria disso

Não dá pra reverter essa curva. Sistema autônomo vai continuar tomando decisão, gerando código, e agindo sem supervisão constante, porque é exatamente isso que empresa tá comprando com trilhão de dólar. A pergunta que sobra pra cada um de nós, que trabalha com isso no dia a dia, é onde a gente decide se posicionar dentro dessa cadeia: como o cara que só entrega o que o modelo pediu pra entregar, ou como quem entende, audita e responde pelo que foi entregue.

A segunda opção dá mais trabalho. Também é a que ainda não tem fila de substituto pronto pra tomar teu lugar amanhã.

FONTES citadas no blog.

Carregando publicação patrocinada...
2

Texto muito necessário! Essa distinção entre "capacidade de gerar" e "capacidade de conter/auditar" é exatamente o que separa o desenvolvedor profissional de quem só faz vibe coding.
A ilusão mais perigosa de quem programa com IA hoje é achar que "compilou ou rodou na tela sem erro, então está pronto". A IA é ótima para produzir sintaxe plausível, mas é cega para concorrência de baixo nível, integridade transacional, vazamento de contexto e modos de falha silenciosos.
A postura que passei a adotar e que vejo fazer toda a diferença é o princípio de Zero-Trust com código de IA: todo output gerado por um modelo deve ser tratado estritamente como "input não confiável".
Isso muda a responsabilidade do dev de digitador para auditor de invariantes:
*O sistema lida com falhas parciais e interrupções de processo (crash resilience)?
*As decisões de arquitetura e restrições de negócio foram respeitadas ou o modelo "inventou" um atalho destrutivo?
*O que acontece nos cenários de borda que o prompt não previu?

Quem só sabe pedir para a IA escrever vai competir por preço com o próprio modelo. Quem sabe desenhar a esteira de contenção, prever os vetores de falha e garantir que o resultado é determinístico e seguro é quem vai assinar como responsável técnico. Parabéns pelo post!

1

Valeu, trsthales. Esse enquadramento de "input não confiável" é melhor que o meu, e vou pegá-lo emprestado pra usar.
Tem uma armadilha embutida no teu terceiro item que eu só fui enxergar apanhando. Quando o cenário de borda não foi previsto no prompt, ele normalmente também não foi previsto no teste, porque quem escreveu o teste foi o mesmo modelo, com o mesmo ponto cego. Aí você ganha uma suíte verde que só confirma o que o modelo já achava que era verdade. Cobertura alta, invariante nenhuma.
Naquele sistema do cliente que mencionei no post, foi mais ou menos isso. Tinha teste. Passava. O que não tinha era alguém que soubesse dizer quais invariantes importavam ali, e essa parte nenhum modelo entrega pronta, porque ela depende de saber o que o negócio não pode perder de jeito nenhum.
Que é onde acho que mora a escassez real. Auditar output de IA todo mundo até consegue, no sentido de ler e achar bug. Difícil é saber o que procurar antes de olhar. Falha silenciosa não se anuncia. Ela espera.

1

Essa frase sobre a "suíte verde que só confirma o ponto cego do modelo" foi perfeita. É a ilusão de segurança mais perigosa que existe hoje: você olha o relatório com 95% de cobertura e acha que o sistema está blindado, quando na verdade o teste só validou o caminho feliz que a própria IA imaginou.
Vivi isso na pele recentemente construindo uma ferramenta CLI:
-Se você pede pra IA testar a escrita de um arquivo, ela cria um teste unitário padrão que salva o arquivo e verifica se ele existe no disco. O teste passa verde.
O que ela não testa (porque o modelo não "sente" a dor do runtime):
-O que acontece se o processo sofrer um SIGKILL ou falta de energia no milissegundo exato entre a escrita e o rename atômico?
-O que acontece se o arquivo de destino for um hardlink apontando para outro arquivo sensível do sistema operacional?
-Como o código se comporta se dois processos simultâneos disputarem a mesma trava?

A IA nunca vai propor esses testes espontaneamente porque, para o modelo, o código que ele acabou de gerar "já está certo".
O papel do dev sênior mudou de digitador de código para modelador de ameaças: definir quais são os invariantes invioláveis do negócio e submeter a IA a testes adversariais (injeção de falhas, concorrência e quebras de processo).
Essa sua frase final resume tudo com perfeição: "Difícil é saber o que procurar antes de olhar. Falha silenciosa não se anuncia. Ela espera." Excelente reflexão!