Stjörnhorn

Stjörnhorn — ein knotenbasierter Editor für Bild-, Video- und Datenverarbeitung. Das gesamte Projekt entstand kompromisslos mit KI-Unterstützung, für Programmierung, Assets und Dokumentation.

Jeder Softwareentwickler hat einen Stapel an Projektideen, die nie verwirklicht werden. Eines der Projekte auf meinem Stapel heißt OCVL. Es sollte für OpenCV Vision Library stehen. Ein High-Level-Wrapper der OpenCV-Bibliothek für Bildbearbeitung. Die Bibliothek sollte alles können, von einfachen Filteroperationen über das vollautomatische Stapeln von Astrofotos bis hin zum kamerabasierten Datenlogger für digitale Anzeigen aller Art.

Sie konnte all das, aber was ich nicht konnte, war, das Projekt zu Ende zu führen und eine wiederverwendbare Basis zu schaffen. Sobald ein Problem wie Astrostacking oder ein OCR-basierter Datenlogger gelöst ist, wird es langweilig. Der Rest sind API-Aufräumarbeiten, das Schreiben von Dokumentationen und der Bau einer Benutzeroberfläche – alles andere als spannend. Das Gegenteil von Spaß. Solche Aufgaben erledige ich im Job, aber nicht in der Freizeit. Am Ende stand die Designidee eines knotenbasierten Ablaufs, der es erlaubt, Filter und Bearbeitungsschritte aneinanderzureihen und zu erweitern. Es fehlte jedoch die Zeit, um das in einer Anwendung zusammenzuführen. Die Entwicklung eines solchen Freizeitprojektes würde sich über Jahre hinziehen.

Auf der anderen Seite wollte ich ohnehin einen Artikel über generative KI schreiben. Warum also nicht beides kombinieren? Das ist also die Geschichte von Stjörnhorn, der besten Software, die ich nie geschrieben habe.

Was ist Vibe Coding?

Der Begriff Vibe Coding kam Anfang 2025 auf und beschreibt eine Art, mit großen Sprachmodellen Software zu schreiben: Man beschreibt einem KI-Assistenten, was man möchte, akzeptiert die generierten Vorschläge weitgehend ungeprüft und korrigiert nur dort, wo das Ergebnis nicht der eigenen Erwartung entspricht. Das Ziel ist nicht, jede Zeile zu verstehen, sondern eine Idee in lauffähigen Code zu überführen.

"There's a new kind of coding I call 'vibe coding', where you fully give in to the vibes, embrace exponentials, and forget that the code even exists."
— Andrej Karpathy, Februar 2025

Für viele Softwareentwickler ist Vibe Coding allerdings ein abstoßendes Konzept. Ein Prozess, um automatisiert seelenlosen, minderwertigen und letztendlich unwartbaren Code zu erstellen. Mit einem System, das vermutlich weitgehend mit dem Quellcode des "Durchschnittsprogrammierers" auf GitHub trainiert wurde — aber was, wenn es funktioniert?

Projekt Stjörnhorn

Die Ausgangslage — OCVL, ein eingeschlafenes Hobbyprojekt

Wie bereits erwähnt, ist der Startpunkt meine unveröffentlichte OCVL-Bibliothek. Das sind 2500 Zeilen Code in 32 Dateien Python-Quellcode, an denen ich über eine Zeit von insgesamt 25 Monaten immer mal wieder gearbeitet habe. Ich habe sie hauptsächlich in Projekten für diese Webseite verwendet. OCVL-Code befindet sich im Touristenfilter, im Endlos-Zoom-Effekt, in einem undokumentierten visuellen Datenlogger und zuletzt auch im Archiv des Dithering-Artikels.

Modellsuche

Der Plan war, jede Möglichkeit der KI-Unterstützung zu nutzen — ohne Einschränkungen, ohne Reue. Das Projekt sollte plattformunabhängig sein, auf einem einfachen Python-Stack basieren und einen grafischen Knoteneditor haben. Ich wäre nur ein Projektmanager, der Architekturvorgaben macht.

