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:
