AI Reverse Engineering Is Getting Easier. Can It Really Replace Adobe?

Reporting checked October 10, 2026, Pacific time.

An AI agent that can explain an unfamiliar program is useful. An agent that can rebuild a feature from that explanation could change how software gets made. A free application that reliably replaces a professional creative workflow would change what people need to buy.

Those are three different achievements. The online discussion about AI reverse engineering keeps compressing them into one.

On October 8, Matthew Berman posted: “Reverse Engineer Anything 😂 Software is done.” His follow-up linked to REA, a project that connects coding agents to software-analysis tools. Around the same time, ArtCraft’s open-source alternatives to Adobe applications were drawing attention on Reddit and Hacker News. Together, the stories offered an irresistible premise: point AI at expensive software, reconstruct it, and end the subscription. Berman’s post and repository follow-up.

There is a consequential development here. Public projects now combine agent interfaces, source repositories, releases, and explicit attempts to reproduce familiar creative workflows. But the evidence supports a more specific story than the death of software. The cost of attempting a replacement may be falling. The cost of proving that replacement dependable remains substantial.

For a designer, the decisive moment comes after the screenshot: when a client’s layered file opens, a revision preserves the typography, the export meets the printer’s requirements, and the project opens again next month. For a developer, it comes when reconstructed behavior survives inputs that were never shown to the model. For a business, it comes when someone is responsible for a failure.

Reporting boundary: This article reviews public documentation, release metadata, developer statements, research papers, statutory material, and community discussions. We did not install or benchmark the current ArtCraft applications, run REA 6.3.0, audit model-development logs, or verify the projects’ complete provenance. “Documented” identifies a project’s stated capability; “untested” identifies behavior we have not independently established. The evaluation examples below are proposed tests, not results.

How two separate projects became one software story

ArtCraft’s developer announcement appeared on Reddit on October 3. Brandon Thomas, posting as u/ai_art_is_art, described a suite of Rust applications built with Claude Opus 5.5 and presented the work as clean-room development. That model attribution and description of the process are the developer’s account. We have not examined the session records, token bills, human interventions, or earlier code that would establish exactly how the software was produced. Original developer announcement.

REA became another focus of attention. Its name, “Reverse Engineer Anything,” helped frame a larger conversation about whether AI could strip away proprietary software’s advantages. Berman’s post linked to REA; it did not document REA being used to build ArtCraft. We found no primary evidence establishing that connection. Treating the projects as one demonstrated pipeline would manufacture a causal link the sources do not provide.

The difference matters technically. REA is analysis infrastructure for an agent. ArtCraft consists of end-user applications that aim at familiar creative tasks. A successful analysis tool does not automatically deliver a successful photo editor. A working photo editor does not reveal which tools or prompts its author used.

The public rhetoric is much broader. Thomas’s Hacker News comments include a sweeping claim about reconstructing Photoshop and a longer argument for making software more accessible. They establish his ambition and position. They do not substitute for an independent comparison against Photoshop’s behavior. Short developer comment and longer statement.

By the October 10 source check, REA’s latest listed release was 6.3.0, and all seven ArtCraft repositories had release entries with downloadable assets. These are observable publishing events. They establish that the projects are more than speculative announcements, while leaving the quality of the downloadable software open. REA releases and ArtCraft’s application directory.

That is the right starting point for the debate: there is software to investigate, and there are ambitious claims to test.

What “reverse engineering” actually describes

Reverse engineering begins with an existing artifact or observable behavior and works toward an understanding of how it functions. The artifact might be an executable, a file format, a network protocol, a browser application, or a device. The investigation can produce an explanation, a compatible implementation, a security finding, or a preservation tool. It need not produce a competing application.

Several methods get mixed together in social posts:

These distinctions explain why a convincing demonstration can be real and still support a narrow conclusion. A developer might recreate a menu, implement one filter, or reproduce an export routine. Each can be valuable. None independently establishes that a whole application has been recovered.

Compilation also loses information. Different source programs can produce similar machine code; optimization can inline functions, remove branches, and rearrange operations. A decompiler makes an interpretation of what remains. Human analysts have long worked with such interpretations using tools such as Ghidra, which supplies disassembly, decompilation, graphing, and scripting facilities. AI enters an existing discipline with existing tools. Ghidra project documentation.

The language “Adobe was reverse engineered” needs equal care. It could mean someone studied public behavior and wrote compatible software. It could imply analysis of Adobe’s binaries. It could suggest an actual source leak. Those claims require different evidence. The ArtCraft materials reviewed here describe independent implementations and impose contributor restrictions concerning Adobe code; they do not establish that Adobe’s original source was recovered or released.

What REA adds to the investigation

