Dei um aplicativo para o Claude e pedi que ele simulasse o papel de quatro desenvolvedores seniores diferentes — eis o que aconteceu.

Há muitas afirmações online, especialmente no X, que supostamente tornam os chatbots mais eficazes. Quando me deparei pela primeira vez com uma série de afirmações de David Max , um especialista em educação em IA , fiquei cético, o que me levou a testá-las. Essas afirmações alegam transformar o Claude em tudo, desde um depurador sênior até um especialista em desempenho. Eis o que aconteceu quando decidi investigar. Se você estiver interessado em afirmações mais eficazes, pode conferir 7 afirmações eficazes para o Claude 4 para desenvolver suas ideias e aumentar sua produtividade.

Veja meu rastreador de despesas domésticas no Claude.

Eu já havia criado um rastreador de despesas geral com marcadores de despesas usando o ChatGPT Work, então o utilizei e pedi ao Claude que revisasse o aplicativo quatro vezes. Em cada revisão, atribuí a ele uma função de engenharia principal diferente: engenheiro full-stack, engenheiro de depuração, engenheiro de front-end e engenheiro de desempenho.

O resultado foi muito mais revelador do que simplesmente pedir a Claude para "melhorar o aplicativo". Cada personagem se concentrou em um conjunto diferente de problemas — e às vezes até descobriu problemas que o "desenvolvedor" anterior havia deixado passar. Veja o que aconteceu e as alegações que eles usaram.

1. O engenheiro sênior Full-Stack construiu a aplicação.

Tudo começou com um pedido de Claude para criar um rastreador de despesas domésticas interativo que qualquer pessoa pudesse usar. Para saber mais sobre as capacidades de Claude na criação de aplicativos, leia " Criei 3 aplicativos em minutos usando Claude e Gemini: mas um deles tem um recurso oculto ".

O desafio: Criar um rastreador de despesas domésticas interativo que qualquer pessoa possa usar para registrar e entender seus gastos. Ele deve incluir a capacidade de adicionar e excluir despesas, atribuir categorias, filtrar transações, calcular o gasto total e visualizar um detalhamento visual das categorias.

Imagine-se como um engenheiro full-stack sênior desenvolvendo um MVP refinado para uma startup. Antes de escrever qualquer código, forneça um breve esboço da arquitetura, da estrutura de dados e do fluxo do usuário. Em seguida, crie o aplicativo como um Artefato na Nuvem.

Faça com que seja responsivo e fácil de usar, mas não gaste tempo extra revisando, depurando ou aprimorando o código final. Vou delegar essas tarefas a outros desenvolvedores.

Claude criou um aplicativo React surpreendentemente refinado. Ele incluía exemplos de transações, totais de gastos, rankings por categoria, funcionalidades de busca e filtro, além da possibilidade de ordenar as transações por data. As alterações também eram salvas, permanecendo disponíveis mesmo após reabrir o aplicativo.

À primeira vista, parecia muito mais um produto finalizado do que um protótipo incompleto. Havia cartões estatísticos na parte superior, um formulário de despesas bem organizado e barras coloridas mostrando quanto foi gasto em cada categoria.

2. O engenheiro sênior de depuração descobriu alguns problemas.

Depois disso, pedi a Claude que ignorasse a aparência e examinasse seu próprio trabalho como engenheiro de depuração, preparando um aplicativo para lançamento.

A exigência: Agora, aja como o depurador-chefe que herdou este aplicativo antes de seu lançamento público.

Examine cuidadosamente a aplicação e seu código existente sem alterar sua funcionalidade pretendida ou design visual. Teste os principais fluxos de usuário e procure por erros funcionais, tratamento de entradas inválidas, riscos de perda de dados, cálculos incorretos, problemas de persistência e casos extremos.

Antes de modificar o código, forneça-me um breve relatório de depuração contendo o que você testou, cada problema encontrado, a causa raiz de cada problema, a gravidade de cada problema e a correção que você recomenda.

