Was fehlt, einfach selbst bauen: Wie Vibe-Coding Linux und Co. zugänglicher machen könnte

Linux ist längst eine ernsthafte Alternative zu Windows. Doch oft fehlen Programme, die man unter Windows ganz selbstverständlich nutzt – oder die vorhandenen Alternativen überzeugen nicht. Also habe ich ein Experiment gewagt und mithilfe von KI einen eigenen Bildbetrachter entwickelt. Denn Vibe-Coding könnte Linux vielfältiger, lebendiger und zugänglicher machen, indem Nutzer selbst entwickeln, was ihnen fehlt.

Von Michael Förtsch

Ja, Windows kann einem manchmal auf die Nerven gehen. Mit der ständigen Werbung für den Cloud-Speicher OneDrive, der Integration ungewollter CoPilot-KI-Funktionen, dem Zwang, ein Microsoft-Konto anlegen zu müssen und der teils undurchsichtigen Erhebung von Nutzerdaten. Microsoft hat so manche der Kritikpunkte in Windows 11 mittlerweile adressiert. So einiges ist besser geworden. Aber dennoch: Immer wieder versuche ich es mit Linux. Aber immer wieder kehre ich zu Windows als mein hauptsächlich genutztes Betriebssystem zurück. Denn auch wenn sich bei Linux in den letzten Jahren sehr viel getan hat und viele Linux-Distributionen heute sehr gut nutzbar sind, bleibt vieles umständlich. Doch der Hauptgrund für mich ist: Unter Linux fehlen mir recht oft Programme, die für mich unter Windows einfach selbstverständlich sind. Die fest in meine Arbeitsabläufe integriert sind und ich deshalb nicht missen möchte.

Sicher, einige davon lassen sich mit WinBoat, Bottles oder Wine als Windows-Apps auch unter Linux ausführen. Das funktioniert mal besser, mal schlechter. Microsoft Word etwa läuft über WinBoat flüssig, während Capture One ziemlich krampft. Bei Programmen, mit denen man längere Zeit am Stück arbeitet, fallen solche Umwege weniger ins Gewicht. Anders sieht es bei kleinen Apps aus, die man über den Tag verteilt immer wieder nur für Sekunden benötigt. Die müssen möglichst snappy und sofort zur Hand sein. Beispielsweise IrfanView: ein auf den ersten Blick einfacher Bildbetrachter, der jedoch mit etlichen Zusatzfunktionen vollgepackt ist und den ich seit über 20 Jahren nutze. Über die Kompatibilitätsschicht ist es nicht so reibungslos und instantan wie eine native App. Zwar existieren mit Nomacs und anderen Programmen ähnliche Apps. Aber keine ließ sich so bedienen, wie ich es wollte, und bot zugleich alle Funktionen, die ich benötigte. Das war der Punkt, an dem ich mich fragte: Okay, warum nicht einfach selbst eine Alternative bauen? Mit Künstlicher Intelligenz – und Vibe-Coding.

Denn seit meinem letzten größeren Exkurs dazu haben sich die KI-Modelle und ihre Fähigkeiten, aber auch dedizierte Vibe-Coding-Programme deutlich weiterentwickelt. Manche Nutzer erschaffen mit KI-Tools inzwischen ganze Online-Rollenspiele, millionenschwere Telemedizin-Plattformen oder machen sogar PlayStation-4-Spiele auf PC und Mac spielbar. Da sollte ein Bildbetrachter doch eine mehr als lösbare Aufgabe sein, oder? Zumal ich IrfanView keineswegs einfach kopieren oder nachbauen wollte. Wenn ich ein solches Projekt schon angehe, sollten mir IrfanView und Nomacs zwar als Richtschnur dienen, aber ich wollte auch etwas Eigenes daraus machen: eine Anwendung, die ich um Funktionen, Möglichkeiten und Ideen erweitern kann, die ich bislang vermisst habe – oder die mir einfach zeitgemäß erscheinen. Ich wollte mit KI einen Bildbetrachter bauen, der schnell ist, in seinen Grundzügen unkompliziert wirkt, aber deutlich mehr kann, als nur Bilder anzuzeigen.

Vom Prompt zum eigenen Bildbetrachter

