REA (Reverse Engineer Anything) and ArtCraft: reverse engineering with AI and the future of SaaS

AI agents make it easier to rebuild software, and ArtCraft is aiming at Adobe's tools. What changes for SaaS companies, and how to defend your value with specialization, data, and innovation.

If a customer could use AI to recreate the three features they use most in your product, would they still pay for the subscription?

REA, Morluto's reverse-engineering project, lets an agent investigate existing software. ArtCraft is building alternatives to applications such as Photoshop and Premiere. They are two signals of a shift that affects the software business: features are easier to reproduce, and value also has to rest on specialization, data, and service quality.

To understand the threat, it helps to see how this reconstruction works and what changes when the product is a SaaS.

What REA is and how reverse engineering with AI works

REA, short for *Reverse Engineer Anything*, connects coding agents with reverse-engineering tools. It does so through commands and MCP, the protocol that lets an agent use external tools.

Imagine a function written by a developer. Here is a teaching example in C:

unsigned duplicar(unsigned numero) {
    return numero * 2u;
}

unsigned duplicar(unsigned numero) {
    return numero * 2u;
}

unsigned duplicar(unsigned numero) {
    return numero * 2u;
}

When you compile it to run directly on a processor, it becomes machine instructions. Whoever analyzes the executable does not get that readable source code: they start from bytes, represented as ones and zeros. For the body of this function, one possible sequence on x86-64 with the System V calling convention is:

Binary:      10001101 00000100 00111111 11000011
Hexadecimal: 8D       04       3F       C3

Binary:      10001101 00000100 00111111 11000011
Hexadecimal: 8D       04       3F       C3

Binary:      10001101 00000100 00111111 11000011
Hexadecimal: 8D       04       3F       C3

These are two representations of the same four bytes. A full executable contains many more instructions, plus data and other structures. The exact result depends on the architecture, the compiler, and its options.

Engineers have studied these files for decades. A traditional disassembler translates instructions into a textual form called assembly. For those bytes, the reading would be:

lea eax, [rdi + rdi]
ret

lea eax, [rdi + rdi]
ret

lea eax, [rdi + rdi]
ret

Here the argument is added to itself and the result is returned. A decompiler can reconstruct something close to C:

unsigned funcion(unsigned parametro) {
    return parametro + parametro;
}

unsigned funcion(unsigned parametro) {
    return parametro + parametro;
}

unsigned funcion(unsigned parametro) {
    return parametro + parametro;
}

We have recovered equivalent logic, but not the original names or the intent of whoever wrote it. In large applications, optimizations, jumps between functions, and data structures make that interpretation much harder.

Binaries could be analyzed before AI: tools such as Ghidra include disassembly and decompilation. REA lets the agent use those instruments, follow references, form hypotheses, and code a reconstruction that must then be verified. AI adds value by connecting the clues and turning them into an implementation you still have to check.

Rebuilding a function from a compiled program: the DX-Ball case

DX-Ball is a brick-breaker game: a ball bounces on a paddle the player controls and destroys blocks on the screen. When it hits a brick, a sound plays. The case published by REA reconstructs how that sound pans between left and right speakers depending on the position of the brick that was hit.

The first decompilation omits part of the calculation. The agent inspects the instructions and constants in the executable. Among the operations you see:

FMUL double ptr [0x00420068]
FSUB double ptr [0x00420070]

FMUL double ptr [0x00420068]
FSUB double ptr [0x00420070]

FMUL double ptr [0x00420068]
FSUB double ptr [0x00420070]

Those addresses hold the values 1.5625 and 500.0. A simplified version of the reconstructed calculation, passing the scale as an argument for readability, would be:

int posicion_estereo(int x, double escala) {
    return (int)(((double)x * 1.5625 - 500.0) * escala);
}

int posicion_estereo(int x, double escala) {
    return (int)(((double)x * 1.5625 - 500.0) * escala);
}

int posicion_estereo(int x, double escala) {
    return (int)(((double)x * 1.5625 - 500.0) * escala);
}

Here, x is the horizontal coordinate in pixels. With scale 1, x = 0 places the sound on the left (-500), x = 320 in the center (0), and x = 640 on the right (500).

The project publishes 3,205 comparisons with the original function and a match of its 63 compiled bytes. Those are results for that function; reconstruction of the full game was still in progress.

Can REA help replicate a SaaS or a web app?

Yes. REA also includes analysis of pages and scripts in the browser, as well as analysis of network traffic captures. Its applications go beyond desktop executables, though the information available changes.

In many web apps, the browser receives JavaScript that can be inspected, even when it is bundled or minified. It also lets you observe screens, interactions, and the requests exchanged with the server. That information helps you understand how the accessible part of the product works.

