Por Dr Caio Vieira | Vertex Instituto de Tecnologia e Inovação

Virou quase um bordão nos times de tecnologia dizer que “a IA me deixou 10x mais produtivo”. E olhando apenas para números, não é uma mentira, já que os agentes cospem código, telas, testes e documentação numa velocidade que há três anos era apenas sonho. Porém, ao olharmos para o porquê de boa parte dessa produtividade não ser ganho de verdade, enxergamos que é apenas um ‘adiantamento’. Você recebe o resultado hoje e paga a diferença lá na frente, com juros, geralmente num lugar onde consertar já saiu caro.

O que me incomoda não é a IA errar. É como ela erra, e quem a induziu a cometer esse erro. Um bug normal grita: trava, fica vermelho, cospe um stack trace na sua cara. A IA generativa faz o contrário: ela não tem como te avisar que faltou entender alguma coisa, então ela chuta o mais provável e segue em frente com uma confiança impecável. Não vou fazer listas de medos. Quero olhar o padrão por trás das histórias, porque no fundo elas se repetem. E pra cada uma, a pergunta que interessa não é “a IA é perigosa?”. É o que se pode fazer de diferente.

Ela fala igual quando sabe e quando inventa

Esse é basicamente o ponto central de tudo, então começo por aqui. O modelo não te mostra um medidor de “quão certo eu estou”, apenas a resposta ‘certíssima’, que pode ser alucinação e sair com exatamente o mesmo tom seguro de quem faz achando que sabe tudo.

 

Já vi as três versões disso na prática. Você pergunta se um componente “segue o nosso design system” e ele jura que sim, citando um token de cor que simplesmente não existe no projeto. Você pede uma função e ele te entrega um método com nome bonito, parâmetros, assinatura completa, um método que nunca foi implementado em nenhuma biblioteca. Você pede um resumo de status pra levar pra diretoria e ele devolve números redondos e convincentes, com uns quantos inventados no meio dos reais. Nenhuma dessas vem com um asterisco avisando “isso aqui eu chutei”.

O jeito de não cair nisso é meio chato, mas é o único que funciona: se dá pra verificar, não entra sem verificação. Assinatura de método você confere na doc oficial. Aderência ao design system você checa no catálogo versionado, não no “achei que estava ok”. Número que vai virar decisão tem que dar pra rastrear até a origem, senão não é dado, é chute com aparência de precisão. E chute com aparência de precisão, quando você repassa como fato, deixa de ser problema da IA e vira seu.

“Compilou e os testes passaram” não prova quase nada

Esse é o mais traiçoeiro de todos porque parece rigor. Afinal você rodou os testes, tá tudo verde, o que poderia estar errado?

O detalhe é que quando a mesma IA escreve o código e escreve o teste, o teste só garante que o código faz o que o código faz. Não o que a regra de negócio pedia. Teste que nasce depois da implementação vira um espelho dela: fica verde no código certo e no código que resolve o problema errado com a mesma tranquilidade. Já vi PR aprovado no “os testes passam” onde o teste, no fundo, testava o mock e não o comportamento.

Vale pro “compilou” também. Um “…WHERE id=” + req.query.id compila lindo, passa no caminho feliz, e é uma injeção de SQL indo pra produção com a naturalidade de bom dia. O verde não pegou porque ninguém pediu pra ele pegar.

A saída aqui é inverter a ordem: escreva o critério de aceitação antes de gerar a solução, enquanto você ainda tá pensando no problema. É esse critério que dá ao teste algo de verdade para cobrar. E depois leia a explicação da IA e o código-fonte. Leia mesmo, linha por linha, não role a página até achar o botão de aprovar. Se você não sabe explicar o que uma linha faz, ela não é sua, e alguém vai ter que ser dono dela, provavelmente de madrugada, no meio de um incidente.

O escopo vaza, o contexto escapa, a dívida se acumula

Tem uma família inteira de problemas que não vem do que a IA erra, e sim do quanto ela faz sozinha.

Você pede “muda só o espaçamento desse botão” e ela aproveita a viagem para redesenhar meia tela, mexer em três componentes do lado e quebrar dois que estavam de pé. Você pede uma tela e recebe só o caminho feliz, sem estado vazio, sem erro, sem loading, justamente os estados onde o produto quebra de verdade lá fora. E lá pela quadragésima mensagem daquela conversa gigante, ela esquece a regra que você deu no começo (“zero libs externas nesse módulo”) e manda você instalar três dependências numa boa, porque o contexto dela é uma janela, não uma memória.

E aí entra a tentação clássica: colar o que você não entende. O componente, o CSS, o trecho que funciona e que ninguém no time sabe explicar. Cada um desses vira dívida invisível, código órfão que só vai cobrar a conta daqui a seis meses, quando alguém precisar mexer e descobrir que herdou um problema sem manual.

Não tem mágica pra isso, tem hábito. Trabalhe em pedaços pequenos e de escopo travado, peça um diff cirúrgico e recuse o que passou do combinado. Mudança grande é decisão sua, não efeito colateral de um pedido pequeno. Coloque os estados de borda na spec logo no começo. E segure o contexto enxuto: sessão curta e focada rende mais que colar o repositório inteiro e rezar. Quando a conversa começar a poluir, recomece resumindo as regras do projeto.

Ela foi feita pra te agradar, e isso te cega

