This was the result of a _single_ prompt. Which actually shows the power of modern LLMs. I already have a from scratch C++ implementation of Photoshop, in my own custom UI toolkit, with my own custom GPU shaders. From scratch. Whole thing, ported over and I started last night. In preliminary benches it's roughly ~20-40% faster than their Photoshop rewrite. Will start heavy optimization passes and see how hard I can push it.
Can I ask what such a prompt looks like? Is it more along the lines of "implement all the features of Photoshop" or a detailed list of all the features that should be implemented?
The stark contrast between HN comments and everywhere else makes me think HN may be one of the last places left for grounded technical discussion.
Everyone on Twitter is acting as if Adobe’s software was decompiled, rewritten, and that’s it—game over, without even trying the damn thing. Seeing software engineers themselves espouse this nonsense is particularly annoying.
Yes, AI can recreate photoshop. But Photoshop is the product of thousands of tiny design, engineering, and product decisions. The idea that all of those decisions can simply be “decoded” from compiled binaries is laughable.
> But Photoshop is the product of thousands of tiny design, engineering, and product decisions. The idea that all of those decisions can simply be “decoded” from compiled binaries is laughable.
I actually think a couple passes with AI through the product will cover 80+ % of the use-cases people will have and people will have no problem switching to the new thing.
As far as I understand, inspecting the compiled binaries in any way would violate clean-room principles. At a minimum you'd need (A) one set of agents documenting the behavior of the executing binaries, e.g. manipulating the UI, and reviewing documentation and training manuals, and (B) a second set of agents whose only input is the output of the first set of agents. I'm not sure whether testing the real and AI generated agent side by side with equivalent inputs would constitute clean-room, although it might be legal.
I agree that a large part of the value of a product stems from "thousands of tiny design, engineering, and product decisions." But I don't agree with your conclusion. If the goal is to replicate the behavior of an existing piece of software then all you need to do is observe the behavior and replicate it. You don't need to engineer it in the same way, or arrive at it by making the same engineering and design decisions. Of-course in the end all you have is the replica, not the engineering and design heritage, product management, or the teams to carry the work forward. But that is the same problem open source "clones" of commercial products have often suffered from.
We're one major LLM release away from being able to spit out _the whole adobe suit_ in a single prompt, while being safer, faster, and more featureful. I wonder at what point will tech companies stop interrogating candidates on useless Leetcode problems.
Is there any interest in a C++ rewrite of Adobe products? A pure Rust implementation essentially holds back portability and control massively, while C++ allows you to control and account for every single bit of memory.
I don't know all the details of how this was done. But I think the big advance is that LLMs can now allow people to decompile binaries who don't know what "clean-room reverse engineering" means.
IMO either it was decompiled (a tedious but not complex task to do by hand, now automated) and illegal, or properly clean-roomed and buggy slop.
If it was me doing this, I'd anonymously dump the source onto a torrent, not parade around the media.
22 comments
[ 9.0 ms ] story [ 102 ms ] threadWould be amazing to this these tools in Linux distros.
Everyone on Twitter is acting as if Adobe’s software was decompiled, rewritten, and that’s it—game over, without even trying the damn thing. Seeing software engineers themselves espouse this nonsense is particularly annoying.
Yes, AI can recreate photoshop. But Photoshop is the product of thousands of tiny design, engineering, and product decisions. The idea that all of those decisions can simply be “decoded” from compiled binaries is laughable.
I actually think a couple passes with AI through the product will cover 80+ % of the use-cases people will have and people will have no problem switching to the new thing.
As far as I understand, inspecting the compiled binaries in any way would violate clean-room principles. At a minimum you'd need (A) one set of agents documenting the behavior of the executing binaries, e.g. manipulating the UI, and reviewing documentation and training manuals, and (B) a second set of agents whose only input is the output of the first set of agents. I'm not sure whether testing the real and AI generated agent side by side with equivalent inputs would constitute clean-room, although it might be legal.
I agree that a large part of the value of a product stems from "thousands of tiny design, engineering, and product decisions." But I don't agree with your conclusion. If the goal is to replicate the behavior of an existing piece of software then all you need to do is observe the behavior and replicate it. You don't need to engineer it in the same way, or arrive at it by making the same engineering and design decisions. Of-course in the end all you have is the replica, not the engineering and design heritage, product management, or the teams to carry the work forward. But that is the same problem open source "clones" of commercial products have often suffered from.
I'm certainly not going to hold Adobe stock long-term.
>Installers for macOS, Windows, Linux, FreeBSD and the web are attached to each GitHub release
>On FreeBSD 14 (x86_64), the release has a tarball
>photocraft-<version>-freebsd-x86_64.tar.gz
IMO either it was decompiled (a tedious but not complex task to do by hand, now automated) and illegal, or properly clean-roomed and buggy slop.
If it was me doing this, I'd anonymously dump the source onto a torrent, not parade around the media.