Die Umsetzung erfolgte mit Claude Opus 4.6 1M und 4.7 1M. Das sind Modelle mit 1 Million Tokens Kontextfenster. Das ist wichtig, denn wenn man der KI einen Prompt sendet, dann wird intern nicht nur der Prompt übermittelt, sondern auch weite Teile des bisherigen Gesprächsverlaufes und relevante Dateien aus dem Projekt. Je mehr Kontext die KI hat, desto besser kann sie die Aufgabe verstehen und umsetzen.

Zunahme der Kontextfenstergrößen verschiedener Sprachmodelle 2023-2026. (Logarithmische X-Achsenskalierung)

Heute erscheint eine Million Token Kontextspeicher noch groß, ChatGPT 3.5-turbo fing im Jahr 2023 mit gerade einmal 4096 an. In zwei Jahren wird auch das wenig sein.

Rollenspiele

Ein Sprachmodell ist ein Werkzeug, aber auch ein Mitarbeiter. Es ist wichtig, ihm eine Rolle zuzuweisen und es darin einzuweisen. Für Claude geschieht das mit der Datei Claude.md. Für dieses Projekt sollte die KI als Softwareentwickler agieren und auch selbständig auf Wartbarkeit des Quellcodes achten. Im Verlauf der Entwicklung habe ich es auch mit der Aufgabe betraut, die Dokumentation zu schreiben und Backlogs zu erstellen. Das Dokument wurde im Verlauf der Entwicklung immer mehr erweitert.

Die Beiträge der KI wurden fast ausschließlich über sogenannte Pull-Requests (PR) in das Projekt integriert. Das heißt, die KI hat nicht direkt am Hauptzweig gearbeitet, sondern ihre Änderungen in einem separaten Branch umgesetzt. Dieser wurde dann von mir überprüft und in den Hauptzweig überführt. Das ist ein etablierter Prozess in der Softwareentwicklung. Er hatte den Vorteil, dass ich die Kontrolle über die Änderungen behalten konnte und gleichzeitig die KI frei arbeiten lassen konnte. Änderungswünsche habe ich in der Regel direkt mit der KI besprochen.

Die Claude CLI ist eine der Möglichkeiten, mit dem Programmierassistenten zu interagieren. Sie hat Vorteile, wenn man lokal arbeitet, beispielsweise kann man mit ihr zwei Projektverzeichnisse vergleichen.

Einführung in die Grundlagen der Softwareentwicklung

Das Projekt beginnt mit einem leeren Git-Repository und im Benutzerinterface von Claude Code. Tatsächlich habe ich meistens mit der Webseite gearbeitet. Die CLI ist zwar praktisch für das lokale Arbeiten, aber ich wollte Kontrolle über den Entwicklungsprozess ausüben und habe daher auf ein Entwicklungsmodell ausschließlich mit Pull-Requests gesetzt. Das geht zwar prinzipiell auch mit der CLI, aber diese würde Branches und Pull Requests unter meinem Account anlegen und könnte auch versehentlich direkt in den Hauptzweig pushen.

Praktisch wird man schon nach kurzer Zeit merken, dass die Qualität der Zuarbeiten sehr hoch ist und man häufig Änderungen durchwinkt. Das ist definitiv nicht der Durchschnittsprogrammierer, den ich erwartet hätte. Es ist ein sehr guter Programmierer. Einer, der wie ein menschlicher Entwickler Daten benötigt, um Fehler zu beheben. Aus diesem Grund ist es ratsam, der KI zu sagen, dass sie von Anfang an einen Logger einbauen soll. Damit kann sie später Programmabläufe nachvollziehen und bekommt Informationen, um Fehler systematisch zu analysieren.

Um die Komplexität des Projektes im Griff zu behalten, ist eine weitere Praxis der Softwareentwicklung, regelmäßig Refactoring-Sessions einzulegen. Damit das funktioniert, sollte man eine Test-Suite haben. Auch diese kann eine KI schreiben und vollautomatisch erweitern.

Was bleibt, ist den Technologiestack zu wählen und die KI mit der Umsetzung zu beauftragen. Für Stjörnhorn war Python und OpenCV gesetzt. Das UI-Toolkit war zunächst DearPyGui, aber nach kurzer Zeit bin ich auf PySide6 umgestiegen. Das alles kann man in einem Prompt erledigen lassen:

Lege ein neues Projekt auf Basis von Python, OpenCV und PySide6 an. Es soll
ein knotenbasierter Editor für Bild- und Videoverarbeitung werden, in den
sich später meine bestehende OCVL-Bibliothek einbinden lässt.

Richte zusätzlich folgende Qualitätssicherung ein:

- Einen Logger, der wichtige Programmabläufe und Fehler in eine Logdatei schreibt.
- Eine Behandlung von Abstürzen in nativem Code, sodass auch diese im Log landen
  und ich später nachvollziehen kann, was passiert ist.
- Ein Unit-Test-Framework mit ersten Tests für die Kernfunktionen.

Halte in der CLAUDE.md fest, dass neue Funktionen immer mit passenden Tests
geliefert werden sollen.

Das ist nicht der Originalprompt, aber er würde funktionieren.

Der Plan

Geplant war die Erstellung einer Software für die Bearbeitung von Bildern und Videos mit einem knotenbasierten Editor. Eine Art "Photoshop für Nerds", die es ermöglicht, komplexe Bildverarbeitungsabläufe zu erstellen, ohne eine einzige Zeile Code schreiben zu müssen. Die Software sollte in mehrere Module aufgeteilt sein, wobei jedes Modul eine eigene Seite darstellt, zwischen denen man hin- und herschalten kann.

Die Module im Einzelnen:

• Eine Startseite mit einer Liste der zuletzt verwendeten Dateien
• Eine Seite mit dem Knoteneditor
• Eine Seite für die Logfile-Ansicht
• Später kam noch eine Seite für Programmeinstellungen dazu
• Alle Bearbeitungsknoten sollten in Form von Python-Quellcodedateien vorliegen und dynamisch zur Laufzeit geladen werden.

Die KI sollte ebenfalls die Programmdokumentation erstellen und eine einfache CI/CD-Pipeline über GitHub Actions aufsetzen, denn das Projekt sollte so weit wie möglich automatisiert werden.

Niedrige Erwartungen und ein bescheuerter Name

Das Projekt begann unter dem Namen "Image-Inquest" als Test mit der Erwartungshaltung, dass es ultimativ scheitern würde. Allerdings waren die Fortschritte von Anfang an erstaunlich. Begonnen wurde mit DearPyGui, einem einfachen UI-Toolkit, das sich gut für schnelle Prototypen eignet. Es wurde gewählt, weil es einen einfachen Knoteneditor mitbrachte. Ich hielt das für entscheidend, da ich der KI nicht zugetraut habe, einen eigenen zu implementieren und keine Drittanbieterkomponenten im Projekt wollte. 124 Commits und ungefähr 8-10 Stunden Entwicklungszeit später hatte das Projekt folgenden Stand:

Eine leere Startseite, aber das Applikationsframework mit Modulaufteilung funktioniert bereits.

Der erste funktionsfähige Prototyp mit DearPyGui: Knoteneditor mit Knotenliste, Drag-and-Drop, allerdings noch keine lauffähige Bildbearbeitungskette.

Das mythische Stjörnhorn, Symbolbild für die Sloppifizierung der Softwareentwicklung oder magischer Helfer?

Es gab einen funktionierenden Knoteneditor mit einer Knotenliste, aus der per Drag and Drop Elemente in den Editor gezogen werden konnten. Es konnten Verbindungen zwischen den Bearbeitungsschritten erzeugt werden. Die Knoten wurden dynamisch geladen und enthielten bereits funktionsfähigen Code, den die KI vom OCVL-Projekt übernommen und angepasst hatte. Die Bearbeitungsschritte waren allerdings noch nicht funktionsfähig, sondern nur Platzhalter.

