Contrate um desenvolvedor para corrigir código gerado por IA: perguntas de entrevista

O que dá errado com código gerado por IA em projetos reais

Apps gerados por IA costumam parecer ótimos em uma demo porque o caminho feliz funciona. O problema aparece quando usuários reais fazem coisas reais: se inscrever duas vezes, resetar senha, colar entradas estranhas, abrir o app em uma rede lenta ou usar outro dispositivo. Muitos protótipos feitos com IA são costurados rapidamente, então o primeiro caso limite pode quebrar um fluxo essencial.

As falhas comuns são fáceis de identificar quando você sabe onde olhar. Autenticação é um grande ponto: o login funciona localmente e depois quebra no deploy, ou papéis e sessões se comportam de forma inconsistente. Outro problema clássico são segredos expostos, como chaves de API no código cliente ou comprometidas no repositório. A lógica também costuma ser frágil: o total do checkout é calculado em dois lugares, um webhook roda duas vezes, ou erros são engolidos fazendo com que haja corrupção silenciosa de dados em vez de um erro claro.

Sintomas que geralmente significam que o código precisa de reparo real (não ajustes menores):

• Auth e permissões parecem aleatórias (usuários veem coisas que não deveriam)
• Segredos estão hard-coded ou compartilhados entre ambientes
• Mudanças em uma área quebram funcionalidades não relacionadas
• Manipulação de dados inconsistente (duplicatas, atualizações faltando, gravações parciais)
• O app funciona localmente mas falha após o deploy

O que você está tentando contratar não é “alguém para adicionar features”. Você precisa de alguém que consiga diagnosticar rápido, explicar o que está acontecendo e aplicar correções seguras sem criar novos problemas. Isso significa ler código desconhecido, rastrear requisições ponta a ponta, escrever alguns testes ou verificações direcionadas e melhorar a estrutura para que a próxima correção seja mais fácil.

Velocidade importa, mas velocidade sem correção transforma protótipos em retrabalho sem fim. Defina expectativas cedo: peça primeiro um diagnóstico inicial e depois um plano de reparo com prioridades. Um bom desenvolvedor separa correções de “estancar o sangramento” (buracos de segurança, auth quebrado, perda de dados) de trabalho de “deixar mais bonito” (refactors, limpeza). Se você quer rapidez, deixe claro onde arestas podem ficar ásperas e onde não podem (segurança, pagamentos, dados do usuário).

Antes da entrevista: defina o trabalho que você realmente precisa

Se você quer contratar alguém para corrigir código gerado por IA, não comece com uma vaga genérica. Comece escrevendo o que significa “pronto” para seu projeto. Sem isso, entrevistas viram batalhas de opinião em vez de uma decisão clara de sim/não.

Defina “pronto” em resultados, não em sensações. Para um repositório bagunçado, “pronto” geralmente significa que os fluxos principais funcionam, checagens básicas de segurança estão no lugar e você consegue fazer deploy sem surpresas.

Uma meta simples é listar o que deve ser verdade quando o trabalho for finalizado. Mantenha prático: jornadas-chave do usuário funcionam de ponta a ponta, os caminhos de maior risco têm pelo menos uma pequena rede de segurança de testes, segredos não estão expostos, passos de deploy são repetíveis (sem “funciona na minha máquina”) e o código é legível o suficiente para que outro desenvolvedor continue.

Depois, confirme se o trabalho é realmente “reparar” e não “reconstruir”. Apps gerados por IA podem parecer completos mas esconder problemas profundos (estrutura emaranhada, estado frágil, autenticação quebrada). Decida o que você aceita: um patch que estabilize o código atual ou uma reescrita parcial das partes mais arriscadas.

Também decida que tipo de desenvolvedor você precisa: alguém confortável com código que não escreveu. Você pode filtrar isso antes da entrevista pedindo que descrevam as primeiras 48 horas em um repositório bagunçado. Procure por um plano que comece com diagnóstico (rodar, reproduzir bugs, ler logs), depois adiciona segurança (testes, backups, mudanças pequenas), não grandes refactors no primeiro dia.

Por fim, defina expectativas sobre como comunicam risco. Você quer alguém que diga: “Ainda não tenho certeza. Aqui está o que vou checar a seguir e o que pode mudar a estimativa.”

Perguntas de entrevista que revelam a abordagem de depuração

