AI Cloned Adobe's Software. What Does That Mean for the Future of Software Development?

Brandon Thomas, an experienced software engineer and former Square developer, used Anthropic’s Claude Opus 5.5 to create open source alternatives to seven Adobe applications, including Photoshop, Illustrator, Premiere Pro, and Lightroom. The applications were written in Rust and released publicly under the ArtCraft project.

Thomas described the effort as a way to challenge established software companies, declaring, “Software is over."

The statement made headlines. So did the speed at which the applications appeared.

The software isn’t ready to replace Adobe’s products. Even its creator has acknowledged that the applications are in early alpha. But the fact that a relatively small development effort could produce recognizable, partially functional alternatives to several complex commercial applications in such a short period has sparked a much larger conversation.

For years, the complexity and cost of building sophisticated applications helped protect established software companies from new competitors. Replicating years of development required significant funding, specialized engineering teams, and enormous amounts of time.

AI may be changing that equation.

For engineering leaders, the most important question isn’t whether Adobe should be worried. It’s what happens when the cost of building a competing product starts to fall, but the expectations for reliability, security, and long term maintenance remain just as high.

Impressive, But Not Ready to Replace Adobe

Before considering the implications, it’s worth understanding what Thomas actually built.

The ArtCraft project includes seven applications intended to recreate familiar Adobe functionality. PhotoCraft targets Photoshop, VectorCraft takes on Illustrator, FilmCraft resembles Premiere Pro, and the remaining applications address photo management, motion graphics, page layout, and PDF editing.

Thomas says he used Claude Opus 5.5 to accelerate development, relying on a clean room approach that studies publicly observable application behavior and available specifications rather than directly copying Adobe’s source code.

The resulting applications are open source, with code available for developers to inspect, modify, and contribute to. That’s an ambitious undertaking, particularly for software as mature and complex as Adobe’s creative applications.

But there’s an important distinction between recreating recognizable functionality and achieving the reliability of the original product.

In an independent hands-on review published by Creative Bloq, the reviewer tested several ArtCraft applications and found that basic editing capabilities were functional, but significant limitations remained. These included problems with color profiles, masking precision, high resolution video editing, and compatibility with existing project files.

FilmCraft, for example, could perform basic video editing operations but couldn’t open or save Adobe Premiere Pro project files. Other applications encountered problems with workflows that professional users depend on.

These findings don’t invalidate the project. They help establish what has actually been demonstrated.

Thomas has also acknowledged the early state of the software. His initial prediction of reaching complete feature parity within a month was subsequently revised to a more cautious expectation measured in months rather than years. Whether that timeline proves realistic remains to be seen.

The applications demonstrate how quickly AI assisted development can produce substantial functionality. They do not yet demonstrate that a small team can reproduce decades of production maturity in the same timeframe.

And that distinction leads to the more interesting part of the story.

The Real Disruption May Be the Cost of Building Software

Adobe isn’t the first company to face open source competition. GIMP, Krita, Inkscape, and other applications have offered alternatives to commercial creative software for years. Some have developed into mature tools with dedicated communities and established workflows.

The difference with ArtCraft isn’t that someone thought to build another photo editor. It’s the possibility that AI has significantly reduced the effort required to create an initial version of one.

Historically, replicating a mature commercial application meant building much of its functionality through conventional development. Engineers needed to research expected behavior, design components, implement features, integrate dependencies, write tests, and resolve countless compatibility issues. That work required substantial time and expertise before a new competitor could offer even a reasonably functional alternative.

AI coding agents are beginning to change how some of that work gets done.

An engineer can now use agents to explore implementations, generate code, write tests, and work across multiple parts of a codebase. Tasks that previously required extensive manual implementation can sometimes be completed much faster.

ArtCraft offers a visible example of what that acceleration might enable.

It doesn’t establish how much money was saved or how many engineering hours would have been required without AI. Those comparisons would require reliable development cost and productivity data that hasn’t been made public.

But it does raise a question that software companies should take seriously:

What happens when the cost of attempting to recreate a product falls enough that projects previously considered financially unrealistic become worth pursuing?

For smaller development teams, that could mean experimenting with more ambitious products without securing the funding traditionally required to get started.

For established software companies, it could mean facing competitors who can reproduce portions of their functionality with fewer resources.

For engineering leaders, it creates new decisions about where development effort should be invested and what actually makes their products difficult to replace.

None of this means sophisticated software suddenly becomes inexpensive to build and operate in its entirety. It means the economics of getting started may be changing, and that alone could have significant consequences.

Building the First Version Is Getting Cheaper. What About Everything After?

Getting a photo editor to open a PSD file is an achievement. Getting it to handle thousands of real world files, preserve compatibility across versions, recover gracefully from failures, and perform consistently across different hardware configurations is an entirely different challenge.

Consider what happens when an application moves beyond its initial demonstration.

A developer might successfully implement image rendering, layer manipulation, and basic editing tools. But how does the application behave when someone opens a corrupted 4 GB project file? What happens when GPU memory runs out during rendering? Can a user recover hours of work after an unexpected crash? Will the same file produce consistent results across different operating systems?

