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!

Carregando publicação patrocinada...
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!