Você não está contratando esperteza. Está contratando uma forma repetível de encontrar a causa real, mesmo com código bagunçado.

Peça os cinco primeiros passos após um relatório de bug crítico. Você ouve um plano calmo e ordenado (coletar fatos, reproduzir, reduzir escopo), não “eu começaria a mudar coisas”. Bons candidatos mencionam confirmar impacto, capturar saída de erro exata e checar mudanças recentes.

Prompts que expõem como trabalham:

• “Um usuário diz que o checkout falha. Quais são seus primeiros 5 passos, em ordem?”
• “Como você reproduz um bug quando o relato é vago? Que detalhes você pede?”
• “Como você isola o menor caso que falha, e por que isso importa?”
• “Do que você parte primeiro: logs, breakpoints, testes, tracing? Quando você troca?”

Depois que responderem, peça para eles caminhar por um exemplo real. Por exemplo: o app funciona localmente, mas em produção usuários são deslogados aleatoriamente. Um bom depurador fala sobre comparar ambientes, checar cookies e sessões, procurar timeouts e adicionar logging direcionado com uma hipótese clara.

A pergunta mais reveladora é o que fazem quando não conseguem reproduzir o bug. Procure respostas como: melhorar observabilidade (logs e traces melhores), criar um teste mínimo, reduzir risco com um guard ou feature flag e construir uma lista curta de hipóteses para confirmar ou eliminar. Se disserem “vou ficar tentando coisas aleatórias”, é um sinal de alerta em bases frágeis onde um “pequeno conserto” pode quebrar três fluxos.

Se quer um chek rápido da realidade, peça que expliquem a abordagem em linguagem simples, como se estivessem atualizando um fundador não técnico no fim do dia. Atualizações claras costumam indicar depuração disciplinada.

Perguntas que testam como lidam com incerteza e falha

Código gerado por IA tem um jeito de estar confiantemente errado. Você precisa de alguém que admita que errou, mude de direção rápido e deixe o sistema mais seguro do que encontrou.

Esta parte da entrevista não é sobre respostas perfeitas. É sobre como reagem quando a realidade não bate com a primeira teoria.

Peça por uma história real de falha (e seja específico)

Forçe detalhes, não histórias polidas:

• “Conte sobre um bug que você inicialmente diagnosticou errado. O que você achou que era e o que era na verdade?”
• “Que sinal te fez mudar de ideia?”
• “O que você fez primeiro para reduzir risco enquanto ainda estava incerto?”
• “Como confirmou a correção e garantiu que não quebrou algo próximo?”

Se ficarem vagos, pergunte: “Qual foi o menor experimento que você rodou para provar ou refutar sua teoria?”

Um exemplo realista: o login falha “aleatoriamente”. Um candidato fraco culpa “auth instável” e troca bibliotecas. Um forte explica como reproduziu, percebeu expiração de token ou drift de relógio e provou com um ou dois checks direcionados.

Como soam boas respostas

Ouça por hábitos confiáveis. Bons candidatos descrevem uma linha do tempo (hipótese, teste, resultado, próximo passo), nomeiam a evidência que mudou a opinião e falam sobre contenção (planos de rollback, guardas temporários). Também previnem repetição com um pequeno teste, uma nota de causa raiz ou um alerta de monitoramento.

Se não conseguem explicar um erro sem culpar outros, ou afirmam que “nunca” erraram o diagnóstico, é um sinal ruim. Depurar código bagunçado é incerteza, e os melhores permanecem calmos e metódicos.

Hábitos de segurança: perguntas que revelam práticas reais

Segurança é muitas vezes onde “funciona na minha máquina” vira risco real. Você quer hábitos repetíveis, não promessas.

Comece por autenticação e sessões. Apps feitos por IA frequentemente misturam padrões (cookies, JWTs, localStorage) e deixam lacunas.

Perguntas que tendem a expor prática real rapidamente:

• “Quando você abre um novo codebase, o que checa primeiro em auth e manejo de sessão?” Ouça por específicos: flags de cookie (HttpOnly, Secure, SameSite), expiração de sessão, fluxos de refresh e onde tokens são armazenados.
• “Mostre como você encontraria segredos expostos e configuração insegura.” Bons respostas incluem escanear por .env comprometidos e chaves no repositório, além de um plano para rotacionar e evitar reintrodução.
• “Como você previne SQL injection aqui?” Você quer ouvir queries parametrizadas, padrões seguros de ORM e validação de entrada. Se disserem “eu só sanitizo entradas”, pergunte como, exatamente.
• “Qual sua rotina de atualização de dependências em um projeto bagunçado?” Respostas fortes cobrem lockfiles, ferramentas de audit e um plano de testes após upgrades.

