Descobri o Segredo! Fiz o Claude Virar um Time de Engenheiros Sênior e o Resultado Me Chocou!
Olá, pessoal! Aqui é o Lucas Tech, e hoje a gente vai mergulhar em um experimento que realmente abriu meus olhos sobre o poder da inteligência artificial. Você já deve ter visto por aí, principalmente no X (o antigo Twitter), um monte de gente compartilhando prompts "mágicos" que prometem deixar os chatbots super eficazes, né?
Confesso, quando vi uma coleção de prompts do David Max, um educador de IA, fiquei com um pé atrás. "Será que é só hype?", pensei. Mas a curiosidade falou mais alto! Os prompts diziam que podiam transformar o Claude em qualquer coisa, desde um engenheiro de debugging sênior até um especialista em performance. E é exatamente por isso que decidi testar! Preparem-se, porque o que aconteceu em seguida foi surpreendente.
O Desafio: Apresentando Meu Controle de Gastos Domésticos ao Claude!
Eu já tinha criado um app genérico para controle de gastos, com uns "placeholders" para despesas, usando o ChatGPT Work. Peguei ele como base e pedi para o Claude fazer uma "revisão" quatro vezes. Mas não foi uma revisão qualquer! Cada vez, eu dei uma persona diferente para ele, como se fosse um engenheiro sênior especializado: engenheiro full-stack, engenheiro de debugging, engenheiro frontend e engenheiro de performance.
O resultado foi MUITO mais revelador do que se eu simplesmente tivesse pedido para o Claude "melhorar o app". Cada "persona" se concentrou em um conjunto diferente de problemas – e, às vezes, encontrava questões que o "desenvolvedor" anterior tinha deixado passar batido! Bora ver o que rolou e quais prompts eu usei.
1. O Engenheiro Full-Stack Sênior: A Base de Tudo!
Comecei pedindo para o Claude criar um controle de gastos domésticos interativo, algo que qualquer pessoa pudesse usar no dia a dia.
O prompt: Crie um controle de gastos domésticos interativo que uma pessoa comum possa usar para registrar e entender seus gastos. Inclua a capacidade de adicionar e excluir despesas, atribuir categorias, filtrar transações, calcular o gasto total e exibir um detalhamento visual por categoria.
Pense como um engenheiro full-stack sênior desenvolvendo um MVP (Produto Mínimo Viável) de uma startup polido. Antes de escrever qualquer código, descreva brevemente a arquitetura, a estrutura de dados e o fluxo do usuário. Em seguida, construa o aplicativo funcional como um Claude Artifact.
Torne-o responsivo e fácil de usar, mas não gaste tempo adicional revisando, depurando ou otimizando o código finalizado. Pedirei a outros "desenvolvedores" para cuidarem dessas etapas.
Para minha surpresa, o Claude criou um aplicativo React incrivelmente polido! Ele já veio com transações de exemplo, totais de gastos, detalhamento por categoria, busca, filtros e a capacidade de organizar transações por data. Ah, e ainda salvava as mudanças, então elas continuavam lá mesmo depois de reabrir o app.
À primeira vista, parecia muito mais um produto final do que um protótipo inicial. Tinha cartões de estatísticas no topo, um formulário de despesas limpo e barras coloridas mostrando quanto foi gasto em cada categoria. Arrasou!
2. O Engenheiro de Debugging Sênior: Caçando Bugs!
Em seguida, pedi para o Claude esquecer um pouco a aparência e investigar seu próprio trabalho, como um engenheiro de debugging se preparando para o lançamento de um app.
O prompt: Agora atue como um engenheiro de debugging sênior que herdou esta aplicação antes de seu lançamento ao público.
Examine cuidadosamente o aplicativo e seu código existente sem alterar sua funcionalidade pretendida ou design visual. Teste os principais fluxos de usuário e procure por bugs funcionais, tratamento de entrada inválida, riscos de perda de dados, cálculos incorretos, problemas de persistência e casos extremos.
Antes de editar o código, me forneça um relatório conciso de debugging contendo o que você testou, cada problema que encontrou, a causa raiz de cada problema, a gravidade de cada problema e a correção que você recomenda.
Em seguida, implemente as correções e verifique se os recursos originais ainda funcionam. Não redesenhe a interface, não execute uma refatoração arquitetural mais ampla nem faça alterações puramente cosméticas.
Essa passada de debugging encontrou vários problemas reais.
Por exemplo, os campos de entrada originais não estavam dentro de um formulário adequado. Clicar em "Salvar Transação" funcionava, mas apertar Enter talvez não. O Claude corrigiu isso, transformando a seção em um formulário de verdade com um botão de envio.
Ele também descobriu que os usuários podiam apagar a data e salvar uma transação com informações de data inválidas. O Claude adicionou validação de data, reforçou as verificações para valores inválidos e corrigiu um cálculo que fazia com que "Moradia" aparecesse como a maior categoria mesmo quando o controle estava vazio.
Pontos negativos? As transações ainda podiam ser excluídas permanentemente com um clique só. Falhas de armazenamento continuavam escondidas no console do desenvolvedor, ou seja, o usuário podia achar que salvou a informação quando não salvou. E o Claude também não criou testes automatizados para confirmar que as correções funcionavam.
3. O Engenheiro Frontend Sênior: Olho Clínico na Experiência do Usuário!
Para a terceira rodada, pedi para o Claude analisar o controle de gastos como um engenheiro frontend especializado em design responsivo e acessibilidade.
O prompt: Agora atue como um engenheiro frontend sênior especializado em aplicações de consumo acessíveis e responsivas.
Revise o controle de gastos atual da perspectiva de alguém usando-o em um telefone, com um teclado ou com tecnologia assistiva. Preserve sua funcionalidade e identidade visual geral, mas melhore sua usabilidade e acessibilidade.
Antes de alterar o código, forneça uma revisão concisa cobrindo comportamento móvel e responsivo, navegação por teclado, usabilidade do formulário, acessibilidade para leitores de tela, contraste de cores, estados de carregamento e erro, ações destrutivas e controles confusos.
Em seguida, implemente as melhorias. Certifique-se de que cada campo de entrada e controle interativo tenha um nome acessível, os estados de foco sejam claramente visíveis, as mensagens de validação possam ser anunciadas por um leitor de tela e o detalhamento de gastos comunique informações sem depender apenas de barras coloridas.
Essa foi, sem dúvida, a revisão mais completa de todo o experimento!
O Claude notou que o app removia o contorno normal em volta dos campos selecionados sem oferecer um substituto. Ou seja, alguém navegando com o teclado teria dificuldade em ver qual campo estava ativo. Que perigo!
Ele também descobriu que os rótulos visíveis não estavam conectados corretamente aos seus campos correspondentes, o campo de busca dependia apenas do texto do placeholder e os erros de validação não estavam configurados para serem anunciados por leitores de tela.
O Claude restaurou os indicadores de foco visíveis, conectou os rótulos aos controles do formulário, adicionou descrições para leitores de tela e aumentou o contraste de vários elementos de texto cinza-claro. Ele também tornou a barra de busca mais flexível em telas pequenas e adicionou rótulos mais descritivos aos botões que só tinham ícones.
Mas o mais legal, galera, é que essa persona pegou o problema de exclusão que o engenheiro de debugging tinha deixado passar! O Claude substituiu o botão de exclusão de clique único por uma confirmação de duas etapas, perguntando aos usuários se queriam realmente excluir ou manter a transação. Ufa!
Nem tudo foi perfeito, claro. O Claude descreveu 44 por 44 pixels como tamanho mínimo para o alvo de toque, mas aumentou o botão de exclusão primário para apenas 36 por 36 pixels. Isso satisfaz o alvo menor do WCAG 2.2 AA, mas não a recomendação de 44 pixels que ele mesmo citou. Pequenos detalhes, né?
Mesmo assim, ficou claro que mudar o "papel" do Claude mudou totalmente o que ele enxergava. O engenheiro de debugging examinava se o app funcionava. Já o engenheiro frontend considerava se uma pessoa de verdade poderia usá-lo confortavelmente. Genial!
4. O Engenheiro de Performance Sênior: Otimizando o Que Realmente Importa!
Por último, pedi para o Claude preparar o controle de gastos para lidar com, pelo menos, 10.000 transações. Muita coisa!
O prompt: Agora atue como um engenheiro de performance sênior preparando este controle de gastos para lidar com milhares de transações.
Analise a implementação atual em busca de renderizações desnecessárias, cálculos repetidos, ordenação ou filtragem ineficientes, gargalos de armazenamento, crescimento de memória e interações que podem se tornar lentas à medida que o conjunto de dados aumenta.
Não presuma que existe um problema de performance. 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 importantes.
Em seguida, implemente apenas otimizações justificadas pela análise. Preserve a aparência do aplicativo, as melhorias de acessibilidade e o comportamento existente. Não alegue uma melhoria de velocidade a menos que você a tenha medido ou a rotule claramente como uma melhoria esperada.
O Claude encontrou um gargalo especialmente significativo. O app criava um novo objeto para formatar moeda toda vez que exibia um valor. Com 10.000 linhas, o Claude mediu esse processo em 349 milissegundos. Reutilizar um único formatador reduziu para 5,2 milissegundos, uma melhoria de 67 vezes! Que diferença!
Ele também adicionou virtualização de tabela, o que significa que o navegador renderizaria apenas as transações visíveis na tela, em vez de milhares de linhas de uma vez. As atualizações de busca e armazenamento foram atrasadas em uma fração de segundo para evitar repetir um trabalho "pesado" após cada digitação ou mudança rápida.
O Claude até adicionou botões que podiam gerar 1.000, 10.000 ou 50.000 transações de exemplo para testes de estresse. É tipo um "modo turbo" para testar os limites do app!
Mas a parte mais convincente do relatório, na minha opinião, foi a admissão do Claude de que a maior parte disso era desnecessária para o propósito original do app.
Uma família pode adicionar de 30 a 50 transações por mês. Mesmo depois de uma década, o Claude concluiu que o aplicativo original provavelmente teria lidado com os dados sem um problema perceptível. Tirando o cache do formatador de moeda, a maioria das otimizações só foi útil porque eu tinha especificamente pedido suporte para milhares de transações.
Essa "moderação" me pareceu muito mais "sênior" do que simplesmente fazer mudanças porque "pode". Incrível!
Meu Veredito Final (e algumas Dicas!)
Pois é, pessoal! Achei que esses prompts funcionaram muito bem, e cada um destacou o que o Claude faz bem e onde ele ainda tem seus limites. Cada papel foi uma lente diferente para a revisão, e isso foi super útil! Com certeza vou implementar essa ideia em outros apps e sites.
Enquanto o engenheiro de debugging encontrava comportamentos quebrados, o engenheiro frontend identificava problemas de acessibilidade e usabilidade. O engenheiro de performance pensava no que aconteceria com mais dados – e soube reconhecer quando uma otimização era desnecessária.
O experimento também mostrou por que um prompt enorme tipo "deixe isso pronto para produção" talvez não seja a melhor abordagem. Uma única revisão pode ignorar questões importantes, mesmo que o prompt pareça super completo. Dividir o trabalho em etapas focadas deu ao Claude menos prioridades para gerenciar e tornou suas descobertas mais fáceis de avaliar.
Só fiquem de olho nos limites de uso do Claude, viu? Na próxima, talvez eu tente combinar alguns prompts para não estourar meu limite.
Minha Visão
Galera, essa experiência com o Claude mudou totalmente minha forma de ver a IA no desenvolvimento de projetos. Não é só pedir "faça um app" ou "melhore o código". É como ter acesso a uma equipe de especialistas de altíssimo nível, cada um com uma perspectiva única e um foco bem definido. A "engenharia de prompts" se torna um skill vital, quase como ser um maestro que orquestra uma sinfonia de inteligências artificiais. Percebi que a IA, quando bem direcionada, não é apenas uma ferramenta que executa tarefas; ela se torna um verdadeiro parceiro, capaz de pensar criticamente e oferecer insights que até nós, humanos, podemos deixar passar. É um futuro onde a colaboração entre homem e máquina atinge um novo patamar de eficiência e qualidade!
E vocês, o que acharam dessa abordagem? Já pensaram em dar "personalidades" diferentes para as suas IAs? Qual "chapéu" de engenheiro vocês pediriam para a IA usar no seu próximo projeto? Me contem nos comentários!
Referência: Matéria Original