REA presents analysis tools through a local Model Context Protocol server and a command-line interface. Its documentation covers native binaries, JavaScript and Electron applications, .NET assemblies, and websites. Native analysis can use an installed provider such as Hopper, Ghidra, or IDA. The agent asks for an inspection, receives results, and uses those results to explain behavior or guide implementation. These are documented capabilities, untested in the current release for this article. Pinned REA README.

The practical opportunity is reducing the friction between questions. An analyst often needs to move from a string to a reference, from that reference to a function, and from that function to a hypothesis about a feature. An agent can help coordinate that work, summarize intermediate findings, and suggest what evidence would distinguish competing explanations.

Consider a hypothetical investigation of a file exporter. The initial question might be why a column is reordered. A useful agent would locate relevant code or observations, identify the ordering rule, construct a small test, and compare the result with its prediction. If the prediction fails, it should revise the explanation. An agent that merely supplies a plausible paragraph has not completed that investigation.

REA’s documentation emphasizes evidence, limitations, provider selection, and investigation artifacts. Those are valuable design choices because a conclusion should be traceable to what the tool actually observed. A response can be structurally valid while its interpretation remains wrong. A successful tool call means the operation returned; it does not prove that the agent understood the target. Pinned CLI and Evidence documentation.

Setup has its own boundary. REA connects to other software and agent clients; the analysis engine, the agent, and the target are distinct components. Reproducing a result requires their versions and configuration, along with the target’s identity. “I used REA” is about as complete a methods description as “I used a debugger.” Pinned installation documentation.

The project’s showcases illustrate why scope matters. Its DX-Ball account describes bounded native reconstruction work, while the Notion example investigates clipboard behavior in a particular historical JavaScript asset. These are project-authored case studies, not independent tests performed for this article. Neither should be promoted into proof of universal application recovery. DX-Ball showcase and Notion clipboard showcase.

Kingy’s earlier REA guide covers a narrower investigation and its evidence. Its historical results should stay attached to that experiment and version; they cannot validate REA 6.3.0 or any ArtCraft application.

Where AI helps, and where the evidence can break

An agent can be useful at several points: navigating unfamiliar code, proposing names for anonymous functions, explaining data transformations, drafting a replacement routine, creating test inputs, and recording unresolved questions. The benefit is potentially cumulative. Saving time on a hundred small transitions may matter more than producing one dramatic decompilation screenshot.

That advantage depends on correction. A model can confidently infer a familiar algorithm from a partial pattern and overlook a product-specific exception. It can treat an error-handling branch as dead code because the available sample never reaches it. It can write tests that restate its own implementation instead of challenging it. A long chain of polished explanations can compound an early mistake.

Research provides a better vocabulary than “it understands the binary.” The LLM4Decompile paper evaluates reconstruction of C functions and distinguishes producing code that compiles from code that passes behavioral assertions. Its reported setup includes GCC-compiled functions on x86 Linux and function-level benchmarks. That is meaningful evidence within its experimental domain, not a direct test of rebuilding a creative suite. LLM4Decompile methods.

Decompile-Bench likewise separates functional recovery, readability, and text similarity. Its authors describe the difficulty of constructing executable evaluations from real projects without training-data leakage, and acknowledge limitations in moving to project-level decompilation. A readable answer and a similar-looking answer are useful measures, but neither establishes complete operational equivalence. Decompile-Bench methods and limitations.

For readers, the useful question is what the experiment withheld. If a model can see the original implementation, its own generated tests, and all expected outputs, a good result may demonstrate assisted translation or reproduction. A stronger generalization test includes unfamiliar inputs, independent expected results, and conditions that expose incorrect assumptions.

For a simple numeric function, that might include zero, negative values, overflow boundaries, and unusual precision. For a creative application, the corresponding cases include malformed documents, missing fonts, large histories, interrupted writes, and projects assembled across several application versions. The breadth of those conditions makes application parity a different problem from reconstructing an isolated function.

Speed also needs a denominator. Minutes of agent execution exclude preparation, licensing, test-data creation, review, failed runs, and later repair unless those costs are deliberately recorded. Claims that a product was recreated “in one prompt” should come with the exact starting state and the full sequence of work. We have not independently established those costs or development conditions for ArtCraft.

ArtCraft’s seven applications, with the claims kept in scope

ArtCraft’s public lineup maps seven applications to familiar Adobe categories. The repository release listings checked on October 10 showed the versions below. The underlying release timestamps fall on October 9 in Pacific time. The listing confirms that release records and assets exist; this reporting did not download, launch, or inspect those binaries. Documentation is pinned separately to repository revisions and should not be assumed to describe the exact contents of every release asset.

The code manifests reviewed for all seven declare MIT-or-Apache-2.0 licensing. That supports describing the projects as open source. It does not settle the provenance of every contribution, the rights attached to third-party assets, or whether every distributed binary corresponds to the reviewed source. Release metadata and source licenses answer specific questions; they are not independent maturity or legal certifications. ArtCraft directory and repository links.

PhotoCraft: the menu is the beginning of the test

