Fra «svart boks» til kreativt råmateriale
Mange har hatt den samme tanken: «Jeg liker akkurat den funksjonen i et gammelt program – eller den mekanikken i et spill. Hvordan virker den egentlig, og kan jeg lage min egen variant?»
Tidligere krevde det mye spesialkompetanse bare å begynne å lete. Nå kan AI gjøre inngangen langt lavere. REA – Reverse Engineer Anything kobler en agent til analyseverktøy som kan undersøke autorisert programvare og gjøre tekniske spor mer lesbare: hvilke moduler som hører sammen, hva som skjer når en knapp trykkes, eller hvordan en avgrenset beregning flyter gjennom et eldre program. [1]
Dette er mer enn «bare en MCP». MCP er forbindelsen mellom agent og verktøy. Det interessante med REA er arbeidsflyten rundt forbindelsen: agenten kan gå fra et konkret spørsmål, via analyseverktøy, til funn med instruksjoner, referanser og begrensninger. Derfra kan en utvikler forstå, dokumentere, teste og bygge noe nytt. [1]
Den store muligheten er ikke å få en AI til å kopiere alt. Det er å gjøre programvarehistorie, funksjoner og arbeidsmåter lærbare igjen – slik at flere kan skape noe eget.
Spill man drømmer om kan bli mulige å lage
Den mest inspirerende siden av denne utviklingen er at en gammel idé ikke lenger må stoppe ved «jeg skulle ønske noen lagde det». En utvikler eller et lite kreativt team kan studere prinsipper bak gamle spill, velkjente grensesnitt eller smarte arbeidsflyter – og bruke innsikten til å lage et nytt spill, en ny simulering eller en helt annen opplevelse.
REA sine egne eksempler er bevisst avgrensede og godt dokumentert. I prosjektet rundt Windows-spillet DX-Ball fra 1996 brukes REA til å forstå én konkret lydpanoreringsberegning. Den rekonstruerte C-funksjonen er kontrollert mot originaladferden i 3 205 tilfeller og mot 63 kompilerte byte. [2] Det er ikke «AI lagde hele spillet». Det er et mye mer interessant bevis på at et lite stykke gammel programvare kan bli forståelig, testbart og vedlikeholdbart igjen.
Et annet eksempel er Touhou 4 (TH04), der REA hjelper med å forklare en avgrenset beregning bak en kule-ring som kan dreies mot spilleren. Den dokumenterte rekonstruksjonen er kontrollert mot en 2 139-byte seksjon av den opprinnelige spillkoden. [3] Slike eksempler kan hjelpe med bevaring av spillhistorie, undervisning og originale prosjekter som bygger på samme type mekanikker – med eget uttrykk, egen kode og egne aktiva.
| Fra inspirasjon til eget prosjekt | Det kan bety i praksis |
|---|---|
| Forstå en mekanikk | Lær hvordan rytme, fysikk, poeng, navigasjon eller visuell respons kan være strukturert. |
| Lag en ny vri | Kombiner ideen med egne regler, egen verden, egen grafikk og egen historie. |
| Bevar noe verdifullt | Dokumenter hvordan et eldre internsystem, et spill eller en arbeidsflyt faktisk virket før kunnskapen forsvinner. |
| Prototyp raskere | La AI bygge en liten, original demonstrasjon av en idé før teamet velger hva som er verdt å utvikle ordentlig. |
Det er remiks på den gode måten: ikke å overta andres verk, men å forstå hvorfor noe fungerte – og gjøre det til utgangspunkt for et nytt og selvstendig arbeid.
Adobe er ikke blitt open source – men alternativene kommer raskere
Det går historier om at «Adobe er blitt open source». Det er ikke riktig. Adobe har ikke gjort Creative Cloud åpen kildekode.
Det som faktisk skjer, og som er spennende, er at uavhengige open source-prosjekter bygger frie alternativer til velkjente kreative arbeidsflyter. ArtCraft beskriver tolv Rust-baserte apper for blant annet bildebehandling, vektorgrafikk, video, PDF, lyd, presentasjoner, CAD og regneark. De er laget som selvstendige, åpne programmer som skal kunne kjøre på brukerens egen maskin. [4]
PhotoCraft beskriver seg som en clean-room-reimplementasjon av Photoshop-lignende arbeidsflyter. Prosjektet oppgir at det bygger på offentlige spesifikasjoner og observert adferd, ikke proprietær kode, shaders eller aktiva. Det støtter blant annet lag, masker og PSD-filer, men er samtidig merket early alpha. [5] VectorCraft beskriver tilsvarende en åpen, Rust-basert alternativ arbeidsflyt for Illustrator-lignende vektorgrafikk, men oppgir selv at det fortsatt er under aktiv utvikling og mangler deler av funksjonsbredden. [6]
Det er et viktig skille: ArtCraft er ikke Adobe, og det er ikke en garanti for at profesjonelle kan bytte hele produksjonen sin i morgen. Men det er et tydelig signal om at det blir raskere å bygge frie, lokale og mer kontrollerbare alternativer til programvare som tidligere krevde store abonnementer og store utviklingsteam.
Muligheten for små kreative team og bedrifter
For en liten bedrift på Sunnmøre trenger ikke dette starte med en «Adobe-erstatter» eller et nytt spillstudio. Muligheten kan være mer konkret:
- En bedrift med et gammelt internt system kan dokumentere hva det gjør før de bygger en moderne erstatning.
- Et design-, video- eller markedsføringsteam kan teste åpne verktøy og undersøke om noen arbeidsflyter kan kjøre lokalt, med mer kontroll over filer og kostnad.
- Et produktteam kan bygge en enkel demonstrasjon av en funksjon kundene etterspør, i stedet for å bruke måneder på å diskutere den i et møte.
- En kreativ person med en spillidé kan gjøre en spillbar prototype av sin egen versjon av en kjent mekanikk, med egne ressurser og egne regler.
Dette ligger nært vibecoding: AI kan gjøre det lettere å gå fra idé til noe som kan prøves. Men en prototype er ikke automatisk et produkt. Den må fortsatt få god design, testing, ytelse, tilrettelegging, sikkerhet og en tydelig eier.
Når REA er mer nyttig enn å starte fra blank side
Det finnes også situasjoner der det ikke holder å si «bygg det fra bunnen av». Kanskje har dere en eldre Windows- eller Electron-app med viktig funksjonalitet, men nesten ingen dokumentasjon. Kanskje har dere kjøpt et selskap med programvare ingen lenger fullt ut forstår. Eller kanskje trenger dere en autorisert sikkerhetsgjennomgang av en komponent som fortsatt er i drift.
Da kan REA være et lovende startpunkt. Det støtter analyse av blant annet native binærfiler, JavaScript/Electron, .NET, nettsteder, lagrede nettverksopptak, Android-artefakter og firmware. Noe av dette krever etablerte analyseverktøy som Ghidra, Hopper eller IDA, mens statisk JavaScript- og .NET-inspeksjon kan ha færre avhengigheter. [1]
Her er REA sin styrke: ikke at agenten later som den vet alt, men at den kan koble en forklaring til observerbare tekniske spor. Likevel må en utvikler vurdere funnene. Dekompilert kode og pseudokode er tolkninger, og gamle systemer inneholder ofte støy, unntak og forretningsregler som bare folk i virksomheten kjenner.
Dette bygger videre på AI-orkestrering: Modellen er ikke hele løsningen. En god agentopplevelse kommer fra samspillet mellom modell, verktøy, riktige kilder, test og menneskelig dømmekraft – ikke bare fra et imponerende modellnavn.
Åpenhet og frihet krever egne grenser
Den kreative optimismen blir sterkere, ikke svakere, når rammene er tydelige. REA oppgir at analyse av målet skjer lokalt. [1] Det kan være nyttig for egne filer og interne systemer. Men når en skybasert agent leser analysen, kan tekniske funn fortsatt bli sendt til modellleverandøren. Filnavn, kodeutdrag, API-endepunkter eller feilmeldinger kan være følsomme.
Velg derfor bevisst hvor agenten kjører, hva den får se og hvilke handlinger den får utføre. Lokal AI som testpartner og Mistral Large 4: Europas åpne AI for egne tjenester og datasentre viser to relevante spor når dataflyt og egen infrastruktur betyr mye.
Og uansett hvor fascinerende teknologien er: En analyse av andres programvare gir ikke rett til å kopiere kode, visuell identitet, data, aktiva eller forretningslogikk. REA sitt eget ansvarlig-bruk-forbehold avviser omgåelse av DRM, lisenssjekker og tilgangskontroller, samt kopiering av proprietær kode og aktiva. [7] EU-reglene har begrensede unntak for blant annet observasjon, testing og nødvendig interoperabilitet, men de er ikke en generell rett til å lage eller markedsføre et vesentlig likt program. [8]
Det beste utgangspunktet er derfor enkelt: jobb med programvare dere eier eller har skriftlig tillatelse til å analysere. Bruk offentlige spesifikasjoner, egne data og originalt innhold når dere bygger nytt. Da blir AI ikke en snarvei rundt andres arbeid, men en kreativ forsterker for deres eget.
Den nye superkraften er å kunne bygge videre
De beste ideene står sjelden alene. De oppstår når noen ser en god mekanikk, et godt arbeidsmønster eller en frustrerende gammel begrensning – og tør å spørre: «Hva om vi lager vår egen versjon, bedre tilpasset det vi faktisk trenger?»
REA kan være et verktøy for å forstå det som kom før. ArtCraft viser at åpne alternativer kan vokse fort når programvare blir mer tilgjengelig å bygge. Og AI-agenter gjør det enklere å ta første skritt fra inspirasjon til prototype.
Det betyr ikke at alt blir enkelt. Men det betyr at avstanden mellom en idé og en konkret, testbar versjon av ideen er blitt mye kortere.
Kilder
[1] morluto/rea — REA: Reverse Engineer Anything
[2] REA showcase — DX-Ball: Rebuilding a sound-pan calculation
[3] REA showcase — TH04: Reconstructing bullet patterns
[4] ArtCraft — Twelve open-source creative apps
[5] PhotoCraft på GitHub — clean-room, åpen bildebehandling i Rust
[6] VectorCraft på GitHub — åpen vektorgrafikk i Rust
[7] REA — Responsible-use disclaimer
[8] EU Directive 2009/24/EC — Legal protection of computer programs
[9] Nick Saraev på YouTube — I Tested The Viral Github Repo That Reverse Engineers Anything
