Auf Mastodon ansehen
Inhaltsverzeichnis
Teil 1: Motivation
Teil 2: Treenotes (das ist dieser Artikel)
Teil 3: UniTree
Das Ende von proprietärer Software
Wenn ich mir anschaue, was andere Personen mit KI-unterstützter Softwareentwicklung zustande bringen, wird mir schwindelig. Dabei denke ich nicht nur an Vibe-Coding oder Modelle, die einen bei der Entwicklung unterstützen, sondern auch an das Reverse Engineering von Closed-Source-Software. Vielleicht habt ihr mitbekommen, dass ArtCraft mal eben die gesamten Adobe-Creative-Anwendungen reversed hat. Auch die Microsoft-Office-Suite steht auf dem Radar. Das Rezept dazu lautet:
- Führe ein Reverse Engineering des proprietären Binärcodes durch.
- Erstelle daraus eine Spezifikation der Anwendungen.
- Generiere auf der Grundlage dieser Spezifikation neue Anwendungen.
KI-Modelle sind in der Lage, den Binärcode von proprietären Anwendungen in Software-Spezifikationen zu überführen. Auf dieser Basis können ähnliche Applikationen generiert werden. Damit ist das Geschäftsmodell von proprietärer Software gestorben. Ab sofort ist alles Open Source.
Ob dieses "Reverse-Spec-Free"-Modell wirklich funktioniert und rechtlich haltbar ist, werden wir in den nächsten Monaten erfahren. Doch darum soll es in diesem Artikel nicht gehen; ich wollte nur einen Ausblick geben.
Erst einmal ausprobieren
Bevor ich 500 Seiten Spezifikation für UniTree schreibe (oder reverse engineere), möchte ich erst einmal ausprobieren, ob sich eine ähnliche, aber viel einfachere Anwendung Vibe-Coden lässt. Dazu habe ich aus Gründen, die ich nicht näher erläutern möchte, Copilot verwendet. Mein erstes Ziel war es, eine einfache Note-taking App generieren zu lassen. Los geht es, hier ist der erste Prompt:
Generiere eine einfache Anwendung für den GNOME-Desktop. Die Anwendung zeigt links einen treeview. Zu jedem Element im treeview gibt es auf der rechten Seite einen Texteditor. Jeder Text soll in einer eigenen Datei gespeichert werden, die hierarchisch in einer Verzeichnisstruktur abgelegt werden soll. Verwende Python, Gtk4 und libadwaita. Schreibe den gesamten Code in nur eine Python-Datei.
Der erste Versuch ist fehlgeschlagen:
Funktioniert nicht. Fehlermeldung:
(python3:32057): Adwaita-ERROR **: 22:38:21.243: gtk_window_set_titlebar() is not supported for AdwApplicationWindow
zsh: abort (core dumped) ./treenotes.py
Copilot sagt dazu: "Der Fehler ist korrekt. In libadwaita darf bei Adw.ApplicationWindow kein eigenes Titlebar-Widget mittels "self.set_titlebar(header)" gesetzt werden. Das war früher bei Gtk.ApplicationWindow üblich, bei Adw.ApplicationWindow aber nicht mehr. Stattdessen muss die HeaderBar Bestandteil des Inhalts sein, typischerweise über eine Adw.ToolbarView.
Das ist ein typisches Muster beim Vibe-Coding, aber auch bei normalen Fragen an einen Chat-Bot. Es wird ein fehlerhaftes Ergebnis geliefert. Nachdem man auf den Fehler hingewiesen hat, sagt das Modell im Brustton der Überzeugung: "Ist doch klar, dass das nicht funktionieren kann". Ich frage mich, warum denn nicht gleich richtig?
Mein nächster Prompt:
Schlage nicht einzelne Korrekturen vor, sondern generiere den Code korrekt, so wie ich es befohlen habe.
Danach lief die Anwendung, hatte aber noch einige Verbesserungen nötig:
Speichere die Daten nicht im Home-Verzeichnis, sondern im current working directory. Füge ausserdem eine Löschfunktion für die Elemente im Treeview hinzu.
Copilot kommt dann mit Code-Schnipseln um die Ecke, die die angepassten Teile enthalten. Deshalb:
Generiere die vollständige aktualisierte Datei.
Die Verbesserungen wurden korrekt eingefügt. Wie die Anwendung aussieht, seht ihr im Titelbild dieses Artikels. Die Dateistruktur gestaltet sich folgendermassen:
Der generierte Python-Code (400 Zeilen) sieht sauber aus und ist klar strukturiert. Leider ist er nicht dokumentiert, was mit einem weiteren Prompt schnell zu erreichen ist.
Wer Python kann, versteht den Code und kann ihn überprüfen. Häufig ist das beim Vibe-Coding nicht der Fall. Die Leute verstehen den Code nicht, weshalb sie ihn nicht von Hand anpassen oder pflegen können. Für schwerwiegender halte ich das Argument, dass Vibe-Coding eingesetzt wird, weil man sich die Zeit zur Überprüfung des Codes sparen möchte. Bei 400 Zeilen Code, ist das ein schwaches Argument, aber richtige Anwendungen kommen locker auf 10'000 bis 100'000 Codezeilen. Die sichtet niemand mehr.
Meine kleine Anwendung ist weit entfernt von "benutzbar". Wer sie ausprobieren möchte, findet hier den Quellcode. Es gibt viele Unzulänglichkeiten:
- Die Dokumentation des Codes fehlt.
- Das linke Panel ist zu breit.
- Man möchte keine txt‑Endungen im Baum haben.
- Beim Hinzufügen von Elementen, wird der Baum jedes Mal geschlossen.
- Die Einordnung von Elementen erfolgt alphabetisch und ignoriert die aktuelle Hierarchieebene.
- Baumelemente zeigen den zugehörigen Text nur nach Doppelklick.
- Neue Ordner werden unterhalb des aktuellen Ordners eingefügt, anstatt auf derselben Ebene zu bleiben.
- und so weiter, und so fort
Ich bin mir sicher, dass ich diese Mängel durch weitere Prompts beheben kann. Doch für diesen Artikel soll die kleine Demonstration reichen. Im nächsten Artikel der Serie lasse ich die KI auf den Quellcode und die Spezifikation von UniTree los. Ich habe wenig Hoffnung, dass dabei etwas Brauchbares herauskommen wird. Insbesondere, weil Copilot nicht das beste Modell für diese Aufgabe ist.
Titelbild: selbst
Quellen:
Was ist denn nun eigentlich der Sinn dieser Übung?
Ralf schreibt es selbst: "weil Copilot nicht das beste Modell für diese Aufgabe ist"
Dann vielleicht ein besseres LLM nehmen. Oder verschiedene Ansätze vergleichen. Aber das ist ja nicht ganz unaufwändig. Und andere machen das schon zuhauf und Vollzeit. Warum dann nicht zumindest darauf aufsetzen und das "aktuell beste Coding-LLM" für diese Serie verwenden?
Oder oder... ;-)
> Vielleicht habt ihr mitbekommen, dass ArtCraft mal eben die gesamten Adobe-Creative-Anwendungen reversed hat.
Naja, mal eben... Den Tests zufolge, die ich gelesen habe, sind die noch lange nicht am Ziel, einiges funktioniert, aber das meiste nicht. Und wir alle wissen, die ersten 80% der Arbeit sind ruckzuck erledigt, aber die Details.... > > Das Rezept dazu lautet: Führe ein Reverse Engineering des proprietären Binärcodes durch. Erstelle daraus eine Spezifikation der Anwendungen.
Nach meinen Informationen geht es eben nicht um klassissche Reverse Engineering sondern um "clean-room reverse engineering", also Analyse des Programmverhaltens und von Spezifikationen. Reverse Engineering ist nämlich nicht überall erlaubt.
Sorry, das zweite Zitat ab "Das Rezept..." sah in der Voransicht korrekt aus.
Ja, das hat Ralf für Artcraft falsch umschrieben. Die nutzen nicht AI + Reverse Engineer Anything und deshalb auch keine Binärdateien. Er hat meinen Artikel aber korrekturgelesen, daher verstehe ich den Patzer nicht so ganz ;-)
Weil Ralf auch Fehler macht :)
Hallo Ralf,
vielen Dank für die Serie. Macht einfach wieder Spaß, es zu verfolgen. Magst Du das Ganze nicht vielleicht einfach nochmal direkt mit OpenCode und dem aktuell immer noch kostenlos nutzbaren Space Bunny Free von OpenCode Zen versuchen? Dann hast Du auch eine saubere Suite und der Agent kann auch selber Tests ausführen und den Code besser bearbeiten. Gerade jetzt, wo für so etwas noch eine kostenlose Promo zur Verfügung steht, wäre es einen doppelten Blick vielleicht wert. Ich selber habe jetzt schon sehr viel mit Space Bunny gemacht und kann nur Gutes darüber berichten und über OpenCode sowieso.
Gruß Michael
Hallo, so kann es leider nicht wirklich gut funktionieren. "Vibe coden" funktioniert meiner Erfahrung nach so nicht (gut).
Damit es wirklich funktioniert und gute Ergebnisse leifert muss einiges an Vorarbeit leisten:
Erstelle skills und "trainiere" deinen Agenten, damit er das macht was du willst (wie soll der code formatiert werden, welche Kommentare willst du, welche speziellen Anforderungen/Versionen hast du, wie soll die UI aufgebaut sein). Eigentlich so wie man einen neuen Programmierer in einer Firma auch einführt.
Erstelle Agenten die verschiedene Aufgaben übernehmen: Ein Senior-Programmierer der die Planung mit dir übernimmt (hier ein gutes LLM nutzen z.B. Claude Opus 5.5) und dann einem Junior-Programmierer (preiswertes LLM) ganz genau sagt was dieser tun soll.
Automatische Tests müssen rein, damit bei jeder Änderung die Funktionsweise des Programms überprüft werden kann.
Ein gute Codingumgebung ist Pflicht für die Agenten (Stichwort "harness") (z.B. opencode).
Damit habe ich gute Erfolge erzielt. Hängt viel von den Skills und Modellen ab.
Diese Vorarbeiten machen den Unterschied zwischen "vide coden" funktioniert super und funktioniert gar nicht.
Ich könnte anbieten deinen alten Quellcode von Claude Opus 5.5 bearbeiten lassen, das ist nicht mit Copilot vergleichbar.
Man kann Opus 5.5 auch mit Copilot verwenden. Sie (MS$ / Github) haben ja keine eigenen Modelle. (Mittlerweile haben sie auch MAI Modelle). Copilot funktioniert auch gut. Man muss aber Copilot in VSCode benutzen. Copilot CLI ist furchtbar. Auch jede Integration von Copilot in andere IDE z.B. Jetbrains IDEs machen keinen Spaß.
Ich habe gute Erfahrungen mit VS Code und der Claude Code Extension gemacht. Das funktioniert bei mir am besten.