Documented; current behavior untested here. PhotoCraft describes layers, masks, adjustments, smart-object workflows, and Photoshop-oriented document support. Its README also calls it early alpha and explicitly says it is not yet a replacement for daily professional Photoshop work. It identifies gaps in generative features, tools, typography, professional workflows, and plug-in compatibility. Pinned PhotoCraft README.

Its parity document reports 627 of 627 menu items live. That count measures command wiring. The roadmap’s October 5 assessment estimated professional daily-work readiness at roughly 25–35%, while directing readers to newer scorecard evidence where the documents disagree. The historical percentage is the project’s estimate, not our measurement or a current universal score. Pinned menu report and dated roadmap.

A meaningful evaluation would start with layered files that exercise several features together. Does a clipping mask still work after a transform? Does text remain editable? Do blend modes preserve the intended result across bit depths? Can the document return to its original application without silently flattening important structure?

The proposed test should distinguish opening a preview, rendering the full document, preserving its editable structure, and saving a compatible result. These are separate outcomes. A thumbnail that looks correct can conceal a document that can no longer support the next requested revision.

VectorCraft: compatibility has to preserve the drawing

Documented; fidelity untested here. VectorCraft describes vector editing and SVG/PDF workflows, including PDF-compatible Illustrator files. Its documentation distinguishes that path from universal support for every Illustrator document. It also describes limitations and fallbacks in Affinity import, rather than promising unrestricted bidirectional compatibility. Pinned VectorCraft README.

An effective test would inspect editable paths, compound shapes, gradients, clipping, text layout, and export behavior. A logo can appear correct at one size while containing a malformed path that becomes visible in a cutter or another renderer. Converting text to outlines may preserve appearance while losing the editing workflow the customer needs.

The application should also make unsupported content visible. A clear warning that an effect has been flattened is useful information. Quiet substitution creates a harder problem because the user may discover the loss only after forwarding the file. For a replacement editor, honest import diagnostics are part of compatibility.

FilmCraft: video support is a matrix

Documented; performance and export quality untested here. FilmCraft describes a timeline editor with its own Rust codec implementations. Its README says FFmpeg serves as an external test oracle. That documentation does not support casually describing the project as an FFmpeg wrapper; resolving its implementation would require a code audit. The README also identifies missing third-party plug-in hosting, including VST3, Audio Units, and OpenFX. Pinned FilmCraft README.

A video evaluation needs to separate the container, codec, profile, bit depth, frame rate, audio layout, and hardware path. “MP4 works” is too broad. An application might handle one camera’s footage but fail on variable-frame-rate phone recordings or a different encoding profile.

The proposed acceptance project would combine several source types, perform cuts and transitions, relink moved media, generate proxies, and export a long sequence. Reviewers should inspect audio synchronization, color interpretation, dropped frames, and the final file in an independent player. Smooth playback of a short demonstration gives little evidence about a two-hour export under memory pressure.

LightCraft: a recognizable image can conceal a fallback

Documented; RAW quality and catalog migration untested here. LightCraft describes nondestructive photo development and catalog workflows. Its README discloses camera-support limits, including embedded-JPEG fallback for some RAW variants, and says some AI-labeled processing uses classical heuristics. Camera calibration and other professional-workflow areas also remain qualified in its documentation. Pinned LightCraft README.

The distinction between decoding a RAW sensor file and showing its embedded preview is central. A preview can look excellent while offering different latitude for exposure recovery, white-balance changes, and detail extraction. A test needs the actual camera model and compression variant, alongside a clear indication of which path the application used.

A migration exercise should also preserve ratings, keywords, capture times, lens corrections, edit history where supported, and links to originals. The catalog is part of a photographer’s work. An attractive rendering of one image cannot establish that a multi-year library survives the move.

PdfCraft: visual correctness is only one layer

Documented; document security and conformance untested here. PdfCraft advertises native PDF handling, organization, forms, and security-related operations. It describes incremental saving that preserves original bytes where appropriate. Those statements require separate evaluation for ordinary editing, signed documents, and operations intended to remove information. Pinned PdfCraft README.

Redaction is the clearest example. A black rectangle over a name is not evidence that the underlying content has been removed. A proposed security test would inspect the resulting document’s text, objects, attachments, metadata, and earlier revisions where retained, using independent tools. It would also check that ordinary editing does not imply preservation of a digital signature’s validity.

Accessibility is another independent requirement. Reading order, tags, form labels, and keyboard operation matter even when pages look identical. Any claim that PdfCraft can replace a particular Acrobat workflow must identify which of these properties was actually checked.

EffectCraft: expressions and timing carry the workload

Documented; project and plug-in parity untested here. EffectCraft describes compositions, layers, animation controls, expressions, and 3D features. Its documentation includes a native JSON project format, Lottie interchange, and command interfaces. Those are relevant foundations for automation, but they do not establish universal After Effects project compatibility. Pinned EffectCraft README.