Um das noch einmal deutlich zu sagen: Das war der Stand nach einem Arbeitstag. Ab hier war klar, dass das Projekt nicht an den mangelnden Fähigkeiten der KI scheitern würde, denn auf dieser technologischen Basis hätte es weiterentwickelt werden können. Allerdings war auch klar, dass DearPyGui an seine Grenzen stieß.

Aus diesem Grund wurde das UI komplett auf PySide6 umgestellt. Nicht von mir, von der KI. Das war eine größere Umstellung, da PySide6 keinen Knoteneditor mitbrachte, aber die KI hat auch diese Aufgabe gemeistert und einen eigenen neu erstellt. Dieser sah von Anfang an besser aus als der von DearPyGui und war mit den Möglichkeiten der Qt-Lib leichter zu erweitern.

Jetzt brauchte das Projekt noch einen neuen Namen. Über Umwege wurde "Stjörnhorn" gewählt. Ans Altnorwegische angelehnt heißt es in etwa so viel wie "Sternenhorn". Es ist eine erfundene mythische Kreatur, die es eigentlich nicht geben kann. Ich fand das passend und es hatte 0 Treffer bei Google...

Stand nach 100 Stunden Vibe Coding

Zum Zeitpunkt des Schreibens dieses Artikels sind ungefähr 100 Stunden Entwicklungszeit in das Projekt geflossen. Das ist nicht viel für ein Softwareprojekt. Zeit für eine Bilanz.

Startbildschirm mit Recently-Used-File-Liste und Webview-Element für die Anzeige einer Kurzdokumentation.

Ein funktionsfähiger Knoteneditor mit einer Vielzahl lauffähiger Abläufe. Im Bild wird aus Erdbebendaten ein Hodogramm mit darunter liegender spektraler Heatmap gezeigt, die darstellt, in welche Richtung der Boden schwingt. Das Ganze wird als Video ausgegeben.

Jeder der mittlerweile über 50 verschiedenen Knoten ist dokumentiert. Die Dokumentation wird angezeigt, wenn er ausgewählt wird. Es gibt zusätzliche Funktionen im Header, um beispielsweise Daten zu inspizieren, und man kann Knoten ausblenden und so im Ablauf bestimmte Schritte überspringen. Es gibt Knotenparameter, welche wie Konstanten wirken, Input-Ports und Output-Ports. Für alle Datentypen gibt es spezifische UI-Elemente für deren Eingabe. Die Ports akzeptieren jetzt verschiedene Datentypen: Matrix, Skalar, Farbbilder, Graustufenbilder und Tabellendaten.

Ein funktionsfähiger Knoteneditor mit einer Vielzahl lauffähiger Abläufe. Im Bild wird aus Erdbebendaten ein Hodogramm mit darunter liegender spektraler Heatmap gezeigt, die darstellt, in welche Richtung der Boden schwingt. Das Ganze wird als Video ausgegeben.

Die Benutzeroberfläche kann mit zwei verschiedenen Skins verwendet werden. Das hier gezeigte dunkelblaue Farbschema basiert auf einem KI-generierten Vorschlag für das Titelbild der Applikation. Die KI wurde einfach beauftragt, ein Farbschema zu erstellen, das ähnlich aussieht.

Projektstatistiken

Blicken wir auf die Statistiken nach ungefähr 100 Stunden Entwicklungszeit. Auf meinen Namen laufen lediglich 7% der Codezeilen. Aber auch das ist irreführend, denn diese Zeilen sind mit Sicherheit auf den Quellcode der OCVL-Bibliothek zurückzuführen, welche ich als Referenz im Repository abgelegt habe. Das ist passiver Code, der nicht verwendet wird und nur als Vorlage dient. Wenn man das herausrechnet, dürfte mein Beitrag bei maximal 1-2% liegen. Ich kann mich nicht erinnern, überhaupt etwas direkt zur Codebasis beigetragen zu haben. Ich wollte hier auch nicht Programmierer sein, ich wollte Softwarearchitekt sein.