The backend stays on another machine. Observing a request and its response does not automatically reveal the code that processes it, the private database, or all the business rules. The developer has to build that part with their own implementation and validate its behavior.

Think of a task manager as a hypothetical example. You can study how cards are created, which fields they use, and how they move between columns. Rebuilding that flow can be relatively feasible. Reproducing team permissions, sync, history, and integrations as well adds work the interface does not fully explain.

So being a web app does not block using REA; the barrier is what happens outside the observable part. The more value depends on private data, internal processes, and complex integrations, the more remains to solve.

A competitor does not need to reproduce the entire service either. In his video on REA, Nate Herk describes a prototype inspired by Loom that records with the camera and stores files locally. It can cover a specific need without offering the full collaboration and hosting platform.

That same logic helps explain the ArtCraft threat to Adobe: rebuild enough features of a known tool so that some users can drop their subscription.

What ArtCraft is and why it threatens Adobe's model

The Crafting Apps are presented as independent reimplementations of well-known applications, as the PhotoCraft repository explains. That work fits the goal of reverse engineering: study how a solution works and rebuild equivalent capabilities. There is no proof they used REA or decompiled Adobe's programs. The connection is in the outcome they pursue.

ArtCraft brings together two proposals. Its visual creation studio lets you work with AI-generated images and video. The Crafting Apps are the editors that pose direct competition:

Its creator, Brandon Thomas, places these reimplementations in the context of development with AI agents.

PhotoCraft and FilmCraft publish their code under MIT/Apache-2.0 licenses. The generation studio also offers credit-based plans: having the software does not necessarily remove the cost of models or compute.

There is another feature that matters for agents. The PhotoCraft MCP lets you discover and run commands and inspect documents. The proposal includes automation of creative work, not only new tools to do it manually.

Maturity is still an open question. PhotoCraft documents gaps in PSD fidelity, performance, and plugins. In his FilmCraft test, Fireship describes smoothness issues and considers it does not yet meet his professional needs.

Adobe combines desktop applications with cloud services under a subscription model. The commercial threat to that model can arrive before full parity. A company that trims clips or prepares simple images may need fewer features than a professional studio. If an alternative solves those tasks reliably and at lower total cost, the subscription becomes harder to justify for that segment.

For any SaaS, the question is similar: what part of our product does a competitor need to recreate to solve the customer's main job?

Three levers to build a more defensible SaaS

1. Vertical focus: solve a job in depth

A specialized SaaS embeds the decisions, exceptions, and integrations of a sector. That widens the work anyone competing with it must solve.

Think of an invoicing product for logistics. Extracting fields is a bounded function. Linking them to shipments, checking agreed rates, spotting surcharges, and handling discrepancies requires understanding the customer's operations. Defensibility grows when that knowledge measurably reduces incidents and manual review.

2. Data: quality, protection, and context

An agent with authorized access to current rates, agreements, and incident resolutions can make better-grounded decisions than one that only sees an invoice.

The value lies in obtaining, relating, and maintaining reliable information, with traceability and proper permissions. Integrations and validation processes can be hard to reproduce. Protecting that data and customer trust sustains the advantage; using them only as a lock-in lever erodes it.

3. Innovation: improve outcomes with AI

AI lets you revisit how a process is completed. An agent could prepare a reconciliation, explain discrepancies, and ask for approval on exceptions, reducing manual work.

That evolution requires deciding what to automate, how to detect errors, and when a person must step in. Innovation adds defensibility when the customer gets better results with verifiable quality. In AI agents in production for SaaS we cover the implications for permissions, observability, and recovery.

A SaaS is also valuable because it keeps working

Building your own alternative can make sense. Whoever adopts it also takes on maintenance: integrations that change, unexpected formats, updates, permissions, incidents, and data recovery.

AI helps you code fixes, but someone has to verify they work and respond when the service fails. That ongoing work can turn an initial saving into fragility and maintenance load for the customer.

A SaaS that runs well keeps each company from having to organize that responsibility on its own. When you compare build versus buy, the cost includes implementation, infrastructure, review, support, and failures.

REA and ArtCraft make the pressure on reproducible features visible. Our read is that SaaS companies should go deeper in their sector, work with reliable protected data, and innovate on customer needs. The three levers gain strength when paired with excellent operation, sustained over time.

At Devic we work on bringing AI agents into SaaS products: choosing what to automate and sustaining quality in production are part of the same product decision.

Sources and development status checked on 14 October 2026. The first compilation example is didactic; the DX-Ball code is presented in adapted simplified form. Published results and tests are attributed to their authors.