A practical evaluation would combine animated text, nested compositions, parenting, expressions, motion blur, and external media. Timing and interpolation need frame-level inspection. A composition can look right in a still image while differing throughout its motion.

Studios also build workflows around templates and plug-ins. Recreating a visible effect with different controls may be sufficient for a new project, but an existing template may depend on precise expression semantics or an unavailable extension. Those users face a migration question that a feature checklist cannot answer.

DesignCraft: the final pages must survive production

Documented; typography and prepress output untested here. DesignCraft describes threaded text, paragraph composition, IDML import/export, EPUB output, and PDF/X-4 and PDF/A-2b workflows. These are stated capabilities. IDML interchange should not be described as blanket support for every native InDesign file or feature. Pinned DesignCraft README.

The proposed test is a document with enough complexity to expose interaction effects: linked images, styles, tables, footnotes, multiple languages, and text flowing across pages. Reviewers would check overset text, line breaks, font substitution, and whether edits cause unexpected reflow.

Export validation belongs outside the originating application too. A claimed PDF standard should be checked with an independent validator and the actual recipient’s requirements. Print production introduces bleed, output intent, transparency, and finishing constraints. A page that looks persuasive on a laptop has only passed the first part of that workflow.

Why “percentage complete” needs a definition

A percentage seems to simplify comparison, but the denominator can change the story entirely. Counting menus gives every menu entry a vote. Counting supported formats treats a simple import and a demanding professional format as comparable units. Counting passing test cases depends on how those cases were selected. None automatically measures the probability that a particular person can finish a job.

A more useful assessment separates at least six dimensions:

These dimensions are not interchangeable. Excellent rendering can coexist with poor editing support. A fast filter does not compensate for unreliable saving. A mature application can fail one specialized workflow while serving another extremely well.

That also means partial replacements can have real value. Someone producing flattened images for a personal website may need a much smaller feature set than an agency exchanging complex editable documents. An experimental tool can be useful before it becomes a professional substitute. The appropriate claim is tied to the task it completes.

File formats make this especially clear. Adobe publishes a PSD specification that gives implementers a legitimate technical reference. Public documentation can lower the barrier to compatibility. It does not guarantee a complete implementation, nor does it supply every behavior of the originating application. Adobe’s Photoshop file-format specification.

Round-trip testing is therefore valuable. Open a controlled document, make a defined edit, save it, reopen it in the original application, and compare both visual output and editable structure. Record warnings and substitutions. Preserve the original file so failures remain reversible. That exercise tests a relationship between programs, rather than the attractiveness of one program’s interface.

Performance deserves similar precision. Report the document size, hardware, operating system, application version, cache state, and operation. Include memory consumption and failure rate alongside elapsed time. “Faster” without those conditions is difficult to interpret, particularly if one implementation performs a cheaper approximation or silently skips unsupported content.

The maintenance test takes longer. A user needs to know whether an update can reopen last month’s projects, whether an old version remains available, and whether a reported regression can be reproduced. Rapid release frequency is encouraging only when the project can control what each release changes.

Free software still has a cost of adoption

Subscription frustration helps explain the enthusiasm. At the source check, Adobe’s US pricing page advertised Creative Cloud Pro at a regular US$69.99 per month on an annual plan billed monthly. A displayed new-subscriber promotion reduced the first three months to US$34.99 each, then returned to the regular price. Offers, eligibility, region, and tax treatment can change; this is a dated advertised-price observation, not a checkout quote. Adobe pricing.

The annual commitment is material. Adobe’s published US terms describe an early-cancellation charge of 50% of the remaining contract obligation for an annual plan paid monthly when cancellation occurs after the initial 14-day period. Readers need the terms attached to their own purchase, rather than an assumption that a monthly bill means a month-to-month contract. Adobe subscription terms.

There is also a documented regulatory backdrop. In March, the US Department of Justice announced a proposed settlement concerning subscription practices, describing US$75 million in civil penalties and US$75 million in free services. Calling that a US$150 million cash fine would be inaccurate, and the announcement alone should not be used to establish when a court entered an order. It concerns subscription conduct, not ArtCraft’s legality. DOJ announcement.

Eliminating a recurring software fee can be valuable even when the savings are modest. For a student, hobbyist, small nonprofit, or occasional user, a subscription can determine whether a tool is available at all. Source access can also matter independently of price: it creates the possibility of studying, modifying, and maintaining software beyond the original developer’s priorities.

Adoption costs remain. They include learning a different workflow, replacing plug-ins, rebuilding templates, converting archives, training colleagues, checking outputs, and retaining an old application for exceptions. A team that saves on licenses but spends more time repairing documents has changed the form of its expense.

A hypothetical calculation makes the trade-off clearer. If a freelancer values an hour of working time at US$50, two additional hours of repair in a month represent US$100 of opportunity cost. That example is not a measured ArtCraft burden, a recommended rate, or a prediction. It shows why the fee alone cannot decide a production migration. For someone learning on personal projects, the same hours may be worthwhile practice rather than lost income.

REA has a different cost model. A free toolkit can still sit between a paid analysis provider and a metered model. Long investigations may consume substantial agent context and repeated inference. Before quoting the cost of reconstruction, distinguish software licenses, model usage, hardware, human review, and failed attempts. No paid model experiment was run for this article, and it contains no independently measured ArtCraft development budget.

The alternatives already exist, and they deserve a fair comparison

ArtCraft enters a field that already includes substantial free and open-source work. GIMP covers image manipulation, Krita focuses on painting, Inkscape provides vector editing, and darktable addresses photography and RAW workflows. Their existence matters because “Adobe or an AI-generated clone” is an unnecessarily narrow choice. GIMP, Krita, Inkscape, and darktable.

Video users also have projects such as Kdenlive and Shotcut. Blender provides a broader open-source creation environment. These tools have different interfaces and priorities, so listing them together does not imply they are interchangeable or that each replaces every Adobe workflow. Kdenlive, Shotcut, and Blender.

Other alternatives have different licensing and business models. Photopea provides browser-based image editing; DaVinci Resolve has free and paid offerings. “Free to use,” “open source,” “runs locally,” and “available without a subscription” describe different properties. A useful comparison should say which property matters to the user. Photopea documentation and DaVinci Resolve.

This article has not performed a comparative benchmark of those applications. They belong in an evaluation set, not in an untested ranking. A user who needs a reliable alternative today should compare the same real task across the incumbent, an established alternative, and the new entrant.

The existence of mature alternatives also changes the engineering question. If agents can produce substantial new implementations, can they help existing projects address compatibility gaps, accessibility issues, or difficult bug reports? A new repository can explore a different architecture. A contribution to an established project can build on years of accumulated fixes and user knowledge. Both routes deserve attention; the AI label alone tells us little about which produces more lasting value.

Clean-room claims and the legal questions they leave open

“Clean room” is a claim about development process. ArtCraft’s contributor instructions set boundaries against inspecting or disassembling Adobe application bundles and point contributors toward public specifications and permitted behavioral references. Those rules are relevant evidence of intended practice. A rules file does not establish that every prompt, contribution, dependency, or generated output followed it. PhotoCraft contributor instructions and EffectCraft contributor instructions.

For an AI-assisted project, a stronger provenance account would explain the sources given to the model, how contributors were instructed, what review occurred, and how suspiciously similar output was handled. It would distinguish independently prepared functional descriptions from copied implementation material. It would also retain enough development history to investigate a disputed component.

Even a careful process does not answer every rights question. Software disputes can involve copyright, contractual restrictions, access controls, patents, confidential information, branding, or separately licensed assets. Which issues apply depends on the facts and jurisdiction. There is no single legal status attached to the phrase “reverse engineering.”

The following is a map of the relevant boundaries, not a legal clearance of ArtCraft or a direction to bypass a particular product’s protections.

United States: copyright and access controls are separate questions

In Google v. Oracle, the US Supreme Court held that Google’s challenged copying of Java API declaring code was fair use in the circumstances before it. The Court assumed copyrightability for purposes of deciding the case. The decision should not be shortened to “all APIs are uncopyrightable” or “copying commercial software is legal.” Its reasoning and factual context matter. Supreme Court opinion.

Anti-circumvention law introduces a separate analysis. Section 1201 of the Copyright Act contains a conditional interoperability provision for someone lawfully entitled to use a program. It addresses obtaining information necessary for interoperability of an independently created program and imposes limits on use and disclosure. That is substantially narrower than a general license to remove subscription checks or distribute circumvention tools for any purpose. Official 2024 statutory edition, 17 USC 1201.

The Copyright Office’s exemption process also concerns specified classes and conditions. A preservation or research exemption cannot be assumed to apply to an unrelated commercial replacement. Exemptions from particular circumvention prohibitions do not automatically resolve every copyright or distribution question. Copyright Office’s 2024 Section 1201 proceeding.

European Union: functionality, expression, and interoperability

The EU Software Directive distinguishes protected program expression from underlying ideas and principles. It provides conditions for observing, studying, or testing a program and a separate, limited route for decompilation necessary for interoperability. It also restricts what can be done with information obtained through that route. National implementation and the actual conduct remain important. Directive 2009/24/EC.

The Court of Justice’s explanation of SAS Institute v. World Programming is especially relevant to claims about reproducing behavior. It distinguishes program functionality, programming languages, and certain data-file formats from protected program expression. It also addresses lawful observation and the separate possibility of infringement through copying expressive material from manuals. That distinction supports careful analysis of what was reproduced and how, rather than treating similar functionality as the complete legal question. CJEU explanation of the judgment.

