Habt ihr schon mal etwas mit KI gebaut und euch danach gefragt, ob es wirklich taugt?
Von der Ahnenforschung zu Vibe Coding
Bei meiner Ahnenforschung suche ich gezielt nach Menschen, zu denen mir Daten fehlen, und nach Informationen zu denen, die ich schon kenne, unter anderem in alten Zeitungen. Mit der Zeit sammeln sich so viele Personendatenblätter an, dass ich kaum noch den Überblick behalte. Ein Wiki mit all den Verbindungen und Sortierfunktionen, dachte ich, macht das einfacher. Das selbst zu programmieren hätte mich viel Zeit gekostet, und da ich ohnehin viel mit KI arbeite und experimentiere, dachte ich: Probier ich es mal mit Claude Code.

Zwischen den Stühlen: Muss man für Vibe Coding programmieren können?
Beim Vibe Coding, dem Entwickeln von Software mit KI, sind mir auf LinkedIn zwei Lager aufgefallen. Die einen sagen: Voll easy, das kann jeder. Die anderen: Geht gar nicht, nicht ohne Programmierausbildung. Ich sitze dazwischen, und genau deshalb habe ich für die loscon, die lernOS Convention, einen Vortrag dazu vorbereitet. Programmieren muss man dafür nicht zwingend können, aber man braucht ein Gespür dafür, wie man Software gut beschreibt. Es hilft, ihre Grammatik zu kennen, die Struktur von Systemen und ein paar Prinzipien. Die Grenze verläuft für mich nicht zwischen Laien und Profis, sondern zwischen denen, die wissen, was sie der KI mitgeben müssen, und denen, die es nicht wissen.
Drei Werkzeuge: Divide and Conquer, SMART und SOLID
Zwei Fragen begleiten mich dabei. Wie beschreibe ich etwas, für das ich noch keine Sprache habe? Und woran erkenne ich, ob das Ergebnis nicht nur gut aussieht, sondern wirklich gut ist? Drei Werkzeuge helfen mir, das zu beantworten.
Das erste ist Divide and Conquer: erst selbst zerlegen. Beim Wiki habe ich aufgeschrieben, was es können soll, mit Verben, weil die das Vorhaben greifbar machen. Daten erfassen, filtern, auswerten, darstellen. Dieses Zerlegen empfehle ich überhaupt im Umgang mit KI, nicht nur beim Programmieren. Erst überlegen:
- Welche Schritte braucht die Aufgabe?
- Bei welchen kann mir die KI helfen?
- Und bei welchen will ich ihre Unterstützung wirklich?
Und dann bleibe ich im Dialog und frage auch mal: Habe ich vielleicht etwas übersehen?
Das zweite sind die SMART-Kriterien, also die Bedingungen benennen.
- Auf welchem System soll es laufen?
- Wie aktuell muss dieser Stand sein?
- Für wen ist es gedacht?
- Welche Funktionen sind wirklich wichtig?
Den aktuellen Wissensstand der Modelle unterschätzt man leicht: Bei einem anderen Projekt ging die KI von einer älteren Betriebssystem-Version aus, und ich musste ihr erst den Weg zu den fehlenden Informationen bahnen. Auch Anforderungen wie Barrierefreiheit gehören dazu: Was ich nicht ausdrücklich nenne, interpretiert die KI frei.
Das dritte sind die SOLID-Prinzipien aus der Softwareentwicklung. Sie sorgen dafür, dass sich das Ergebnis nicht nur heute nutzen, sondern später auch erweitern und pflegen lässt, ohne dass eine Änderung kaputt macht, was schon lief. Im Detail verstehen muss man sie beim Vibe Coden nicht, aber benennen können hilft. Ich sage der KI zu Beginn, sie soll sich daran halten, und erinnere sie gelegentlich daran. Beim Wiki habe ich auch nachgefragt: „Hast du das solide eingerichtet, ordentlich kommentiert?“ Die Antwort war ehrlich „nach SOLID ja, die Kommentare aber zu dünn“.

Woran erkenne ich nun, ob das KI-Ergebnis gut ist?
Das ist der eigentliche Punkt: Alles, was ich nicht verlange, lässt die KI weg. Sie kennt Prinzipien zu Sicherheit, Wartbarkeit oder Barrierefreiheit, wendet sie aber nur auf Ansage an.
Also bleibe ich im Dialog, lasse mir erst einen Vorschlag machen, statt sofort umsetzen zu lassen, und überlege mir eigene Testfälle. Dabei entsteht auch Neues: Als der erste Wurf stand und mir gefiel, dachte ich, eine grafische Übersicht oder ein paar Wortwolken könnten das anschaulicher machen. So kam das erst nach und nach dazu. Ich lese nicht jede Codezeile. Ich prüfe, ob das Ergebnis stimmt und die Begründung trägt.
Das ersetzt keine professionelle Softwareentwicklung. Aber für ein Werkzeug, dessen Ergebnis ich selbst beurteilen kann, komme ich erstaunlich weit. Nicht der Code ist die eigentliche Arbeit, sondern die klare Anforderung und das kritische Prüfen, ob das Ergebnis taugt.
Vibe Coding in der Lehre: das Vision Pro Lab
Für mich war der Vortrag zugleich Vorbereitung: Im kommenden Semester betreue ich an der TH Wildau das interdisziplinäre Modul „Vision Pro Lab: XR-Projekt“. Studierende verschiedener Fächer entwickeln dort im Team eigene XR-Anwendungen für die Apple Vision Pro, mit dem Design-Thinking-Ansatz von der Idee bis zum lauffähigen Prototyp. Egal ob mit Code oder Konzept: Genau dieses Beschreiben, Beurteilen und Dokumentieren macht sie zu XR-Creator:innen, auch ohne tiefe Programmierkenntnisse.
Die loscon-Sessions wurden aufgezeichnet. Die Videos erscheinen nach und nach in dieser Playlist: https://www.youtube.com/playlist?list=PLYWwp_NunSxU
