Como Depurar um App Criado com IA: Um Método Prático

Para depurar um app criado com IA, primeiro faça o bug acontecer de novo de propósito e depois reúna evidências — os passos exatos, a mensagem de erro e o que o console e a aba de rede do navegador mostram — e entregue isso à IA como “fiz X, esperava Y, aconteceu Z”. Se uma correção piorar as coisas, volte para a última versão que funcionava em vez de empilhar correções por cima. Você não precisa ler o código para fazer tudo isso bem.

Este guia cobre o ciclo completo, incluindo um tour rápido pelas ferramentas de desenvolvedor do navegador para quem não é programador.

O ciclo de depuração

Toda correção de bug, feita por uma pessoa ou por uma IA, segue o mesmo ciclo:

1. Reproduzir — faça o bug acontecer de forma confiável.
2. Observar — colete a mensagem de erro e o que o app estava fazendo.
3. Descrever — dê à IA passos precisos, o resultado esperado e o resultado real.
4. Corrigir — deixe a IA mudar uma coisa só.
5. Verificar — repita os passos exatos, confirme que está corrigido e que nada próximo quebrou.
6. Reverter, se necessário — se piorou, desfaça e tente de novo com informações melhores.

A maior parte do tempo perdido com apps criados por IA vem de pular os passos 1, 2 e 5: dizer “está quebrado”, aceitar uma mudança sem testá-la e depois pedir mais uma correção em cima de uma versão já quebrada.

Passo 1: Reproduza o bug

Um bug que você consegue disparar sob demanda já está meio resolvido. Tente encontrar o conjunto mais curto de passos que o causa.

Pergunte a si mesmo:

• Acontece sempre? Se só às vezes, o que é diferente quando acontece — um registro específico, uma conexão lenta, estar deslogado?
• Acontece para todos os usuários? Entre com outra conta. Muitos bugs só aparecem para usuários novos sem dados, ou para um usuário com outro papel.
• Acontece em todos os dispositivos? Teste uma tela da largura de celular e outro navegador.
• Começou depois de uma mudança específica? Se funcionava ontem, as últimas mudanças são os principais suspeitos.

Anote os passos como uma lista numerada curta. Você vai colá-la no prompt depois.

Passo 2: Leia a mensagem de erro

Mensagens de erro intimidam, mas você só precisa de algumas partes delas.

Você não precisa entender tudo; precisa copiar exatamente. “Cannot read properties of undefined (reading 'name')” diz à IA que o código esperava algum dado (provavelmente uma reserva ou um usuário) que não estava lá. Uma paráfrase como “um erro de undefined qualquer” perde essa informação.

Alguns erros comuns, traduzidos de forma aproximada:

• Erros de undefined / null — o código esperava um dado que não chegou. Muitas vezes é um estado de carregamento ou uma lista vazia que o código não tratou.
• 404 Not Found — a página ou o endereço da API não existe. Muitas vezes é um erro de digitação em uma rota ou um link para uma página que foi renomeada.
• 401 Unauthorized / 403 Forbidden — a requisição não estava logada, ou o usuário não tem permissão para aquilo.
• 500 Internal Server Error — o código do servidor travou. O motivo real está nos logs do servidor, não no navegador.
• Erros de CORS — o navegador bloqueou uma requisição para outro domínio. Geralmente é um problema de configuração do lado do servidor.

Passo 3: Use as ferramentas de desenvolvedor do navegador

Todo navegador de desktop tem ferramentas de desenvolvedor embutidas (“devtools”). Elas mostram o que a página faz por trás dos panos. No Chrome, Edge e Firefox, clique com o botão direito em qualquer lugar da página e escolha Inspecionar, ou pressione F12 (Cmd+Option+I no Mac). No Safari, ative antes o menu Desenvolver nas configurações do Safari.

Você só precisa de três abas.

Console

A aba Console lista erros e mensagens do código da página. Os erros aparecem em vermelho. Se um botão não faz nada quando você clica, o console muito frequentemente mostra um erro vermelho no momento do clique. Copie o texto completo do erro (clique com o botão direito nele para encontrar a opção de copiar, na maioria dos navegadores).

Rede

A aba Rede (Network) lista cada requisição que a página faz — carregar dados, salvar um formulário, fazer login. Abra-a e repita os passos que causam o bug.

• Procure linhas em vermelho ou com status 400 ou superior.
• Clique em uma linha que falhou para ver a Resposta. Um erro de servidor muitas vezes inclui ali uma mensagem mais útil do que qualquer coisa na tela.
• Anote a URL da requisição e o código de status — “o POST para /api/bookings retornou 500” é uma frase muito útil para dar à IA.

Marque Preservar log se o bug envolver um recarregamento de página ou um redirecionamento, para que as requisições não desapareçam.

Elementos

