Wie nutze ich eigentlich KI aka eine LLM?
Okay, bevor wir anfangen... ein Hinweis vorab. Weil es mich wirklich ankotzt. Ehrlich. Jedes Mal aufs Neue.
Es gibt keine uns zugängliche KI / AI / AGI. Noch nicht!
Was ihr nutzt, was ich nutze, was alle nutzen – das sind Large Language Models, kurz LLMs. Und das ist etwas vollständig anderes.
Danke. Musste raus. ;-)
Der Einsatz von LLMs durch mich – und für mich
Ich nutze – wegen meiner Parkinsonerkrankung – privat immer häufiger STT (Speech to Text). In guten Phasen, wie im Moment, tippe ich noch so viel wie ich kann. Der Rest kommt dann nach und nach von einer LLM.
So gebe ich ihr zum Beispiel solche langweiligen Routine-Aufgaben:
„Erstelle mir eine grafische Darstellung von X im Verhältnis zu Y mit folgenden Daten und folgender Visualisierungsmethodik."
Sprich: Dinge, die teilweise gut Zeit fressen, aber auch von einer LLM solide gelöst werden können.
Datenkorrelationen und Visualisierungen sind dabei das A und O für mich.
Vibe-Coding
Zusätzlich lasse ich extrem viel von LLMs wie Claude und Gemini vibe-coden.
Ja, grusselig. Aber so viel einfacher wird es dadurch auch nicht, das will ich klar sagen.
Die Aufgaben verlagern sich nur. Der Code Monkey ist jetzt eine LLM. Man selbst konzentriert sich verstärkt auf Design, Prompts und deren Einhaltung. Das was dann dabei rauskommt... da halte ich die Finger drauf. Und übergebe es nur in bestimmten Fällen an eine Judge LLM.
Um was geht es dabei?
TESTING!
Das was alle Entwickler hassen wie die Pest. Nur eines ist noch schlimmer – Dokumentieren. Was ich im Übrigen ebenfalls die LLM machen lasse. ;-)
Wie gehe ich dabei vor?
Grundsätzlich läuft bei mir im Hintergrund immer ein umfangreiches Debugging-Protokoll mit. Eine LLM beobachtet das aktiv, greift sich die Fehler raus, bietet mir Lösungen im Planungsmodus an – die ich dann ggf. nachjustiere oder einfach bestätige. Danach patcht sie den Code live im laufenden Docker-Container.
Das führt zu sehr kurzen Turnaround-Zeiten bei Bugfixes. Was anstrengend ist. Sehr anstrengend, auf Dauer.
Und konkret? Ein Abend mit YADS...
Ich bin seit mehreren Stunden daran, das eigentlich relativ einfache Setup-Tool für YADS zu vibe-coden.
Jedes Mal wenn man denkt: „Jetzt läuft das Ding endlich sauber" – findet man im nächsten Test einen weiteren Edge Case. Und da ich keinen Schund abliefern will, werfe ich der LLM den Fehler, die Änderung oder das neue Feature als Prompt rüber, sehe mir den Plan an, justiere nach... und dann läuft der nächste Zyklus.
In der Zeit, in der die LLM die Anpassungen durchführt, prüfe ich parallel die Ergebnisse vom vorherigen Testlauf. Das ist fast schon Fließbandarbeit. Nur halt... mein Fließband. ;-)
Ablauf eines Tests – oder: Wie ein Testlauf aussieht
Und damit das alles nicht abstrakt bleibt – hier ein echter Testlauf von heute Abend. 61 von 63 Tests grün, 2 Timeouts auf /queue und /workers (Docker Problem im Test-Container... seufz).
Der Log sieht in etwa so aus:
[21:34:07] Initialisiere GUI-Tests...
[21:34:07] 💻 Local mode — running GUI tests against http://localhost:8085
[21:34:08] ▶ YADS GUI Test Runner v1.51.5 — target: http://localhost:8085
[21:34:08] ✅ Local mode — skipping Dana startup.
[21:34:08] ▶ Waiting for http://localhost:8085 to be ready (timeout 120s)...
[21:34:08] ✅ Target URL is up! (0s)
[21:34:08] ▶ PRE-STEP: Login
[21:34:12] ⚠️ CSRF field not injected by JS (yet).
[21:34:13] ⚠️ Force password change detected — updating...
[21:34:15] ✅ Password changed.
[21:34:15] ✅ Login successful!
[21:34:15] ✅ 🌙 Dark mode activated via localStorage.
[21:34:16] ▶ Scanning sidebar for navigation links...
[21:34:16] ✅ Found 63 pages to test.
[21:34:17] [1/63] ✅ /
[21:34:20] [2/63] ✅ /analytics
[21:34:22] [3/63] ✅ /analytics/external-links
[21:34:25] [4/63] ✅ /analytics/dead-links
...
[21:35:10] [12/63] ❌ /queue — Timeout 30000ms exceeded.
[21:36:00] [14/63] ❌ /workers — Timeout 30000ms exceeded.
...
[21:37:51] [63/63] ✅ /profile
61 von 63. Ich nehm's.
Die zwei Timeouts? Docker-Problem im Test-Container – docker-Binary fehlte einfach im Container. Classic. Das wird der nächste Prompt. ;-)
Warum überhaupt Screenshots?
Gute Frage. Der GUI-Test-Runner macht von jeder getesteten Seite automatisch einen Screenshot. Warum?
Weil Logs lügen. Ein ✅ OK im Log sagt mir, dass die Seite geladen hat und keine Exception geflogen ist. Aber ob die Seite auch vernünftig aussieht? Ob da nicht irgendwo ein Element fehlt, ein Layout bricht oder ein Button ins Nirgendwo führt? Das sagt mir nur ein Bild.
Das ist der optische Smoke-Test on top. Kein Ersatz für echte visuelle Regression-Tests, aber deutlich besser als gar nichts.
Und so sieht das dann aus – hier die erfolgreichen Seiten aus dem Testlauf von heute Abend:
Und für die zwei Kandidaten die auf die Nase gefallen sind:
/queue und /workers. Timeout-Bildschirm – docker-Binary fehlte im Test-Container. Classic. ;-)Fazit? Gibt's nicht. Nur Ehrlichkeit.
LLMs sind kein Wundermittel. Aber sie sind ein brutales Werkzeug, wenn man weiß wie man damit umgeht. Und wenn man – wie ich – körperliche Einschränkungen hat, sind sie manchmal schlicht... unverzichtbar.
Der Code kommt von der LLM. Die Entscheidungen kommen von mir.
Tja... so läuft das hier. ;-)
Transparency Note: Dieser Post entstand heute Abend während laufender YADS-Testläufe. Struktur und Feinschliff von Antigravity (Gemini), Inhalt, Einsatz und persönliche Erfahrungen sind 100% Marco.