Begonnen habe ich die Arbeit in Codex von OpenAI. Ich beschrieb in einem sehr ausführlichen Prompt, was ich haben wollte und woran sich die KI orientieren sollte. Sie sollte mir Vorschläge und Optionen zur Herangehensweise unterbreiten: Entwicklung eher in C++ oder Rust? Welche Vor- und Nachteile bieten die beiden Programmiersprachen? Ich wies die Künstliche Intelligenz an, mich zu Details zu befragen. Beispielsweise dazu, welche Bildformate unterstützt werden sollen, wie sich das Programm in bestimmten Situationen verhalten soll, wie die Menüs aufgebaut sein sollten und ob das Programm eher nur für mich gedacht sein oder auch andere Nutzer ansprechen sollte. Es verging wohl eine halbe Stunde, bevor überhaupt Code generiert wurde. Aber dann ging es tatsächlich recht schnell. Binnen einer Stunde stand der erste brauchbare Prototyp. Gebaut in der bewährten Programmiersprache C++ und mit QT, Sammlung von Softwarebausteinen, die eine moderne, einheitliche Benutzeroberfläche unter Linux, Windows und MacOS ermöglicht.

Seitdem sind mehrere Stunden mit Codex und den GPT-Modellen, aber auch Sitzungen mit dem KI-Coding-Tool Cline und Modellen wie Kimi K3, GLM 5.3 und anderen in das Programm geflossen. Ein Programm, das zunächst schlicht IxView hieß, dem ich mittlerweile aber einen noch absurderen Namen verpasst habe. Immer wieder testete ich, stieß auf Probleme oder Verhaltensweisen des Programms, die behoben oder angepasst werden mussten. Ich ließ die KI-Tools regelmäßig Fehlerchecks durchführen und nach und nach die von mir angedachten Funktionen einbauen. Nach etwa ein oder zwei Wochen mit gelegentlichen Sitzungen ist der Bildbetrachter schon ziemlich solide – das sage nicht nur ich, sondern auch ein erfahrener Entwickler. Bilder anzeigen: kein Problem. Er ist schnell. Bilder lassen sich zuschneiden, Farben bearbeiten und ganze Bildarchive in andere Formate umwandeln. Auch können direkt aus Bildern Texte extrahiert, QR-Codes ausgelesen und noch einige andere Dinge erledigt werden. Fertig ist der Bildbetrachter zwar bei Weitem noch nicht, aber benutzbar. Sowohl unter Windows, MacOS als auch eben Linux, wofür ich ihn ursprünglich entwickeln wollte.

Das soll übrigens keineswegs ein Aufruf sein, IrfanView den Rücken zu kehren. Ganz im Gegenteil: Wer IrfanView verwendet, sollte ihren Entwickler unterstützen. Unter Windows ist IrfanView für mich nach wie vor nahezu unschlagbar.

Mit jeder weiteren Entwicklungsrunde kommt die mittlerweile üxzView genannte App dem näher, was ich wollte. Genau das könnte Vibe-Coding langfristig zu einer transformativen Kraft in digitalen Ökosystemen wie Linux machen. Denn diese sind bislang sehr stark von den Interessen, Fähigkeiten und Prioritäten ihrer gewachsenen Entwicklergemeinschaften geprägt. Eine Szene, in der zumindest teilweise eine bemerkenswerte Betriebsblindheit herrscht: Technisches Vorwissen wird gerne als selbstverständlich vorausgesetzt, Kritik an umständlichen Abläufen und Bedienkonzepten abgewiegelt und mangelnde Benutzerfreundlichkeit als Ausdruck von Nutzungsfreiheit oder mit Verweis auf etablierte Konventionen verteidigt. Wer damit nicht zurechtkommt, der muss sich eben mehr anstrengen. Als wäre das Problem stets nur beim Nutzer zu suchen. Vieles, was für langjährige Linux-Enthusiasten selbstverständlich und intuitiv erscheint, ist für Einsteiger obskur und zum Teil extrem befremdlich. Das betrifft sowohl die Linux-Distributionen selbst als auch die Programme, die es dafür gibt.

Was ist eigentlich ein üxz?

Meinen Image Viewer hatte ich ursprünglich ganz provisorisch IxView genannt – in direkter Anlehnung an IrfanView, das ja auch gerne einfach IView genannt wird.

Irgendwann wollte ich dem Projekt aber einen richtigen, eigenständigen Namen geben. Wie es sich für einen Nerd gehört, suchte ich zunächst in Der Herr der Ringe nach Inspiration. Genauer gesagt in der Elbensprache Sindarin. Doch sämtliche Begriffe, die mir passend erschienen, waren leider schon durch Firmen oder andere Projekte belegt.

