Pular para o conteudo principal

Como validar código gerado por IA ao vivo

O problema não é abrir a IA ao vivo. É aceitar a resposta rápido demais e deixar parecer que o seu critério sumiu.

Andrews Ribeiro

Andrews Ribeiro

Founder & Engineer

O problema

Tem candidato que usa IA na entrevista e até acerta o tom do pedido.

O problema vem depois.

Quando a resposta aparece, ele:

  • lê rápido
  • aceita quase tudo
  • corrige só detalhes de superfície
  • ou valida em silêncio, sem deixar claro o que está verificando

Para ele, parece que houve revisão.

Para o entrevistador, muitas vezes parece outra coisa:

  • confiança cega
  • validação fraca
  • pouca autoria

Ou seja:

não basta usar IA de forma controlada.

Precisa deixar visível que você continua sendo a pessoa que aprova a solução.

Modelo mental

Pense assim:

em entrevista com IA, revisão explícita vale quase tanto quanto geração controlada.

O avaliador não precisa ver só que você chegou em uma resposta.

Precisa ver:

  • como você decide se aquela resposta merece continuar viva
  • onde você procura problema primeiro
  • o que te faz rejeitar, ajustar ou simplificar

Se isso não aparece, a ferramenta parece estar no comando.

O que validar primeiro

1. Se o código resolveu o problema certo

Esse é o filtro mais importante.

Antes de olhar nome de variável ou estilo, vale perguntar:

  • isso responde a pergunta certa?
  • manteve a restrição pedida?
  • ficou no escopo ou resolveu outro problema?

Muita saída de IA erra aqui de forma plausível.

Ela produz algo bonito, coerente, até executável, mas orientado para a leitura errada do enunciado.

2. Se o escopo não cresceu sem autorização

Esse é um dos sinais mais comuns de dependência.

Você pediu uma ajuda estreita e a IA trouxe junto:

  • abstração nova
  • renome desnecessário
  • refactor lateral
  • mudança estrutural que ninguém pediu

Se você não corta isso rápido, parece que perdeu controle do diff.

3. Se existe premissa escondida

Código gerado por IA frequentemente assume coisas sem avisar.

Exemplos:

  • input sempre válido
  • lista sempre ordenada
  • campo sempre presente
  • operação sempre síncrona
  • estrutura já normalizada

Validar bem ao vivo é conseguir dizer algo como:

aqui a lógica ficou boa se esse array já vier ordenado; como isso não está garantido no problema, eu não aceitaria assim.

Esse tipo de frase sobe muito sua credibilidade.

4. Se há risco em comportamento, não só em estilo

Validação fraca olha:

  • nome
  • formatação
  • legibilidade superficial

Validação forte olha:

  • caso de borda
  • contrato
  • falha provável
  • complexidade
  • custo oculto

Em entrevista, isso importa ainda mais porque o avaliador quer ver modelo mental, não só polimento.

Como narrar a validação sem virar palestra

Você não precisa transformar a revisão em monólogo infinito.

Normalmente basta tornar o processo visível.

Algo assim:

  1. “vou checar primeiro se isso resolveu o caso principal”
  2. “agora quero ver se a resposta assumiu algo que o problema não garante”
  3. “aqui eu gostei da estrutura, mas esse trecho expandiu escopo demais”
  4. “vou simplificar e preservar só a parte útil”

Isso já mostra:

  • ordem mental
  • critério
  • controle

Sem parecer teatrinho.

Exemplo simples

Imagine um exercício de API em que a IA gerou um handler para busca paginada.

Validação fraca:

parece bom, vou só ajustar o nome de duas variáveis e seguir.

Validação forte:

vou revisar em quatro pontos: se respeitou o filtro pedido, se a paginação tem limite claro, se assumiu shape demais no input e se trouxe abstração além do necessário. Aqui, por exemplo, ela já colocou um helper separado para algo que ainda cabe no handler. Vou manter a validação e cortar esse helper porque ele adiciona dispersão cedo demais.

Perceba a diferença.

Na segunda resposta, você não só revisou.

Você mostrou como revisa.

O que faz você parecer dependente

Alguns sinais pioram rápido a leitura:

  • aceitar a primeira saída plausível
  • corrigir só cosmética
  • não questionar premissas
  • não cortar excesso de escopo
  • parecer surpreso demais quando o código tem problema

Dependência não aparece só quando você usa muito a ferramenta.

Aparece quando você não parece ter filtro próprio.

O que faz você parecer senior

Quando a validação é boa, você tende a soar como alguém que:

  • supervisiona
  • prioriza o que revisar
  • encontra risco cedo
  • melhora a resposta sem apego à primeira versão

Isso é muito mais senior do que tentar provar que não precisava da ferramenta.

Erros comuns

Validar tarde demais

Se você usa IA, cola um bloco grande e só depois tenta entender, o sinal piora.

Validar em silêncio total

Mesmo quando a revisão existe, ela perde valor se o entrevistador não consegue ver seu critério.

Confundir legibilidade com correção

Código elegante ainda pode estar errado, inflado ou perigoso.

Ficar defensivo quando a IA erra

Se a resposta veio ruim, o melhor caminho é ajustar com calma.

Não proteger a ferramenta.

Como um senior pensa

Quem opera melhor nesse cenário geralmente faz uma mudança simples de postura:

  • não trata a saída da IA como sugestão brilhante
  • trata como rascunho sob inspeção

Essa diferença muda tudo.

Porque recoloca a autoria no lugar certo:

na sua revisão, no seu critério, na sua aprovação final.

Ângulo de entrevista

Em entrevistas com IA permitida, parte do julgamento mudou de lugar.

O avaliador não está vendo só se você consegue produzir código.

Está vendo se você consegue governar código produzido com ajuda.

É isso que separa uso maduro de uso dependente.

Resumo rápido

O que vale manter na cabeça

Checklist de pratica

Use isto ao responder

Você concluiu este artigo

Próximo artigo Prompt engineering para desenvolvimento: o que funciona na prática Artigo anterior Coding assistido por IA em entrevistas práticas

Continue explorando

Artigos relacionados