Em seguida, implemente os reparos e verifique se as características originais ainda funcionam. Não redesenhe a fachada, não realize uma reforma arquitetônica mais ampla nem faça alterações puramente cosméticas.

O processo de depuração revelou muitos problemas reais.

Por exemplo, o campo de entrada original não estava em um formato adequado. Clicar no botão "Salvar transação" funcionava, mas pressionar a tecla Enter podia não funcionar. Claude corrigiu isso convertendo a seção em um formulário adequado com um botão de envio.

Ele também descobriu que os usuários podiam limpar o histórico e salvar uma transação com informações de data inválidas. Claude adicionou validação de data, reforçou as verificações de valores inválidos e corrigiu um cálculo que fazia com que "Habitação" aparecesse como a maior categoria mesmo quando o rastreador estava vazio.

Ainda era possível excluir transações permanentemente com um único clique. Os erros de armazenamento permaneciam ocultos no console do desenvolvedor, o que significava que os usuários poderiam acreditar que suas informações estavam salvas quando, na verdade, não estavam. Além disso, Claude não implementou testes automatizados para confirmar se as correções estavam funcionando.

3. O experiente engenheiro de front-end percebeu uma aplicação completamente diferente.

Na terceira rodada, pedi a Claude que tratasse o rastreador de despesas como um engenheiro front-end especializado em design responsivo e acessibilidade.

A exigência: Aja agora como um engenheiro front-end experiente, especializado em aplicativos de consumo acessíveis e responsivos.

Analise seu atual sistema de controle de despesas sob a perspectiva de alguém que o utiliza em um celular, teclado ou tecnologia assistiva. Mantenha sua funcionalidade e identidade visual geral, mas aprimore sua usabilidade e acessibilidade.

Antes de alterar o código, forneça uma breve revisão abordando o comportamento e a capacidade de resposta em dispositivos móveis, a navegação por teclado, a usabilidade de formulários, a acessibilidade para leitores de tela, o contraste de cores, os estados de carregamento e erro, as ações destrutivas e os controles que possam causar confusão.

Em seguida, implemente as melhorias. Certifique-se de que cada campo de entrada e controle interativo tenha um nome acessível, que os estados de foco sejam claramente visíveis, que as mensagens de verificação possam ser anunciadas por um leitor de tela e que os detalhes de gastos transmitam informações sem depender exclusivamente de barras coloridas.

Esta foi a análise mais completa do experimento.

Claude observou que o aplicativo removia a borda natural ao redor de campos de entrada selecionados sem fornecer uma substituta. Consequentemente, uma pessoa navegando usando um teclado teria dificuldade em visualizar o campo ativo.

Constatou-se também que os rótulos visuais não estavam devidamente conectados aos seus respectivos campos de entrada, que o campo de pesquisa dependia exclusivamente do texto de exemplo e que os erros de validação não estavam configurados para serem anunciados por leitores de tela.

Claude reinstalou indicadores visuais de foco, vinculou rótulos a controles de formulário, adicionou descrições para leitores de tela e aumentou o contraste de muitos elementos de texto em cinza claro. Ele também tornou a barra de pesquisa mais flexível em telas pequenas e adicionou rótulos mais descritivos para botões que contêm apenas ícones.

Mais importante ainda, esse personagem descobriu um problema de exclusão que o depurador havia ignorado. Claude substituiu o botão de exclusão com um clique por um processo de confirmação em duas etapas, que exigia que os usuários excluíssem ou mantivessem a transação.

Nem todas as afirmações eram perfeitas. Claude descreveu 44 x 44 pixels como o tamanho mínimo de um alvo de toque, mas ele só aumentou o botão principal de exclusão para 36 x 36 pixels. Isso atende à meta menor do WCAG 2.2 AA, mas não atende à recomendação de 44 pixels que ele mencionou.

