Kürzlich hatte ich eine gute Diskussion zum Einsatz von LLMs in der Software-Entwicklung, die eine gewisse Differenzierung erlaubte. Derzeit werden Diskussionen rund um den Einsatz sehr schwarz-weiß geführt – ich komme von der AI-kritischen Seite und Argumente rund um Ressourcen-Verbrauch, Finanz-Bubble, Ausbeutung, Sicherheit, Psychosen, Slop sind hiermit acknowledged, werden in der folgenden Betrachtung, aber nicht noch einmal aufgegriffen.
Im Einsatz von LLMs unterscheide ich zwischen zwei Arten: Ist das LLM eine Funktion innerhalb eines größeren Prozesses oder steuert das LLM diesen Prozess. Macht du Bildbearbeitung und nutzt in deiner Software ein Feature zum sauberen Markieren eines Object, ist es Ersteres. Du könntest es ohne AI machen, ist aber mehr administrativer Aufwand, der kreative Prozess liegt bei mir. Du hast eine Automatisierung, die deterministische Schritte geht und ein Schritt ist ein Prompt zu einem LLM, ist ebenfalls Ersteres, solange das LLM eine einzelne klare Funktion, zB eine Qualifizierung erfüllt.
Zweiterem entspricht der Ansatz “mach mir alles”, wenn der kreative Prozess an sich an das LLM abgegeben wird. The Oatmeal hat das schön zusammengefasst.
Ähnlich sehe ich es auch bei Software-Entwicklung. Du kannst einen sehr gezielten LLM Einsatz haben, der an den richtigen Stellen sehr hilfreich ist und eine gute Ergänzung ist. Für mich ist dass, wenn ich komplexen Code debuggen (stell dir 5x verschachtelte SQL vor und frag nicht woher die kommen) und das LLM erstaunlich oft ihr beschriebene Fehler auflösen kann. Meine Erfolge mit Coding Agents sind dagegen gering, was hauptsächlich daran liegt, dass ich sie mit lokalen Open-Source LLMs und zu schwacher Hardware betrieben habe.
Ich war letztes Jahr zu einem n8n-Meetup. N8n nutze ich öfters, wenn es darum geht schnell Automatisierungen zu prototypen. Umgeben war ich von Marketing-Personen und Product-Manager*Innen, die stolz ihre selbst gebauten Systeme zeigten. Automatisierungen wild zusammen geklickt aus 5 Services ohne Rücksicht auf Performance, Datenschutz, Skalierbarkeit und Stabilität. Aber sie waren stolz drauf und es erfüllte für sie eine Aufgabe, die vorher nicht erfüllt werden konnte. Was in der Luft schwang, war eine Abwertung der eigenen IT-Abteilung. Du hörtest den Frust von Menschen, die zu oft “nein, machen wir nicht”, “nein, keine Ressourcen” oder “wir setzen es aufs Backlog, du hast es in 4 Monaten” zu hören bekommen haben. Ihnen ist egal, dass ihre AI-Lösungen alle paar Wochen zusammenbrechen und ein Datenschutz-Albtraum sind.
Im Product Management gibt es eine Organisationsmethode von Flughöhen (Flight levels). Du kannst Initiativen in verschiedenen Flughöhen haben, die alle hohe Prioritäten genießen, aber unterschiedliche Zeithorizonte haben.
Die Quickwins auf niedriger Flughöhe sind schnell eingeführt, lassen sich schnell ändern und können schnell wieder ersetzt werden.
In der mittleren Flughöhe sind Themen mit Blick auf das nächste Projekt, die über die nächsten Wochen/Monate relevant werden.
Die strategischen Themen sind oberste Flughöhe und die dicken Bretter. Diese ändern sich selten und haben einen langen Zeithorizont.
Software kann ebenfalls in diese Flughöhen eingeteilt werden und je nach Höhe kommen unterschiedliche Anforderungen.
Dein Einmal-Script von der AI geschrieben, dass du nicht wieder verwenden willst ist ein Quickwin vorausgesetzt es ist bei unkritischen Dingen im Einsatz.
Die vibe-gecodete Anwendung ist eine nächste Flughöhe mit überschaubarer Lebensdauer aber praktischem Nutzen. Es wird oft kaputtgehen, aber das macht nichts. Es hilft dir, niemand anderen und du kannst die Verantwortung für dich tragen.
Die nächste Höhe ist Software, die mit Zugriff auf das Lethal Trifectar – Private Daten (Kreditkarte), Zugriff ins Internet(kann Daten zu Webseiten schicken) und Zugriff durch Unbefugte (LLM führt Inhalt einer E-Mail aus) – hat. Hier erreichen wir den Punkt an dem Vibe-Coding nicht mehr empfehlenswert ist und wo LLM-Einsatz nur noch in isolierten einzelnen Funktionen sinnvoll sein könnte.
In der höchsten Flughöhe ist die Software das Zentrum deines Businessmodells. Soll sie für Jahre stabil und skalierbar sein, so halte LLMs davon fern. Hier spielen Architektur, Software-Design, Performance und langfristiges Komplexitäts-Management eine große Rolle und können hier nicht LLMs nicht mithalten.
Nach diesen Flightleveln bewerte ich für mich, wann welcher AI-Einsatz tolerabel ist.
Kenne deine Werkzeuge, deine Risiken und wann du einen Bogen drum herum machst.