Treisprezece clone Adobe și Office scrise cu Claude: le-am compilat și le-am rulat pe toate

Publicat pe blogul TEN INVENT · Octombrie 2026

În primele două săptămâni din octombrie 2026, o organizație GitHub numită storytold, care până atunci avea doar câteva plugin-uri vechi pentru Unreal Engine, a ajuns cel mai discutat proiect open-source al lunii. Brandon Thomas, fondatorul studioului ArtCraft, a publicat versiuni rescrise în Rust ale Photoshop, Illustrator, Premiere Pro, Lightroom, After Effects, InDesign și Acrobat. O săptămână mai târziu au urmat Word, Excel, PowerPoint, o aplicație CAD și un editor audio. Aproape tot codul e scris cu Claude Opus 5.5. PhotoCraft, echivalentul Photoshop, a trecut de 59.000 de stele în paisprezece zile.

Presa s-a împărțit în două tabere: „Adobe a murit”, pe de o parte, și „sunt doar niște capturi de ecran generate de AI”, pe de alta. Niciuna nu te ajută prea mult dacă trebuie să decizi dacă le folosești, dacă construiești ceva asemănător sau cum îi explici unui client ce se întâmplă. Așa că am făcut partea plictisitoare. Am clonat toate cele treisprezece aplicații, le-am compilat din surse pe un Mac, le-am pornit, i-am dat lui PhotoCraft câteva sute de fișiere PSD reale, am măsurat memoria și ne-am conectat la serverele MCP. Mai jos e ce am găsit.

Ce s-a întâmplat, în ordine

• 30 septembrie: apar primele repository-uri: PhotoCraft, VectorCraft (Illustrator), FilmCraft (Premiere), LightCraft (Lightroom) și PdfCraft (Acrobat). EffectCraft (After Effects) și DesignCraft (InDesign) vin pe 1 octombrie. Toate au licență dublă, MIT / Apache-2.0.
• 2–3 octombrie: anunțul apare pe Reddit, iar postarea de pe r/SaaS strânge câteva mii de voturi. Acolo, Thomas promite paritate de 100% cu Adobe într-o lună.
• 6 octombrie: Hacker News. Thomas explică de ce a făcut-o: s-a ars de prea multe ori cu „taxa de anulare”, pe care o numește dark pattern. Tot acolo își ajustează promisiunea: 99%, în câteva luni, nu în ani. Contextul contează. În martie 2026, Adobe a acceptat să plătească 150 de milioane de dolari pentru a închide procesul intentat de Departamentul de Justiție al SUA: 75 de milioane penalități civile și 75 de milioane în servicii gratuite pentru clienți. Acuzațiile: taxe de reziliere anticipată ascunse și un abonament greu de anulat. Procesul fusese deschis în iunie 2024, iar Adobe nu și-a recunoscut vina.
• 7–9 octombrie: apar WordCraft, GridCraft și DeckCraft (Word, Excel, PowerPoint), apoi CadCraft, SoundCraft și FigCraft (Figma).
• 9–13 octombrie: subiectul ajunge în presa generalistă. Yahoo Tech, Gizmodo, TweakTown, t3n și alții scriu despre el, unii impresionați, alții sceptici. Pe 13 octombrie, Fabio Akita publică o analiză lungă, cu o concluzie simplă: Adobe nu a murit.

Până azi, 14 octombrie, Adobe nu a comentat public proiectul și nu se știe de niciun proces sau vreo somație. Așadar „scandalul” e un fenomen viral, nu un conflict juridic. Cel puțin deocamdată.

Ce se află de fapt în repository-uri

Stelele de pe GitHub nu spun mare lucru, așa că ne-am uitat direct în Git. Cifrele de mai jos sunt din clonele noastre, făcute pe 14 octombrie.

În total, cam 3,5 milioane de linii de Rust în două săptămâni și aproape 40.000 de funcții de test. Cele 13 repository-uri au 15.840 de commit-uri, iar 7.985 dintre ele au trailerul Co-Authored-By: Claude, majoritatea cu Opus 5.5. Cifra reală e probabil mai mare, pentru că la squash merge-urile venite de la contributori externi trailerul nu se păstrează mereu. Numai PhotoCraft are în jur de 1.990 de pull request-uri integrate și 620 încă deschise. Nu e un om care tastează singur. E un om, câțiva contributori constanți și multe sesiuni de agenți care lucrează în paralel, iar Git ține totul laolaltă.