United Kingdom: lawful observation has its own provision

Section 50BA of the UK Copyright, Designs and Patents Act permits a lawful user to observe, study, or test a program’s functioning while performing acts the user is entitled to perform. Section 50B addresses decompilation under specified interoperability conditions, including necessity and limits on using or sharing the resulting information. These provisions also address contractual terms that purport to prohibit qualifying acts. Neither supplies a blanket conclusion about an entire clone project. Section 50BA and Section 50B.

Canada: the amended interoperability language matters

Canada’s Copyright Act has both a reproduction exception for program interoperability and a separate technological-protection-measure provision. Section 30.61 specifies conditions concerning lawful copies, purpose, and use or disclosure of information. Section 41.12, amended in 2024, extends relevant language to interoperability involving programs, devices, and components, while retaining limitations and exclusions. The consolidated text reviewed was current to September 21, 2026. These provisions need to be applied to the actual activity, rather than cited as universal permission. Section 30.61 and Section 41.12.

Adobe’s terms are relevant, but they are not the whole law

The Adobe terms page reviewed contains a broad Section 17 restriction covering reverse engineering, including some monitoring of inputs and outputs to recreate a system, and certain AI-related uses. It also describes a process for requesting interoperability information where local law grants decompilation rights. Applicable terms can differ by region and product; their effect also depends on statutory rights and enforceability. Adobe General Terms of Use.

That leaves an important reporting boundary. The reviewed materials establish the projects’ public positions and relevant legal frameworks. They do not establish a judicial finding that ArtCraft is lawful or unlawful. We did not locate a verified Adobe notice or court filing specifically targeting ArtCraft in the sources reviewed. This was not an exhaustive docket search. A removed Reddit post is not evidence of a legal takedown, and Adobe’s statement about the subscription settlement is not a statement about these applications.

AI authorship introduces a separate ownership question

The US Copyright Office’s January 2025 report distinguishes human authorship assisted by AI from purely AI-generated expression. It treats the sufficiency of human contributions as a case-specific question and explains that, for the technology it examined, prompts alone generally did not supply sufficient expressive control. That framework does not establish how much of ArtCraft’s code is protectable; the necessary development evidence has not been examined here. Copyright Office report on AI and copyrightability.

Ownership and infringement remain separate questions. A claim about the copyright status of newly generated material does not establish permission to reproduce somebody else’s protected material. Likewise, attaching an open-source license communicates a licensing position without independently resolving provenance. Model-training questions, generated-code review, human contributions, and dependency licenses each require their own evidence. Calling a project AI-generated cannot settle all four at once.

Open source, Rust, and local execution answer different trust questions

The availability of source code is valuable because it makes independent examination possible. Whether meaningful examination has happened is a separate question. A rapidly changing repository can expose its code while still containing incorrect algorithms, fragile parsers, insecure update behavior, or incomplete tests.

Rust can reduce important categories of memory-management mistakes when its safety guarantees apply. It does not prove that an image was decoded correctly, that an access decision was sound, or that a document can be saved without losing data. Unsafe code, dependencies, foreign interfaces, and application logic still need review. Language choice is one engineering decision, not a substitute for evaluating a product.

A security assessment would ask how releases are built, how users identify the publisher, whether signatures and checksums are available and independently checked, how dependencies are updated, and how vulnerabilities are reported. We have inspected release listings, not verified the signatures, reproducibility, or security of the associated binaries.

A maintenance assessment asks different questions: who can review contributions, who controls release credentials, what happens if the primary developer leaves, and whether the project has a credible process for regressions. An open license allows a fork under its terms, but taking responsibility for that fork still requires people with time and expertise.

Privacy needs the same separation. REA says its analysis runs locally, but also explains that tool results reach the agent and that the agent provider’s policy governs their handling. “Local analysis” therefore does not establish that all extracted code, strings, document content, or traces stay on the machine. The complete path depends on the chosen agent and configuration. REA’s privacy explanation.

For a confidential target, the practical review should trace what is read, what appears in tool output, where model inference occurs, what gets logged, and who can access retained artifacts. A locally running model can change that exposure, but it still needs a verified configuration. Merely choosing a tool described as local is insufficient evidence.

Agents introduce another trust boundary: analyzed material can contain text that looks like instructions. Comments, strings, documentation, or application content might try to redirect an assistant. An analysis workflow should treat the target as evidence rather than authority. Giving a model access to a file is different from authorizing whatever instructions that file contains.

Dynamic investigation also involves executing software. A controlled environment, copies of test files, and limited permissions help keep an experiment from affecting unrelated work. These are practical research controls, not accusations about ArtCraft or REA. This reporting did not execute either project’s release binaries or examine their runtime network behavior.

What the Reddit argument reveals