These aren’t obscure scenarios that only matter to a handful of users. They’re the kinds of problems that determine whether professionals can trust an application with their work. And the challenge extends beyond handling unusual inputs.

A mature application needs predictable performance, consistent file compatibility, reliable security updates, and an architecture that can accommodate new functionality without destabilizing existing features. For a product like Photoshop, that means supporting workflows built around years of accumulated files, plugins, integrations, and user expectations. Recreating an interface doesn’t automatically recreate that ecosystem.

AI can help engineers implement and test these behaviors. It may even make some of that work significantly faster. But generating an implementation is only part of the challenge. Someone still needs to define what correct behavior looks like, understand the underlying system, validate the results, and maintain those guarantees as the software evolves.

This is where the economics becomes more interesting.

If the cost of generating a first version continues to fall, organizations may find themselves spending a larger share of their engineering effort on verification, integration, compatibility, and long term ownership.

That doesn’t necessarily mean those activities will consume more time in absolute terms. AI may accelerate them too. But their importance to the finished product doesn’t disappear simply because implementation becomes faster.

The work changes. So does the way teams need to approach it.

If Features Become Easier to Replicate, Where Does Competitive Advantage Move?

For a long time, software complexity has provided a degree of protection for established companies. Building a competing application could require years of engineering work before a new entrant had anything substantial to offer customers. That development cost acted as a barrier to competition.

If AI reduces the cost of replicating certain features, some of that protection may weaken.

But a feature list has never been the only reason customers choose one product over another. Consider why a professional design agency might continue using Adobe even if a free alternative offers many of the same editing tools.

The agency may have years of project files that need to remain compatible. Its employees already understand the software. Clients expect deliverables in specific formats. Internal processes depend on established integrations. Technical support and predictable updates are part of the purchasing decision.

Replacing the software means replacing or adapting parts of that workflow. Those switching costs aren’t necessarily permanent advantages, but they are real considerations that a competing product must address.

The same principle applies well beyond creative software.

A financial platform isn’t valuable only because it can process transactions. Its value also depends on accuracy, security, regulatory requirements, integrations, and the confidence organizations have in its operations.

An enterprise logistics system isn’t differentiated solely by its scheduling features. It also needs to coordinate with existing infrastructure, handle unpredictable demand, and maintain reliable operations across complicated environments.

In both cases, the software’s value extends beyond what appears in the interface. That distinction matters as AI makes implementation more accessible.

Companies may find it increasingly difficult to defend their position through functionality alone.

Instead, competitive advantage may depend more heavily on the systems, relationships, data, workflows, and operational capabilities surrounding those features.

For CTOs and product leaders, this creates an opportunity to examine where their organization’s value actually comes from:

• Which parts of the product would be relatively straightforward for a competitor to reproduce?
• Which capabilities depend on specialized knowledge, difficult integrations, or years of operational refinement?
• What would make customers continue choosing the product even if another company offered similar features at a lower price?

These are strategic questions, but they have direct implications for engineering priorities. The answer may influence where teams invest in architecture, infrastructure, integrations, developer experience, and product development. And perhaps more importantly, it can help organizations identify which investments create lasting customer value rather than simply adding another feature to a growing list.

Customer Frustration Can Become an Opportunity for Competitors

There’s another detail in the ArtCraft story worth examining. Thomas has said that frustration with Adobe’s subscription and cancellation practices helped motivate the project.

That frustration has a documented backdrop. In 2024, the US government sued Adobe over allegations involving subscription disclosures and cancellation procedures. In March 2026, Adobe agreed to a settlement involving $75 million in civil penalties and $75 million in services for eligible customers, while denying wrongdoing.

The dispute doesn’t explain the technical achievement behind ArtCraft, but it helps explain why the project attracted attention. People are more likely to explore alternatives when they’re dissatisfied with the products or companies they currently depend on.

For years, however, dissatisfaction alone hasn’t been enough to make replacing complex software practical. Users may dislike pricing, licensing terms, or particular product decisions while continuing to rely on the software because switching would disrupt their work.

AI assisted development introduces an interesting possibility: frustrated customers and independent developers may find it increasingly practical to experiment with alternatives. That doesn’t guarantee those alternatives will succeed.

An open source project still needs contributors, maintenance, funding, and a reason for people to keep using it. A commercial competitor needs a sustainable business model and a way to acquire and retain customers.

But reducing the initial development barrier could allow more ideas to reach the point where customers can actually evaluate them. For established companies, that’s another reason to pay attention to customer experience. A strong product isn’t defined only by what its software can do. It’s also defined by how well it serves the people who depend on it.

Building a Clone Is One Thing. Owning the Risks Is Another.

The ArtCraft project also raises questions about intellectual property and the responsibilities that come with releasing AI generated software.

Thomas has described his approach as clean room reverse engineering, meaning the applications are intended to reproduce observable functionality without copying Adobe’s proprietary source code.

