Engenharia reversa de software: REA além da demo

Por que isso importa

Copiar a aparência de um aplicativo ficou mais acessível. Reproduzir suas regras, seus estados de erro e o comportamento que aparece depois de semanas de uso continua exigindo investigação. Para quem desenvolve, mantém sistemas antigos ou cria integrações, essa diferença determina quanto trabalho sobra depois da demonstração impressionante.

Minha leitura deste episódio do The Next New Thing é que o assunto mais interessante está no controle que as ferramentas especializadas oferecem ao agente. REA aproxima a investigação do aplicativo; HyperFrames e Diagram Design dão estrutura à produção visual; as skills ajudam a orientar decisões técnicas. O ganho precisa aparecer na qualidade da entrega e no esforço de revisão.

Por isso, eu trataria a promessa de “copiar qualquer app” como uma hipótese para testar. A contribuição deste texto é um protocolo de avaliação: escolher um comportamento verificável, comparar o agente com e sem a ferramenta e decidir com evidências. É um experimento proposto a partir do vídeo, sem presumir resultados que o Luiz ainda não mediu.

Pontos principais

• 03:53 Uma cópia funcional ainda precisa de critérios de equivalência. A reprodução do jogo 2048 demonstra um fluxo observável funcionando. Para avaliar uma aplicação de trabalho, eu acrescentaria entradas inválidas, persistência e regras menos visíveis. Parecer igual na tela cobre apenas uma parte da entrega.
• 15:01 O exemplo do Ghidra revela uma decisão insegura no aplicativo de teste. A demonstração encontra um código embutido no programa criado pelos apresentadores. Isso permite discutir segredos distribuídos junto com o cliente; não demonstra recuperação universal de senhas. A capacidade de decompilação faz parte do Ghidra oficial.
• 04:59 A ferramenta especializada precisa vencer uma comparação justa. Os apresentadores relatam um exemplo em que adicionar REA não ajudou na reprodução do Preview. Esse é um contraponto útil ao entusiasmo inicial: instalar mais uma camada só compensa quando ela resolve uma dificuldade identificável.
• 07:46 Os testes precisam conferir uma regra externa ao código gerado. A discussão sobre TDD mostra por que uma tela final com testes verdes conta pouco sobre o processo. Já a skill de SwiftUI, discutida em 23:20, aborda outro problema: orientar o agente com conhecimento específico. As duas propostas exigem revisão do que o agente recebeu como referência.
• 13:55 Restrições visuais podem economizar tentativas. Diagram Design é apresentado como uma forma de começar com estruturas simples e personalizáveis. HyperFrames, demonstrado em 11:41, aplica controle por código à produção de vídeo. Minha régua seria quanto custa alterar um detalhe depois da primeira versão.
• 18:22 Resumo de contexto pode perder justamente a exceção importante. A crítica ao Billion Context trata da redução semântica do histórico. Ela não se aplica a toda forma de compressão. Para investigar um aplicativo, perder uma condição de borda pode produzir uma reconstrução convincente e incorreta.
• 21:43 O objeto físico acrescenta uma verificação que a imagem não oferece. A conversa sobre Text to CAD destaca medir, imprimir e ajustar. O equivalente no software é executar casos reais e observar falhas; a prévia bonita ajuda a revisar, mas não encerra a avaliação.
• 24:58 Controle sobre o aplicativo tem um custo de manutenção. O openGym entra na discussão pela possibilidade de acompanhar exercícios sem as distrações comerciais criticadas pelos apresentadores. Já o AnyPS5, em 05:32, mostra uma iniciativa de compatibilidade ainda cercada de limitações no episódio. Código disponível e ambição técnica precisam ser avaliados junto com a operação cotidiana.

Como aplicar

Engenharia reversa de software: um teste em uma hora