Esse é o mais silencioso da lista, porque nem parece erro. Parece que a IA concordou com você porque você estava certo.

“Vamos de microserviços nessa arquitetura, né?” Aí ela concorda toda animada, sem levantar um contra sequer. Modelos são otimizados para serem agradáveis, o que os torna péssimos advogados do diabo se você não pedir explicitamente. Uma IA que só concorda não está te ajudando a decidir. Está te ajudando a errar mais rápido, com a autoridade de quem “pesquisou o assunto”.

A mesma bajulação aparece na hora de medir. Contar produtividade por linha de código ou por PR gerado com IA soa objetivo e incentiva exatamente o que você não quer: volume sem revisão, gente aceitando output cru pra bater meta.

O conserto é simples de falar e desconfortável de fazer: peça a crítica, não o elogio. “Em que cenário essa é a pior escolha possível?” “Me dá os três maiores contras disso.” Force o contraditório antes de fechar a decisão. E, na hora de medir, olhe o que foi revisado e entregue funcionando, não o tamanho do output. A pergunta boa nunca é “quanto a IA gerou”, é “quanto disso chegou de pé no usuário certo”.

E tem o erro que não dá segunda chance

Vários dos erros até aqui têm conserto. Porém esse último não, por isso deixei ele para o fim: é o de mandar dado sensível para dentro da IA. Diferente dos outros, o estrago acontece no exato segundo em que você aperta enter, e não tem como desfazer.

É o atalho de colar a planilha de clientes, com CPF, e-mail, telefone, no prompt para pedir “um resumo rapidinho”. Ou de jogar um trecho de log de produção que tem token de sessão no meio. Ou o contrato inteiro do cliente para IA “achar as cláusulas de risco”. Parece inofensivo, afinal a resposta aparece só na sua tela. O problema é o que acontece do outro lado, no caminho até essa resposta.

Dado que sai da sua fronteira não volta. Dependendo da ferramenta e do plano contratado, aquele prompt pode ser retido nos servidores do provedor, logado para auditoria, inspecionado por um time de abuso e, em alguns casos, usado para treinar modelo futuro. Você perde o controle sobre onde aquilo vive, por quanto tempo, e quem consegue olhar. Não dá pra “apagar” um dado que já foi copiado para uma infraestrutura que não é sua, do mesmo jeito que não dá pra despublicar uma foto que já circulou. E, diferente de um bug, aqui não tem rollback: no segundo em que você aperta enter, o vazamento já aconteceu.

E fazer certo não é difícil. Antes de mandar qualquer coisa pra IA, tire o que identifica alguém: troque nomes e documentos por rótulos genéricos (“cliente A”, “CPF 000”), mascare os campos sensíveis, ou trabalhe com uma amostra de dado sintético que tenha o mesmo formato sem ser gente de verdade. Precisa analisar dado real e sensível de forma recorrente? Aí a conversa é outra: use uma ferramenta contratada com cláusula de não-treinamento e retenção zero, aprovada pela sua equipe de segurança, e não a aba anônima do navegador às onze da noite. A regra prática é curta: se você ficaria desconfortável de ver aquele conteúdo vazado num print, ele não vai no prompt.

O fio que costura tudo

Junta as histórias e o padrão pula na sua frente: a IA não sinaliza o que ela não sabe. Ela fecha a lacuna com o mais provável e entrega tudo com a mesma confiança. Então o estrago nunca está em usar IA, e sim em usar solta, aceitando sem entender, colando sem revisar, decidindo sem contraditório, repassando sem conferir.

E é aqui que a coisa fica meio irônica. Se você reler os consertos que eu fui jogando ao longo do texto, vai reparar que todos são a mesma ideia com roupa diferente:

• Entender o problema antes de sair codando.
• Definir os critérios de aceitação antes da solução.
• Rever a estratégia e os riscos antes de implementar.
• Aprovar de olho no diff, porque verde não é prova.
• Pedir o porquê e a crítica, não a validação.
• Conferir o que a IA afirma, e jamais colar segredo.

Sério, não tem nada de novo aí. É engenharia de software com o bom senso de sempre. O problema nunca foi saber disso. É que cada uma dessas coisas depende de disciplina humana toda santa vez, e disciplina que depende de força de vontade é a primeira a evaporar na correria. Some justamente na sexta à tarde, no PR que “é só isso”, no exato momento em que a IA te entregou algo que parece perfeito.

Por isso eu não acredito muito em mais um treinamento de “use IA com responsabilidade”, desses que todo mundo assiste, acha ótimo, e esquece na segunda de manhã. O que resolve de verdade é tirar esse peso das costas da pessoa e fazer com que essas práticas sejam o caminho mais fácil, não o mais virtuoso. Enquanto “entenda antes” e “aprove com consciência” forem coisas que você tem que lembrar de fazer, elas vão falhar exatamente quando mais importam.

No fim, a IA continua sendo genial. Nada que eu escrevi aqui a deixa menos útil. Só que é um gênio a gente não deixa mergear sozinho, nem decidir arquitetura sem discussão, nem levar número pra diretoria sem alguém conferir antes. A gente conduz. O pulo de produtividade de verdade não vem de aceitar mais rápido, vem de conduzir bem, mantendo a pessoa no loop bem nos pontos onde a IA erra quieta. O resto ela faz melhor que a gente, e tudo bem.