A aba Elementos (ou Inspetor) mostra a estrutura e os estilos da página. É mais útil para bugs de layout: passe o mouse sobre um elemento para ver seu tamanho e espaçamento destacados. Você não precisa editar nada aqui; basta dizer “o rodapé tem 2.000 pixels de largura no celular e empurra a página para o lado”.

Passo 4: Verifique os logs do servidor

Alguns bugs acontecem no servidor, onde o navegador não consegue ver. Um erro 500 na aba de rede é o sinal clássico. Os logs do servidor — a saída de texto do seu backend enquanto ele roda — geralmente contêm o erro real com um stack trace (uma lista das funções que estavam em execução quando falhou).

Onde encontrá-los depende da sua ferramenta. Na maioria dos construtores de apps com IA, você pode abrir um terminal ou uma visualização de logs do projeto, ou simplesmente pedir à IA: “Verifique os logs do servidor com erros da última requisição e me diga o que falhou.”

Passo 5: Descreva o bug para a IA

Coloque o que você reuniu neste formato:

Na página de Reservas, logado como membro: cliquei em Cancelar na aula de amanhã às 9:00. Esperado: a reserva some e a aula mostra mais uma vaga livre. Real: nada muda na tela. O console mostra TypeError: Cannot read properties of undefined (reading 'id') em BookingCard.tsx:31, e a aba de rede mostra que DELETE /api/bookings/123 retornou 500. Encontre a causa, corrija e confira se o cancelamento funciona para um membro com uma reserva e para um com várias.

Por que cada parte importa:

• Onde e como qual usuário restringe a um tela e um papel.
• Passos exatos permitem à IA reproduzir o bug.
• Esperado vs real define o que significa “corrigido”.
• O texto do erro e a requisição que falhou apontam direto para a causa.
• “Confira se…” pede à IA que verifique, não apenas que edite.

Se a IA tentou corrigir duas vezes e falhou, peça que explique antes de mudar qualquer coisa:

Não mude o código ainda. O que você acha que causa isso, e que evidências sustentam essa hipótese?

Uma teoria errada é fácil de perceber quando é escrita, e muito mais barata de corrigir do que uma correção errada.

Passo 6: Verifique e depois confira o que está por perto

Quando a IA disser que está corrigido, repita os passos exatos do Passo 1. Depois confira as coisas ao redor:

• A mesma ação para um papel de usuário diferente
• A mesma ação sem dados e com muitos dados
• Páginas que compartilham componentes com a que você corrigiu
• Uma tela da largura de celular, se a correção mexeu no layout

Mudanças feitas pela IA às vezes corrigem um caminho e quebram outro discretamente. Uma checagem de dois minutos agora poupa uma hora de confusão depois.

Passo 7: Reverta em vez de empilhar

Se uma correção piorou as coisas, ou se você já passou três rodadas sem progresso, volte atrás. Reverter para a última versão que funcionava e reformular com evidências melhores quase sempre vence pedir uma quarta correção em cima de três erradas. Cada tentativa fracassada deixa código para trás, e esse código confunde a próxima tentativa.

Hábitos bons que tornam a reversão fácil:

• Teste depois de cada mudança, para saber qual mudança quebrou as coisas.
• Mantenha as mudanças pequenas — uma funcionalidade ou correção por mensagem.
• Anote a última versão boa antes de começar algo arriscado.
• Se o código está no Git, faça commits das versões que funcionam para poder voltar a elas.

Padrões comuns de bugs em apps criados com IA

Quando o problema não é um bug

Alguns “bugs” são a IA construindo exatamente o que foi pedido, e a descrição era ambígua. Se a correção que você pede é, na verdade, uma mudança de comportamento, diga isso claramente: “Mude para que…”. Se você ficar em dúvida sobre qual é o comportamento correto, decida isso primeiro. Nosso guia sobre como escrever prompts para construtores de apps com IA mostra como especificar regras com clareza. E se você está preparando um app para usuários reais, como levar um protótipo de IA para produção cobre as verificações que valem a pena antes do lançamento.

Depuração na Mythex

A Mythex tem ferramentas para cada etapa do ciclo:

• Prévia para reproduzir o bug, incluindo uma moldura do tamanho de celular.
• /test faz o agente clicar na sua prévia ao vivo como um usuário e relatar os fluxos quebrados.
• /fix direciona o agente especificamente para as quebras.
• O modo Plano permite que o agente investigue e explique antes de editar qualquer coisa.
• Código → terminal mostra os logs do servidor do seu app.
• Reverter para este ponto em qualquer resposta devolve o projeto ao checkpoint daquele momento.

Se uma publicação falhar, o diálogo de publicação costuma oferecer Corrigir com IA, que lê a saída do build ou os logs do app. Veja Depure seu app e Solução de problemas de publicação na documentação.

Perguntas