Um follow-up útil: “Explique a troca entre velocidade e segurança nessa correção.” Por exemplo, se um protótipo guarda JWTs em localStorage, um bom engenheiro explica por que mover para cookies HttpOnly reduz impacto de XSS e o que isso muda no frontend.

Sinais de alerta que soam confiantes mas vagos: não conseguem nomear checagens concretas para sessões e armazenamento de tokens; tratam validação de entrada como solução única para SQL injection; descartam risco de dependências por ser “só um protótipo”; ou evitam falar sobre rotação de segredos após vazamento.

Como explicam trade-offs em linguagem simples

Você não está contratando só habilidade de código. Está contratando julgamento. Os melhores candidatos conseguem dizer o que estão fazendo, por que estão fazendo e o que se ganha (e perde) com cada opção.

Um teste simples: peça para explicarem a mesma decisão duas vezes, uma como se você fosse um desenvolvedor e outra como se fosse um fundador ocupado que só quer risco e custo em termos simples. Se não conseguem mudar o tom, você terá dificuldade em tomar boas decisões juntos.

Patch rápido vs refactor correto

Dê um tipo real de bug (auth quebrado, crashes aleatórios, pagamentos falhando) e peça para comparar um patch rápido com uma correção mais profunda. Você ouve como descrevem risco e se incluem um passo de segurança como testes, logging ou plano de rollback.

Prompts úteis:

• “Se enviarmos um patch rápido hoje, o que pode quebrar na próxima semana?”
• “O que faria você parar e dizer: isso precisa de refactor, não patch?”
• “Como provaria que a correção funciona sem depender de esperança?”

Reescrever vs reparar, e como documentam decisões

Código gerado por IA frequentemente funciona até receber tráfego real. Pergunte como decidem reescrever um módulo ou consertá-lo. Bons candidatos usam sinais como limites pouco claros, dependências emaranhadas, lógica copiada repetida ou risco de segurança difícil de conter.

Peça um exemplo concreto: “Se o módulo de perfil do usuário está spaghetti, o que faria nas primeiras 48 horas?” Um bom plano costuma ser: isolar o módulo, adicionar alguns testes, refatorar em passos pequenos e monitorar para não criar páginas lentas ou surpresas de escala.

Por fim, pergunte como escrevem decisões para não técnicos. Procure notas de decisão curtas: o que mudou, o que não mudou (ainda), riscos e próximos passos.

Um cenário realista para discutir durante a entrevista

Use uma história pequena e concreta e peça para falarem em voz alta.

Cenário: depois de uma atualização de uma ferramenta de IA, usuários não conseguem mais logar. O app mostra “Sessão inválida” mesmo com a senha correta. Funcionou ontem. Agora tickets de suporte estão se acumulando.

Primeiro, ouça as perguntas que fazem antes de tocar o código. Bons candidatos querem saber: o que mudou (deploy, vars de ambiente, bump de dependência), se afeta todos os usuários ou um subconjunto, se há logs ou traces, qual método de auth usado (cookies, JWT, OAuth) e se segredos/chaves foram rotacionados. Bônus se perguntarem sobre risco: “Os usuários estão apenas trancados fora ou sessões estão sendo aceitas incorretamente?”

Depois peça para tentar cronometrar a abordagem. O plano deve soar como um checklist, não adivinhação:

• Primeira hora: reproduzir o bug, capturar uma requisição/resposta que falha, checar diffs recentes, confirmar config (domínio do cookie, CORS, URL de callback, store de sessão).
• Primeiro dia: traçar todo o fluxo de login, adicionar logging temporário em torno da criação e validação de sessão, escrever um teste pequeno que prove a falha.
• Depois que estiver estável: refatorar as partes frágeis, remover acoplamentos ocultos, adicionar monitoramento e documentar o que mudou para evitar repetição.

Em seguida, pergunte como confirmam a correção. Boas respostas incluem um passo a passo reproduzível, testes para casos de sucesso e falha e um plano de rollback. Também devem mencionar como evitam repetição (travar versões, checagens de config mais seguras, regras básicas de code review).