Nici codul nu e doar o colecție de capturi de ecran. PhotoCraft e împărțit în 24 de crate-uri, iar ordinea straturilor e verificată la compilare: jos geometria și culoarea, apoi modelul documentului, algoritmii, compozitorii, formatele de fișier, motorul și, deasupra, interfața. Regulile din AGENTS.md sunt mai stricte decât în multe proiecte scrise de oameni: fără unwrap sau panic în afara testelor, fără unsafe, cu excepția unui crate izolat pentru tablete grafice, orice crash reparat vine cu un test de regresie, iar codul care lucrează cu pixeli e testat pe 8, 16 și 32 de biți.

Le-am compilat pe un Mac

Am testat pe un Mac Studio cu M3 Ultra și 96 GB de RAM, cu Rust 1.99. Pentru fiecare aplicație am compilat în modul release aplicația desktop și CLI-ul, fără să atingem codul.

Toate cele 13 s-au compilat din prima. Pe mașina asta, un release build durează între 30 de secunde și 3 minute și jumătate per aplicație. Apoi am dat fiecăreia câte o sarcină reală din linia de comandă, cu fișierele noastre, acolo unde am avut:

Sunt teste de bază (smoke tests), nu o recenzie a fiecărei aplicații. Arată că aplicațiile există, pornesc, citesc fișiere reale și scriu fișiere pe care alte programe le deschid fără probleme. Nu arată cum se descurcă într-o zi normală de lucru. La întrebarea asta răspunde documentul de paritate al proiectului, despre care scriem mai jos.

Cu PhotoCraft am mers mai departe.

Fișierele PSD. PhotoCraft are un script care descarcă seturi publice de fișiere de test, la versiuni fixe: cele din psd-tools (o bibliotecă Python) și ag-psd (una JavaScript), PngSuite și un set de fișiere Affinity. Am deschis fiecare PSD cu photocraft-cli, l-am aplatizat în PNG, l-am salvat din nou ca PSD și am redeschis rezultatul. 308 din cele 309 fișiere psd-tools și toate cele 51 de fișiere ag-psd (360 în total) trec de deschidere, salvare și redeschidere fără eroare. Singurul care pică e un separator de grup cu un mod de amestecare mai neobișnuit. Atenție: faptul că un fișier se deschide fără eroare nu înseamnă că arată identic cu Photoshop, iar noi nu am comparat pixelii cu Photoshop. README-ul spune că randarea e păstrată la 307 din 309 fișiere, ceea ce se potrivește cu ce am văzut noi.

Interfața. Aplicația pornește pe Metal, canvas-ul pe GPU funcționează, iar efectele de strat (bevel, glow, umbre, overlay-uri, contur) se văd pe straturi de text încă editabile. Meniurile, panourile, bara de unelte și scurtăturile de tastatură sunt evident copiate după Photoshop. Un detaliu care arată cât de departe merge imitația: Photoshop folosește ⌘H și ⌘M pentru comenzile lui, deși macOS le rezervă de obicei pentru Hide și Minimize, așa că PhotoCraft păstrează varianta din Photoshop și mută Hide și Minimize pe ⌃⌘H și ⌃⌘M. O anunță chiar în log, la pornire.

Memoria. Am creat din CLI un document de 12.000 × 8.000 de pixeli (96 MP), am adăugat zgomot, un Gaussian blur de 20 px și un strat de ajustare Curves, apoi l-am salvat ca PSD. A durat 3 secunde, cu un vârf de 4,5 GB de RAM. La 4.000 × 3.000 au fost 0,5 secunde și 866 MB. Merge, dar consumă cam 47 de octeți pe pixel pentru un singur strat, ceea ce explică issue-urile deschise despre memorie la fișiere mari. Ca termen de comparație, pixelii unui singur strat RGBA pe 8 biți, la 96 MP, ocupă în jur de 384 MB.

Partea interesantă: fiecare acțiune este o comandă