Da ich ohnehin davon ausgehe, dass mein Projekt wohl nur einen überschaubaren Nutzerkreis finden wird – wenn überhaut –, dachte ich mir, dass es ruhig auch ein etwas obskurerer Name sein darf. Also blieb ich letztlich doch bei meinem ursprünglichen Ix – nur in einer verfremdeten, lautlichen Variante: üxz.

Sicherlich, theoretisch ist jeder eingeladen, sich in Open-Source-Projekte einzubringen. Aber gerade bei über viele Jahre gewachsenen Projekten mit eingeschworenen Entwicklergemeinschaften liegt zwischen der Möglichkeit, Kritik zu äußern oder Vorschläge einzubringen, und der tatsächlichen Chance, etwas zu verändern, oft eine gewaltige Kluft. Gerade dann, wenn man weder eine Historie eigener Programmierprojekte noch regelmäßige Beiträge zu anderen Projekten vorweisen kann – und obendrein die Vorstellungen der langjährigen Entwickler nicht teilt. Gegen festgefahrene Ansichten anzukommen und die Entwickler von Veränderungen zu überzeugen, wird dann nahezu unmöglich.

Wenn Nutzer selbst zu Entwicklern werden

Für solche Nutzer stellen Künstliche Intelligenz und Vibe- beziehungsweise AI-assisted Coding nun einen wichtigen Hebel dar. Denn auch Menschen wie ich, die nur begrenzte oder gar keine Programmierkenntnisse besitzen, werden dadurch ermächtigt und befähigt, eigene Anwendungen nach ihren Vorstellungen zu entwickeln. Sei es für sich selbst oder für andere Nutzer mit ähnlichen Ansprüchen. Sie sind nicht mehr darauf angewiesen, dass erfahrene Programmierer oder die Community ihre Wünsche erhören und entsprechende Programme oder Funktionen entwickeln.

Sicher: Nur weil jetzt jeder Software entwickeln kann, heißt das noch lange nicht, dass dabei immer etwas Gutes herauskommt. Eher im Gegenteil. Vieles dürfte unfertiger, fehleranfälliger und womöglich sogar unsicherer Code-Müll sein. Denn auch wenn KI einem inzwischen nahezu das gesamte Programmieren abnehmen kann, braucht es weiterhin klare Vorstellungen, kritisches Urteilsvermögen und nicht zuletzt Zeit und Durchhaltevermögen, um aus einer Idee ein wirklich gutes Stück Software zu machen.

Dennoch sehe ich in alldem eine große Chance. Besonders, aber nicht ausschließlich, für alternative Betriebssysteme wie Linux. Denn KI könnte deren Softwareangebot langfristig deutlich vielfältiger, zugänglicher und attraktiver machen. Fehlende Programme oder Funktionen müssen nicht mehr zwangsläufig ein Grund sein, einem Betriebssystem den Rücken zu kehren. Auch könnte KI die schon jetzt vorhandenen, für neue Nutzer aber oft schwer zugänglichen Möglichkeiten zur Anpassung von Linux noch einmal erweitern – und vor allem vereinfachen. Und Vibe-Coding könnte nicht nur neue Open-Source-Projekte anstoßen, sondern auch verändern, wie sich Menschen in bestehende Projekte einbringen. Denn wer sich bislang an einer umständlichen Bedienung oder fehlenden Funktion störte, konnte meist nur kritisieren oder Vorschläge machen und hoffen, dass die Entwickler diese aufgreifen.

Nun können auch Menschen ohne Programmierkenntnisse ihre Vorstellungen mit funktionierenden Prototypen demonstrieren. Statt nur zu erklären, was sie sich wünschen, können sie ganz konkret vorführen, wie sich eine Oberfläche zugänglicher gestalten oder ein Ablauf besser umsetzen ließe. Das heißt natürlich nicht, dass die Entwickler jeden Vorschlag übernehmen müssen. Aber aus abstrakter Kritik würden konkrete Ideen, die sich hands-on ausprobieren, diskutieren und vielleicht sogar direkt in bestehende Anwendungen integrieren ließen. Vielleicht ist diese Vorstellung etwas optimistisch, vielleicht auch etwas naiv. Aber ich glaube durchaus, dass sie zumindest in Ansätzen Wirklichkeit werden könnte.