The discussion is easier to understand when the participants’ interests are separated. Someone who wants a free editor may care most about access. A professional may care about preserving an archive and meeting a deadline. An open-source maintainer may care about review burden and contribution quality. A developer may be reacting to how quickly familiar product surfaces can now be attempted.

The sampled Reddit threads reflect those different concerns. The REA discussion includes enthusiasm for agent-assisted analysis and uncertainty about what the toolkit actually does. The graphic-design discussion raises questions about creative labor, originality, and dependence on existing products. The game-development discussion extends the debate to mechanics, code, assets, and rights. These threads illustrate arguments; they are not a representative survey or evidence of a measured adoption trend. REA discussion, graphic-design discussion, and game-development discussion.

There is also a recurring mismatch between the claim being defended and the claim being challenged. One participant sees impressive early progress. Another hears that a professional suite has already been replaced. Both may be responding rationally to different propositions. The solution is to state the proposition precisely and attach evidence at that level.

User reports can help identify what to test next. A report of a crash should lead to a build number, operating system, reproducible file, and operation sequence. A report that a tool feels fast should lead to timing under comparable conditions. A screenshot or anecdote has value as a lead; repeating it as a general product verdict discards the context that could make it useful.

The ethical questions extend beyond whether an implementation is legally permitted. A project can ask whether it credits the prior work that informed its design, whether it respects contributors’ licenses, and whether its claims accurately describe what users receive. It can also ask whether reproducing an established interface serves accessibility and familiarity or simply avoids thinking about a better workflow.

Critics have responsibilities too. Labeling unfamiliar software worthless because AI was involved is not an evaluation. Neither is calling it theft without identifying the material, conduct, and legal theory at issue. The appropriate standard applies in both directions: inspect the evidence, identify the limits, and keep a prediction separate from a finding.

What this could change about software businesses and jobs

The economic implications are significant even if none of these applications becomes a complete Adobe replacement. A credible substitute for a narrow task can reduce the amount of software someone needs to buy. Several substitutes can collectively change a purchasing decision. Competition does not require one product to duplicate an entire incumbent suite.

The following are scenarios, not established forecasts. If agents reduce the effort needed to implement familiar features, small teams may enter markets that previously required too much initial engineering. Buyers may see more specialized tools, more local workflows, and more opportunities to commission software around a specific task. Some features that once differentiated a product may become easier to reproduce.

That does not make every part of a software business equally vulnerable. A visible interface exposes information about itself. A hosted service may depend on infrastructure, proprietary data, operational procedures, and contractual relationships that are absent from the client. Reconstructing an application’s requests does not supply its server-side assets or permission to access them. A clone’s economics depend on what must continue running after the code is written.

For a creative-software incumbent, durable value may come from dependable output, integrations, support, training, collaboration, and the accumulated trust of customers who exchange files. Those advantages can be challenged, but they require different evidence from a recreated menu. A useful competitor may win by making a smaller workflow simpler and more dependable rather than matching every feature.

The labor consequences are also uneven. Faster implementation could reduce demand for some repetitive coding tasks. It could increase the number of attempted products and create more work in evaluation, integration, maintenance, and security. Neither direction establishes the net effect on employment. This article has no labor-market dataset that would justify a numerical jobs forecast.

The skills needed to judge a creative tool remain substantial. Someone must notice a color-management error, a broken type layout, or a subtly incorrect audio export. Someone must decide which user reports indicate a common defect and which reflect an unsupported workflow. Automating code production can make those judgments more consequential because more software arrives for assessment.

Open source introduces another economic question: who pays for the continuing work? A developer can subsidize a project, sell related services, solicit donations, or build a business around support. The launch can be funded one way and long-term maintenance another. Public code availability does not settle whether enough resources will remain for difficult compatibility bugs three years later.

There is a possible reciprocal effect as well. The same tools that help outsiders reproduce features can help incumbents inspect legacy systems, modernize components, and improve internal testing. It is too early to assign the entire productivity gain to challengers. The outcome depends on how different organizations use the tools and what their customers continue to value.

Beyond Adobe: preservation and interoperability may matter more

Creative applications attract attention because their interfaces are familiar and their subscription prices are visible. Reverse engineering has broader uses. An organization may need to recover access to old documents, replace a discontinued component, understand a proprietary protocol, or maintain a device whose original software no longer works.

In those situations, the valuable deliverable can be small. A converter that preserves a document archive may be more useful than a replica of the original application. A compatible library can let existing software survive an operating-system change. A well-supported explanation of an undocumented file field can unblock years of stored data.

These are potential applications of the techniques, not demonstrated achievements of the current REA or ArtCraft releases. They also require their own rights and reliability analysis. Access to an abandoned product does not automatically grant rights to distribute its code, artwork, music, trademarks, or other assets.

Games make that separation especially visible. Reimplementing a rule or engine component is a different task from distributing the original game’s expressive content. Preserving behavior can also require timing, input handling, saved-game compatibility, and network assumptions that a visual imitation does not capture. Kingy’s related game-decompilation article explores that subject separately.