Dacă te uiți doar la capturi de ecran, ratezi arhitectura, adică ideea cea mai ușor de refolosit din tot proiectul. În PhotoCraft, fiecare element de meniu, unealtă și dialog execută o comandă dintr-un registru unic. Build-ul nostru are 909 comenzi. Le folosește interfața, dar și CLI-ul, un canal de control JSON și un server MCP.

Serverul MCP e partea cea mai inteligentă. Nu expune 909 unelte, ci doar 25: command_list, command_run, command_batch, doc_open, doc_save, doc_render_preview, ui_screenshot și încă câteva. Toată schema uneltelor are cam 25 KB de JSON. Agentul cere lista de comenzi doar când are nevoie de ea și rulează comenzile după ID. Ca termen de comparație, Akita a măsurat catalogul de unelte al unui alt server MCP popular, REA (pentru reverse engineering): aproximativ 2,3 MB de JSON, pe care agentul îi plătește în tokeni la fiecare sesiune.

Aceeași abordare apare și la celelalte aplicații: VectorCraft, LightCraft și restul au fiecare subcomanda lor mcp. Implicit, accesul la fișiere e închis: serverul MCP headless poate citi și scrie doar în folderele pe care i le dai explicit, cu --automation-read-root și --automation-write-root. Canalul de control al aplicației desktop ascultă doar pe loopback și cere un token.

Asta am lua și într-un proiect pentru un client, indiferent ce se întâmplă cu clonele. Dacă o aplicație are un singur strat de comenzi, pe care îl folosește și interfața, un agent AI poate face tot ce face și utilizatorul, fără o „integrare AI” separată care rămâne în urmă față de produs. Bonus: poți testa fiecare funcționalitate fără interfață.

Cifrele de paritate, citite cu atenție

PhotoCraft are un document mai onest decât orice titlu de presă: docs/target-app-parity.md. Compară aplicația cu Photoshop 2026 și e actualizat la câteva zile. Versiunea din 10–13 octombrie arată așa:

Două cifre contează. Acoperirea funcțională e de circa 76%: trei sferturi din meniurile, uneltele, panourile și formatele din Photoshop există, într-o formă sau alta. „Gata pentru lucru real” e de circa 45%: cât de aproape e de momentul în care un profesionist ar putea renunța azi la Photoshop pentru ea. Între cele două cifre stă toată partea grea a unui editor: managementul culorii, fișiere PSD create în Photoshop care trebuie să se întoarcă intacte în Photoshop, performanța pe fișiere mari, stabilitatea pe calculatoare reale, plugin-urile.

Documentul e onest și cu propriul trecut. Pe 3 octombrie estima 82% și 140–220 de ore-agent până la 95%. O săptămână mai târziu, aceeași estimare era descrisă drept „mult prea optimistă”: de la prima versiune se adunaseră cam 1.230 de issue-uri, majoritatea despre funcții considerate deja gata. Noua estimare e de 2.300–4.100 de ore-agent până la paritate completă, adică de vreo 15 ori mai mult decât prima, după doar o săptămână cu utilizatori reali.

Asta e cea mai utilă lecție pentru oricine estimează software construit cu AI. Un agent ajunge foarte repede la „funcția există”. „Funcția merge pe fișierele utilizatorilor” e cu totul altă pantă, iar cât de abruptă e afli abia când vin utilizatorii.

Clean room sau nu?

Thomas spune că aplicațiile sunt o reimplementare clean-room. Clasic, clean room înseamnă două echipe separate: una studiază originalul și scrie o specificație, cealaltă scrie codul după specificație, fără să fi văzut vreodată originalul. Aici avem un singur dezvoltator și un model antrenat pe cantități uriașe de cod și documentație publică, deci definiția clasică nu se aplică.

Ce scrie de fapt în repository e mai nuanțat. Regulile de contribuție interzic copierea de cod, shadere, iconițe, profiluri ICC sau alte resurse din software proprietar și cer ca funcțiile să fie refăcute „prin observație și pe baza specificațiilor publice”. Pentru formatul PSD există o specificație publicată chiar de Adobe. Pe de altă parte, documentul de paritate spune că Photoshop 2026 a fost analizat inspectând instalarea, fără a porni aplicația: tipurile de documente din Info.plist, fișierul cu scurtăturile de tastatură implicite, indicatorii de citire și scriere ai plugin-urilor și șiruri de text din executabilul principal. Nu e cod sursă, dar e mai mult decât „specificații publice”, iar licența Adobe restricționează reverse engineering-ul dincolo de ce permite legea.