Eu começaria com um utilitário próprio que importa CSV e calcula totais. Guarde o código-fonte como gabarito para a revisão, separado do material entregue ao agente. Disponibilize a aplicação executável, arquivos fictícios de entrada e uma descrição curta da tarefa. Assim, você conhece o comportamento esperado e consegue conferir as conclusões.

O REA conecta agentes a ferramentas de inspeção de aplicativos, binários e comportamento em execução. A documentação também diferencia análise de JavaScript e análise nativa. Escolha o caminho correspondente ao seu aplicativo antes de configurar dependências.

Distribua a primeira hora assim: dez minutos para definir o comportamento, quinze para uma tentativa com o agente habitual, vinte para uma tentativa com REA em sessão nova e quinze para comparar as entregas. Esse limite serve para descobrir obstáculos e decidir se vale aprofundar.

Escreva o gabarito antes de pedir a reconstrução

Uma lista de engenharia reversa exemplos só ajuda quando permite conferir uma resposta. Para o importador, use casos como estes:

| Caso | O que conferir | | --- | --- | | Nome com acento | O texto permanece correto depois da importação | | Valor 1.234,56 | O total segue a convenção definida pelo aplicativo | | Arquivo vazio | A aplicação apresenta o comportamento esperado | | Linha duplicada | A regra original de duplicidade é preservada | | Valor inválido | O erro é identificado sem alterar registros válidos |

Defina as respostas observando o programa original e conferindo seu código. Não deixe o agente inventar a regra e depois usar essa mesma regra para declarar sucesso. O contexto brasileiro aparece aqui em detalhes concretos: separadores numéricos, acentuação e formatos de arquivo realmente usados pela equipe.

Separe observação, hipótese e implementação

Este seria meu pedido inicial:

Investigue apenas a importação de CSV deste aplicativo. Registre entradas, saídas e mensagens observadas. Separe fatos observados de hipóteses. Associe cada conclusão à evidência disponível e indique o que você não conseguiu verificar. Depois, proponha uma implementação independente e testes para os comportamentos confirmados.

Esse registro facilita descobrir se um erro nasceu na investigação ou na implementação. Se a tarefa envolve um binário, trate o código decompilado como material de análise: nomes, comentários e estrutura do projeto original podem não estar disponíveis. Se a investigação encontrar um segredo embutido, registre o achado separadamente da reprodução funcional.

Compare correção e esforço de revisão

Use o mesmo modelo, os mesmos arquivos e os mesmos critérios nas duas tentativas. Anote versão das ferramentas, tempo de configuração, tempo de execução, custo do modelo quando disponível e quantidade de intervenções humanas. Sessões novas ajudam a evitar que a segunda tentativa herde descobertas da primeira.

Conte os casos que passaram e examine os que falharam. Uma entrega que acerta o fluxo principal e perde linhas com valores inválidos pode gerar mais trabalho do que economiza. Também confira se o agente consegue explicar de onde veio cada regra implementada.

Se optar por TDD na reconstrução, trabalhe um comportamento por vez: escreva um teste, confirme que falha pelo motivo esperado, implemente o necessário e reorganize o código mantendo o teste verde. Acrescente casos de aceite revisados por uma pessoa para conferir a compreensão do problema.

Peça uma alteração antes de adotar

Depois da primeira versão, mude uma exigência: outra coluna no CSV, uma mensagem de erro mais clara ou uma regra adicional de validação. Observe se a alteração preserva os casos anteriores e quanto precisa ser explicado novamente.

Essa mesma pergunta ajuda a avaliar as outras ferramentas do episódio. Um vídeo permite trocar apenas o preço exibido? Um diagrama continua legível com uma etapa extra? Uma peça CAD preserva as medidas depois de arredondar os cantos? Um histórico resumido ainda aponta para a evidência original?

Minha condição para adotar REA seria conseguir repetir um ganho em uma tarefa real: mais comportamentos corretos, menos investigação manual ou revisão mais rápida. Salve os arquivos de teste, as evidências e as limitações junto da entrega. Isso deixa uma base verificável para a próxima manutenção.