Einige Basismetriken des Projektes im Überblick.

Das Ergebnis nach ungefähr zwei Wochen Netto-Entwicklungszeit: 46600 Zeilen Quellcode netto erstellt, wovon im Projekt 34000 erhalten geblieben sind. Die KI hat 219 Pull Requests erstellt, was im Mittel 10 pro Tag bedeutet.

Wer hat den Code wirklich geschrieben und wie verteilt er sich über das Projekt?

Der kumulative Netto-Codezuwachs zeigt eine hohe Aktivität mit rasantem Zuwachs. Gegen Ende des Testzeitraumes habe ich den Fokus verstärkt auf Refactoring gelegt. Das erklärt die Zunahme an entfernten Zeilen.

Kumulativer Netto-Codezuwachs über der Zeit. Am Ende blieben nicht alle Zeilen im Projekt, denn in Refactoring-Sessions wurden auch Zeilen gelöscht.

Code-Churn pro Tag. Zeigt, wie viele Zeilen Code täglich geändert wurden.

Die Stabilität in der Entwicklung wurde nicht zuletzt durch eine umfassende Test-Suite erreicht, die von der KI selbständig erweitert wurde. Es gibt über 760 Unit-Tests, die alle automatisch ausgeführt werden, wenn die KI Quellcode generiert. Ich habe ungefähr 3 dieser Tests explizit angefordert, die restlichen wurden von der KI selbständig erstellt.

Übersicht der Test-Suite. Zeigt die Anzahl der Unit-Tests und deren Verteilung im Quellcode.

Das Ende oder ein Anfang?

Ob es einem gefällt oder nicht, Vibe Coding kann funktionieren. Die Annahme, dass ich einen vergleichbaren Projektfortschritt mit traditioneller Programmierung hätte erstellen können, erscheint absurd. Ein solcher Fortschritt geht nur mit KI-Unterstützung. Der aktuelle Projektstand ist, was UI und UX angeht, weit besser als alles, was ich in vergleichbarer Zeit hätte erstellen können.

Ich habe während der gesamten Entwicklung von Stjörnhorn immer wieder auf den Punkt gewartet, an dem die KI den Überblick verliert und mir eine Codebasis übergibt, die so unverständlich ist, dass ich sie nicht mehr warten kann. Das ist nicht passiert. Zum einen hat sie den Überblick nicht verloren, zum anderen habe ich dafür gesorgt, zumindest die Architektur übersichtlich zu halten. Ich kenne die Codebasis von Stjörnhorn nicht in jedem Detail, aber ich verstehe die Architektur und die prinzipiellen Abläufe. Dennoch bin ich der Meinung, dass es für mich ein erheblicher Aufwand wäre, in allen Teilen der Software den kompletten Überblick zu erlangen. Mittlerweile glaube ich auch nicht, dass das noch notwendig ist.

Es ist aber anstrengend, ständig große Mengen an maschinengeneriertem Code zu überprüfen, und mit der Zeit wird man dazu übergehen, die Änderungen ungesehen durchzuwinken. Vibe Coding nimmt zu einem gewissen Teil auch den Spaß an der Softwareentwicklung. Es führt zu einer Beschleunigung auf Kosten des Verständnisses der Programmabläufe. Die von mir wahrgenommene Produktivitätssteigerung ist enorm und geht weit über die in Papers zu diesem Thema berichteten Werte von 10%-60% hinaus. Wenn tatsächlich Firmen nur 10% Produktivitätssteigerungen durch KI-Unterstützung erreichen, dann sollte die KI in diesen Firmen das Management ersetzen. Die Softwareabteilung ist dort nicht das Problem.