No entanto, a mudança na função de Claude alterou claramente sua perspectiva. O depurador verificava se o aplicativo estava funcionando, enquanto o engenheiro de front-end examinava se uma pessoa real conseguiria usá-lo confortavelmente. Este experimento demonstra como um único requisito pode impactar significativamente os resultados de Claude.

4. O engenheiro de desempenho reconheceu que o aplicativo não precisava de muita ajuda.

Por fim, pedi a Claude que configurasse um sistema de controle de despesas para gerenciar pelo menos 10,000 transações.

A demanda: Agora, atue como engenheiro de desempenho sênior, preparando este rastreador de despesas para lidar com milhares de transações.

Analise a implementação atual em busca de renderização desnecessária, cálculos redundantes, classificação ou filtragem ineficientes, gargalos de armazenamento, crescimento de memória e interações que podem se tornar lentas à medida que o tamanho dos dados aumenta.

Não presuma que haja um problema de desempenho. Crie uma maneira realista de testar o aplicativo com pelo menos 10,000 transações e estabeleça uma linha de base para operações críticas.

Implemente apenas as melhorias justificadas pela análise. Mantenha a aparência do aplicativo, as melhorias de acessibilidade e o comportamento atual. Não declare melhoria de velocidade a menos que a tenha medido ou definido claramente como uma melhoria esperada.

Claude descobriu um gargalo particularmente significativo. O aplicativo estava criando um novo objeto de formato de moeda sempre que exibia um valor. Com 10,000 linhas, Claude mediu esse processo em 349 milissegundos. Reutilizar um único formatador reduziu o tempo para 5.2 milissegundos, o que, segundo os cálculos de Claude, representa uma melhoria de 67 vezes.

Claude também adicionou um recurso de "virtualização de tabelas", o que significa que o navegador exibirá apenas as transações visíveis na tela no momento, em vez de milhares de linhas simultaneamente. As atualizações de pesquisa e armazenamento foram atrasadas em uma fração de segundo para evitar repetições dispendiosas após cada pressionamento de tecla ou alteração rápida.

Claude chegou a adicionar botões que podem gerar 1,000, 10,000 ou 50,000 transações de amostra para testes de estresse.

Mas a parte mais convincente do relatório foi a admissão de Claude de que a maioria dessas melhorias não eram necessárias para a finalidade pretendida do aplicativo.

Uma família típica pode adicionar entre 30 e 50 transações por mês. Mesmo uma década depois, Claude concluiu que o aplicativo original provavelmente teria lidado com os dados resultantes sem grandes problemas. Além do cache do formatador de moeda, a maioria das melhorias só foi útil porque eu solicitei especificamente suporte para milhares de transações.

Essa contenção (ou autocontrole) pareceu mais “madura” e “profissional” do que simplesmente fazer mudanças apenas por fazer.

Minha conclusão final

Achei essas afirmações extremamente eficazes, pois cada uma destacou claramente os pontos fortes e fracos de Claude. Cada função ofereceu uma perspectiva única para avaliação, o que considerei muito útil e certamente aplicarei em minhas futuras análises de outros aplicativos e sites.

Enquanto o engenheiro de depuração descobriu comportamentos incorretos, o engenheiro de front-end encontrou problemas de acessibilidade e usabilidade. O engenheiro de desempenho, por outro lado, considerou as implicações do aumento do volume de dados e reconheceu quando a otimização era desnecessária.

A experiência também demonstrou por que usar uma exigência única e abrangente como "Deixe isso pronto para produção" pode não ser a melhor abordagem. Uma única revisão pode deixar passar questões importantes, mesmo que a exigência pareça completa. Dividir o trabalho em fases específicas reduziu as prioridades de Claude e facilitou a avaliação dos resultados.

Apenas fique atento aos limites de uso da nuvem. Da próxima vez, talvez eu tente combinar os prompts para evitar atingir o limite máximo permitido.

---

---