/ Tecnologia /
Engenharia reversa com IA: como agentes recriam aplicativos e jogos
Alternativas a apps da Adobe, jogos retrô e skills no GitHub: como a IA transforma observação em uma nova implementação.
Uma IA entra em um aplicativo, observa como ele funciona e ajuda a escrever outro programa com funções semelhantes. Essa ideia já aparece em projetos públicos de reconstrução de software, skills para agentes e ferramentas para jogos retrô. O assunto não se limita a desenhar uma tela parecida: envolve transformar o comportamento observado em uma nova implementação.
Para entender esse movimento, reunimos exemplos verificáveis no GitHub: alternativas a aplicativos da Adobe, fluxos de recriação de apps e análise de jogos. Eles não formam uma única ferramenta e não usam todos o mesmo método.
O movimento: observar, entender e reconstruir
O ponto de partida deixa de ser apenas “crie um aplicativo com estas funções”. Um produto existente vira referência: o agente examina telas, percorre fluxos e organiza o que precisa funcionar. Depois, escreve uma implementação e compara o resultado com aquilo que observou.
É essa a proposta do Remaster ↗. Sua documentação descreve pesquisa em páginas e materiais públicos, mapeamento de telas e estados, construção de uma nova versão e verificações. O projeto propõe preservar a lógica de uso com identidade própria, sem reutilizar código, textos ou imagens do original.
Em termos simples, o ciclo é: observar → descrever o comportamento → programar → testar → corrigir. “Escanear tudo” é uma simplificação: a IA trabalha com as telas, os dados e as ferramentas aos quais efetivamente tem acesso, não com conhecimento automático de todo o produto.
O caso Adobe: novas aplicações, não o código original
Um exemplo concreto é o PhotoCraft ↗, da ArtCraft. O repositório o apresenta como uma reimplementação independente do Photoshop em Rust, feita a partir de especificações públicas e comportamento observado. A documentação descreve camadas, máscaras e trabalho com arquivos PSD. A mesma família inclui o LightCraft ↗, voltado à organização e edição de fotografias e apresentado como uma reimplementação do Lightroom.
O importante aqui é a ambição: construir outro programa que realize tarefas conhecidas de uma ferramenta comercial. Isso não equivale a liberar o Photoshop gratuitamente nem a recuperar o código-fonte da Adobe. São projetos independentes, sem vínculo oficial com a empresa.
Há uma ressalva concreta no próprio PhotoCraft: o projeto se declara em estágio inicial e ainda não se apresenta como substituto do Photoshop para trabalho profissional diário. Uma interface familiar pode coexistir com recursos incompletos. Os repositórios consultados também não comprovam que toda essa família tenha sido produzida por uma única skill ou por uma simples varredura automática.
O que as skills do GitHub acrescentam
Uma skill organiza instruções e, em alguns casos, scripts para conduzir o agente por uma tarefa. Não é um botão que transforma qualquer sistema em uma cópia perfeita: ela define o que investigar, quais documentos produzir e como conferir o resultado.
O Replica ↗ reúne skills para investigar um aplicativo, planejar sua reconstrução, implementar e testar. Sua proposta inclui estudar reclamações dos usuários para desenvolver uma alternativa com melhorias, em vez de apenas repetir a experiência existente. A documentação diferencia reproduzir funcionalidades de tomar o código, a marca e o conteúdo de outro produto.
Já o REA, Reverse Engineer Anything ↗, combina instruções com ferramentas de análise conectadas ao agente. Ele descreve a inspeção de aplicativos e de seu comportamento para produzir evidências que possam orientar uma nova implementação. Essa abordagem pode ir além das telas e examinar arquivos e componentes. São caminhos diferentes: observar a experiência de uso não é o mesmo que analisar o programa internamente.
E os jogos que aparecem rodando no navegador?
Nos jogos, um exemplo relacionado é o re-skill ↗, voltado ao Claude Code. Segundo o repositório, ele organiza projetos de engenharia reversa de jogos retrô a partir de ROMs ou executáveis, com análise, documentação, extração de recursos e adaptação para canvas na web. O autor relata uso com NES, Game Boy e DOS.
Isso ajuda a explicar o tipo de demonstração em que um jogo antigo reaparece em outro ambiente. Nesse caso, porém, o material de partida pode incluir o próprio arquivo do jogo, não apenas um vídeo ou uma captura de tela.
Um projeto disponível no GitHub não deve ser tratado como autorização automática para redistribuir todos os jogos e seus recursos. Antes de usar, confira separadamente a licença do código e a origem de imagens, músicas e arquivos necessários. Este artigo apresenta a proposta documentada da ferramenta; não certifica um catálogo de jogos gratuitos nem o funcionamento de cada adaptação.
Por que isso importa para quem cria produtos
Nossa leitura é que o avanço está na aproximação entre pesquisa e implementação. Aquilo que uma equipe aprende ao experimentar um produto pode virar uma especificação inicial, código e testes em um mesmo processo assistido por IA.
Imagine uma empresa que precisa de um agendamento específico para sua operação. Estudar como ferramentas existentes resolvem seleção de horário e confirmação pode ajudar a formular requisitos. A oportunidade está em criar uma solução adequada à necessidade, com regras e identidade próprias, não em reproduzir uma marca conhecida.
Para negócios digitais, isso reforça uma questão estratégica: além da lista de funcionalidades, que valor o produto oferece? Atendimento, integrações, confiança, conhecimento do setor e manutenção continuam importantes mesmo quando uma primeira versão se torna mais fácil de construir.
Como separar uma demonstração de um produto pronto
Antes de trocar uma ferramenta usada no trabalho, teste uma tarefa completa: importar um arquivo real, fazer alterações, salvar, reabrir e exportar. Em aplicativos com dados, confira permissões, falhas e recuperação. Não basta o botão aparecer na tela.
Os exemplos desta matéria foram conferidos em documentação pública, sem instalação nem testes independentes dos aplicativos. As capacidades descritas são declarações dos respectivos projetos, não uma certificação da Bādon.
O fenômeno existe e merece atenção: agentes podem usar a investigação de software como ponto de partida para novas implementações. A conclusão não é que qualquer aplicativo já possa ser reconstruído integralmente com um comando. É que observar, documentar, construir e comparar estão ficando mais próximos dentro do trabalho de desenvolvimento.
DA LEITURA À PRÁTICA
O que conferir no projeto
- Abra o repositório original e confira o estágio de desenvolvimento.
- Veja se o método observa telas, analisa arquivos ou combina as duas abordagens.
- Diferencie uma função demonstrada de compatibilidade completa.
- Confira licenças, permissões e origem dos recursos usados.
- Teste com cópias dos seus arquivos antes de adotar no trabalho.
Fontes e leitura complementar
Documentação dos próprios projetos consultada em 16 de outubro de 2026. As descrições abaixo não substituem testes independentes. Recursos e disponibilidade podem mudar após a data da consulta.