Pe punctele care contează de obicei în instanță, precedentele sunt mai degrabă de partea clonelor. În SUA, în Lotus v. Borland (1995), instanța a decis că structura meniurilor unui program e o metodă de operare, nu o creație protejată, iar Google v. Oracle (2021) a considerat reimplementarea unui API fair use. În UE, CJUE a stabilit în SAS Institute v. World Programming (2012) că funcționalitatea unui program, limbajul de programare și formatele de fișier nu sunt protejate prin drept de autor. Riscul real e în altă parte: aspectul general (look and feel), iconițe prea asemănătoare și mărcile înregistrate. Aplicațiile nu folosesc numele sau siglele Adobe ori Microsoft, ceea ce reduce riscul. Nu e consultanță juridică și totul depinde de jurisdicție, dar ideea că „Adobe dă în judecată și câștigă ușor” e departe de a fi sigură.

Securitate: ce am face înainte să le folosim

Trei lucruri ne îngrijorează mai mult decât drepturile de autor.

1. Ritmul schimbărilor. PhotoCraft a integrat circa 2.000 de pull request-uri în două săptămâni, multe de la contributori noi, cu agenți implicați de ambele părți. Nimeni nu poate citi atent atâta cod. Dacă le folosești, fixează un commit sau un release și nu rula direct main.
2. Fișiere din surse necunoscute. Un editor de imagini sau de PDF-uri parsează formate complicate, venite de oriunde. Rust elimină o întreagă categorie de bug-uri de memorie, iar proiectele interzic unsafe aproape peste tot, ceea ce ajută. Rămân însă bug-urile de logică, fișierele de tip „decompression bomb” și alocările de memorie fără limită. Testul nostru de 96 MP arată cât de repede crește memoria. Nu le pune pe un server care procesează fișiere încărcate de utilizatori.
3. Agenți cu acces la fișiere. Implicit, serverele MCP sunt configurate corect: fără acces la fișiere până nu indici explicit folderele, iar canalul de control merge doar pe loopback și cere token. Lasă-le așa: dă-i agentului un folder de lucru, nu tot directorul home.

Release-urile pentru macOS sunt semnate și notarizate de Apple, ceea ce confirmă cine le-a construit, nu și ce conțin. Noi le-am compilat din surse, de la un commit pe care l-am notat, și am păstrat o copie privată a repository-urilor, în caz că dispar.

Ce înseamnă

Nu, Adobe nu a murit. Cea mai mare parte din valoarea Creative Cloud nu stă într-un executabil care poate fi copiat: știința culorii, profilurile de cameră, paletele și fonturile licențiate, funcțiile generative din cloud, integrarea cu tipografiile și agențiile și cei douăzeci de ani de fișiere PSD care trebuie să se deschidă exact la fel. Akita argumentează pe larg același lucru.

Totuși, trei lucruri s-au schimbat definitiv:

• O primă versiune credibilă costă acum foarte puțin. 3,5 milioane de linii de Rust structurat și testat, scrise în două săptămâni, sunt un fapt, nu un demo. Pentru unelte interne și produse de nișă, „ne-ar trebui o echipă timp de un an” nu mai e automat adevărat.
• Ultima jumătate nu s-a ieftinit în același ritm. Cifrele proiectului o arată: 76% acoperire funcțională, dar doar 45% gata de lucru, plus o estimare care a crescut de 15 ori după o săptămână cu utilizatori. Acolo rămân ingineria, testarea pe fișiere reale și deciziile de produs.
• „Agent-ready” devine o cerință de arhitectură. Un singur strat de comenzi, folosit de interfață, de CLI și de un server MCP cu puține unelte, e modelul pe care l-am recomanda azi oricărei aplicații noi pe care urmează să o folosească și agenți.

Dacă vrei o a doua părere despre ce poate construi realist AI pentru produsul tău și ce va rămâne în continuare treaba echipei, scrie-ne.