Engineering and business applications raise still different acceptance standards. A drawing viewer, a CAD geometry kernel, and software that controls physical equipment require different kinds of validation. A small numerical discrepancy might be harmless in a thumbnail and unacceptable in a manufacturing workflow. The apparent similarity of the interface says little about the consequences of an error.

This is why the most useful long-term question is whether agents can make careful interoperability work more affordable. That would benefit users even without a dramatic claim that an entire category of software has ended.

What a convincing independent evaluation would publish

The next evidence should be reproducible enough for another person to challenge it. For ArtCraft, that means named releases, known files, defined tasks, independent output checks, and a record of failures. For REA, it means a specified investigation and an explanation of which conclusions were supported, corrected, or left unresolved.

The following is a proposed protocol. None of these experiments was performed for this article.

1. Fix the question before the run. Choose a bounded task such as preserving a layered document through one editing round trip. Define success and failure in advance. Avoid choosing the winning demonstration after seeing the results.
2. Record the starting state. Preserve the source revision, release identity, operating system, hardware, dependencies, and target file hashes. If an agent is involved, record its model, configuration, prompts, tool versions, and permitted access.
3. Use inputs that expose interactions. Include ordinary files, edge cases, and realistic combinations of features. Explain how the corpus was selected and which important cases it excludes. Keep confidential customer material out of a public test package.
4. Separate visual and structural checks. Compare rendered output, editable content, metadata, warnings, and round-trip behavior. For security-sensitive functions, use an independent verification method suited to the property being claimed.
5. Count failures and interventions. Report crashes, hangs, retries, manual repairs, unsupported features, and abandoned runs. Include time spent preparing and correcting the result, not only the fastest successful execution.
6. Publish the limits with the result. A passing corpus supports the tested scope. It should not be relabeled as universal parity. Make it possible to add a failing case and revise the conclusion.

A useful first application comparison could use three task tiers. The first would cover basic operations on controlled files. The second would use realistic multi-step projects. The third would examine migration and recovery: reopening old work, round-tripping edits, interrupting operations safely, and handling a known unsupported feature. Results should remain separate so strength in the first tier does not conceal weakness in the third.

An agent experiment needs an additional control. Give a conventional tool-assisted workflow and an AI-assisted workflow the same authorized target and task. Record the analyst’s experience, time, corrections, and final accuracy. A single success can demonstrate possibility; it cannot measure the average productivity gain or the conditions under which the agent makes work slower.

There is also a useful test of uncertainty. Include a question the available evidence cannot resolve. Does the agent state the limit, propose the missing observation, and stop short of inventing a conclusion? A reverse-engineering assistant that knows when it lacks evidence is more useful than one that always supplies an answer.

The claim that will matter after the launch

REA makes a concrete proposal: let an agent work with software-analysis tools and carry evidence through an investigation. ArtCraft makes another: build openly available creative applications that attempt familiar professional tasks. Their documentation and public releases make both proposals worth serious examination.

The available evidence does not establish that Adobe’s source has been recovered, that REA built ArtCraft, or that seven new applications already replace seven mature workflows. It also does not justify dismissing the projects because their current limitations are substantial. Early software can be incomplete and still reveal a useful direction.

The next milestone should be specific enough to verify: this release completed this task, preserved these properties, and failed in these documented circumstances. Repeat that result across enough real work, with dependable maintenance, and the market implications become much stronger.

For now, the important shift is that more people can attempt ambitious software reconstruction and reimplementation. Whether those attempts become trusted products will be decided by the files they preserve, the work they complete, and the failures their maintainers can fix.

Right now

Trending on Kingy

Keep reading with the stories getting the most attention now.

1. 01 Blog · Oct 3

   AI Video Game Decompilation: What Works, What’s Possible, and What’s Legal

   Read story →
2. 02 Blog · Oct 8

   Reverse Engineer Anything with AI: REA Tested on a Notes Exporter

   Read story →
3. 03 Blog · Oct 6

   OpenAI’s 722 Math Manuscripts: The Results, Proofs, Compute and Costs

   Read story →

The Kingy Brief

Get The Kingy Brief.

AI changes, original tests and one practical thing to try. Fridays at 09:00 Vancouver time.

Free · Double opt-in · Unsubscribe anytime

Privacy policy

Signup help and newsletter schedule

Signup form provided by Beehiiv. After submitting, check your inbox for "Confirm your subscription to The Kingy Brief" and open its confirmation link. Check Spam or Promotions if you cannot find it.

Fridays at 09:00 Vancouver time: source-checked AI changes, original tests and one practical thing to try. The weekly restart begins October 9, 2026. We skip a week when there is not enough verified material. Free. Unsubscribe anytime.

Open signup on Beehiiv →