Por fim, pressione sobre trade-offs: o que envia agora vs agenda para depois? Você quer alguém que proteja usuários hoje sem te afundar em dívida técnica amanhã.

Armadilhas comuns ao entrevistar para reparo de código bagunçado

Os maiores erros acontecem quando a conversa fica abstrata. Você quer detalhes: o que olham primeiro, o que medem e o que fazem quando estão errados.

Uma armadilha é fazer perguntas que recompensam confiança, não clareza. Se perguntar “Você pode limpar isso?” quase qualquer um diz “sim”. Em vez disso, pressione por específicos: que sinais indicam que o bug está nos dados, auth ou estado, e que evidências coletariam antes de tocar no código.

Outro erro comum é focar demais em frameworks. Um candidato que só fala em reescrever na stack mais nova pode estar evitando o trabalho real: ler código estranho, traçar requisições e reduzir risco.

Sinais de alerta:

• O plano de depuração é basicamente “adicionar console logs” (sem mencionar reproduzir, reduzir inputs, logs e traces).
• Descartam testes como “depois” e não mencionam uma rede de segurança antes de refactors.
• Dão prazo firme sem pedir para ver o repo, configs e setup de deploy.
• Se recusam a explicar decisões em linguagem simples ou ficam irritados com perguntas “por quê”.

Prazos são uma armadilha especial. Bons engenheiros dão intervalos e um plano, não promessas. “Dia 1: reproduzir e mapear o fluxo de requisição. Dia 2: consertar as principais causas e adicionar testes. Depois, reassess” é mais crível que um prazo garantido sem revisão de código.

Checklist rápido: sinais de que você encontrou a pessoa certa

Depois de uma breve revisão, um bom candidato te diz o que está olhando e por que está falhando. Não precisam ter certeza perfeita, mas devem resumir o codebase em termos simples: o que o app faz, onde estão os fluxos principais (login, pagamentos, uploads, admin) e o que parece errado (vars de ambiente faltando, modelo de dados confuso, lógica duplicada).

Eles também não correm direto para reescrever. O melhor padrão é: “Primeiro faço uma auditoria rápida, depois entrego uma lista priorizada de correções.” Essa lista deve ser ranqueada por impacto e risco, não por o que é mais divertido refatorar.

Ouça por hábitos de produção, não promessas vagas. Devem mencionar naturalmente testes para caminhos quebrados, um ambiente de staging, plano de rollback e monitoramento básico (nem que sejam logs e alertas simples). Devem falar como vão provar que a correção funcionou, não só como vão “implementar”.

Segurança é outro indicador rápido. Um bom candidato percebe riscos sem você dar pistas: segredos expostos, checagens de auth fracas, construção insegura de SQL, validação de entrada faltando ou CORS excessivamente aberto.

Também pergunte como vão organizar a semana de trabalho. Você quer check-ins claros e entregáveis que você entenda, como uma lista curta de problemas principais com severidade, o que foi enviado, o que vem a seguir e o que está bloqueado.

Próximos passos: faça um pequeno teste e defina um plano claro de reparo

Não pule direto para uma grande reescrita. Com código gerado por IA, você aprende mais com um pequeno teste pago do que com mais uma hora de conversa. O objetivo é ver como pensam, como se comunicam e se deixam o código mais seguro do que encontraram.

Mantenha o teste pequeno mas real: um bug visível para o usuário, uma correção de segurança e um teste simples para travar a mudança. Por exemplo: “Login às vezes falha”, “remover um segredo exposto do repositório e rotacioná-lo” e “adicionar um teste básico para o fluxo de login”. Escopo fechado permite julgar resultados em um ou dois dias.

Antes de começarem, concorde no que significa “pronto” e no que você receberá de volta. Você deve ver uma explicação curta do que mudou e por quê, notas sobre qualquer atualização de config ou ambiente e um plano simples de deploy que inclua como verificar e como reverter.

Se não tem tempo para avaliar candidatos a fundo, uma abordagem de auditoria primeiro ainda avança. FixMyMess (fixmymess.ai) foca em diagnosticar e reparar apps gerados por IA de ferramentas como Lovable, Bolt, v0, Cursor e Replit, e começa com uma auditoria de código gratuita para você ver problemas concretos e prioridades antes de se comprometer com uma reescrita.