Reimplementing software functionality can be lawful under certain circumstances, but that doesn’t automatically resolve every legal issue. Questions about interface similarity, trademarks, copyrighted expression, and the specific methods used during development may still matter. The use of AI adds further uncertainty, although the fact that a model was involved does not itself establish infringement.

At this stage, the publicly available reporting doesn’t establish that ArtCraft has violated Adobe’s intellectual property rights.

For organizations considering similar projects, the practical lesson is to evaluate these risks rather than assume that AI generated code is automatically free of legal or licensing concerns. There are engineering risks as well.

AI generated implementations can introduce vulnerabilities, licensing complications, undocumented dependencies, and unexpected behavior. Those risks become more consequential when software is distributed publicly or incorporated into commercial systems.

Open source availability makes code inspectable, but it doesn’t guarantee that someone has thoroughly reviewed it.

Organizations adopting AI assisted development need clear processes for code review, testing, dependency management, security validation, and release accountability. The faster software can be generated, the more important it becomes to ensure that the resulting code is understood and that its behavior can be verified.

What Should Engineering Leaders Take Away From This?

The ArtCraft story is interesting because it challenges assumptions about how much time and investment are required to create sophisticated software.

But the lesson for engineering leaders isn’t simply to start cloning competitors or replacing development teams with AI agents. It’s to reconsider where AI can create meaningful advantages within the software development process.

There are three areas worth examining.

First, reconsider which development opportunities are economically practical.

Projects that once appeared too expensive to explore may deserve another look. Internal tools, specialized applications, and alternatives to costly dependencies could become more accessible when AI reduces the effort required to prototype and implement functionality.

That doesn’t mean every project should be built internally. Organizations still need to consider maintenance, support, security, and the opportunity cost of owning another system.

But the build versus buy calculation may be changing.

Second, examine what makes your existing software difficult to replace.

If a competitor could reproduce a substantial portion of your application’s features, what would still make your product valuable?

The answer may be found in integrations, proprietary capabilities, performance, operational knowledge, customer relationships, or the reliability of the overall experience. Understanding those advantages can help engineering teams prioritize investments that strengthen the product beyond its visible functionality.

Third, adapt engineering processes to faster implementation cycles.

When teams can generate functionality more quickly, existing review and validation practices may struggle to keep pace.

Testing strategies, architectural boundaries, observability, and deployment processes need to support the increased volume and speed of development. Otherwise, faster implementation can simply produce more software that becomes difficult to maintain.

This is particularly important for organizations introducing AI coding agents into established engineering workflows.

The objective shouldn’t be to maximize the amount of code produced. It should be to use the increased development capacity to deliver better outcomes without compromising the systems that customers and businesses depend on.

These considerations aren’t limited to companies building products that compete with Adobe. They apply to almost any organization investing in software, whether that means developing a new application, modernizing an existing platform, or deciding how AI should fit into its engineering practices.

The Future of Software Isn’t Just About Who Can Build It

The ArtCraft experiment doesn’t prove that Adobe is about to lose its market position, or that anyone with an AI subscription can replace decades of software engineering. What it does suggest is that some of the assumptions we’ve made about the cost of building software deserve another look.

Applications that once required significant engineering investments may become increasingly accessible to smaller teams. New competitors may be able to test ideas that would previously have been too expensive to pursue. Established software companies may need to reconsider how much of their competitive advantage comes from functionality alone.

That’s an important shift, and one worth taking seriously. But building an alternative and becoming an alternative are still different things.

A product earns its place in an organization through more than a list of features. It has to integrate with existing workflows, behave predictably, protect users’ work, and continue improving long after its initial release.

At Ardan Labs, we work with engineering teams navigating that distinction every day. Whether we're architecting and developing software, helping organizations evaluate technical decisions through consulting, or expanding their engineering capabilities, the objective is the same: build software that delivers value beyond its initial implementation.

AI is changing how quickly we can get started. It may also change who can afford to compete.

The more interesting question is what companies choose to build, and what makes their software worth depending on once the novelty wears off.

Let’s Talk

Sources and Further Reading

Reporting

• Ars Technica (October 2026), “Software is over”: Bold AI developer takes aim at Adobe with open source clones. Original reporting on the project, Thomas’s development claims, and the limitations of the applications.
• TechSpot (October 8, 2026), “Software is over”: Developer uses AI to build free Adobe clones after frustration with cancellation fees. Reporting on ArtCraft, its development approach, and Thomas’s stated motivation.

Independent testing

• Creative Bloq (October 2026), I tried those free AI-coded Adobe Creative Cloud clones, and they have some big problems. Independent testing covering application functionality, compatibility, and limitations.

Official records

• U.S. Department of Justice (March 2026), Adobe Agrees to $150 Million Settlement and Injunction. Official details of the settlement involving Adobe’s subscription practices.

Commentary

• Creative Boom, AI cloned Adobe’s apps for free in design’s Napster moment. Industry commentary on the potential implications for creative software.
• DEV Community (October 13, 2026), People Are Vibe-Coding Clones of Every Paid App. What Actually Survives?. Discussion of sustainability and long term challenges for AI generated software.

Ardan Labs

• Development Services
• Consulting Services
• Staff Augmentation Services