Es gehört mittlerweile beim Verwenden von KI zum guten Ton, Probleme und Aufgaben mit Rechenleistung zu erschlagen. Ein Prompt, das größte verfügbare Modell, maximaler Kontext, fertig. Das funktioniert, solange jemand anderes die Rechenzentren betreibt und man bereit ist, seine Daten dorthin zu schicken.
Wer mit lokalen Modellen arbeitet, hat diesen Luxus schlicht nicht. Ein aktuelles 35B-Modell verzeiht keine schlampigen Prompts, keine überladenen Instruktionen, keine Aufgaben, die eigentlich drei Aufgaben sind, und auch keine Mehrdeutigkeiten. Und genau das ist keine Schwäche, sondern eine Chance für alle mit Erfahrung: Denn was dem Modell an Kapazität fehlt, lässt sich nicht durch Prompt Engineering herbeireden, wohl aber durch schlaue Architektur ersetzen. Aufgaben in lösbare Einheiten zerlegen, deterministisch den Kontext vorbereiten und das Modell nur dort einsetzen, wo es wirklich stark ist.
Das Ergebnis kann sich sehen lassen: Anwendungen, die mit einem kleinen Modell zuverlässiger und schneller laufen als der große Wurf mit dem Frontier-Modell. Dieser Artikel zeigt anhand eines konkreten Beispiels, wie das geht und warum klassisches Software-Handwerk in Zeiten der KI nicht entwertet wurde, sondern wertvoller ist denn je.
Gute Programmierer sind wertvoller denn je
Viele Programmierer haben sich vermutlich zu Beginn der Programmier-Agenten gedacht, dass sie nicht mehr gebraucht werden. Gelernt, studiert, viel Erfahrung und am Ende macht eine KI die Arbeit um Welten besser. Der Herausforderung gestellt, setzt sich aber immer mehr die Erkenntnis durch: Ja, die KI programmiert schneller, besser und sauberer, allerdings arbeitet auch sie nicht von Luft und Liebe, sie kostet Tokens via APIs und sie kann zwar das umsetzen, was der Anwender im Prompt anweist, allerdings fehlt vieles an Erfahrung und die KI kennt oft auch kein Halten. Unfassbar großes Wissen, gefühlt unendliche Möglichkeiten verleiten KI-Programmier-Agenten gerne dazu, völlig überzogene Lösungen für einfache Aufgaben zu bauen.
Folglich sind die ganz typischen architektonischen Programmierskills wertvoller denn je: wie gehe ich die Aufgabenstellung an und was vor allem die älteren Programmierer noch zu gut kennen: Wie gehe ich mit knappen Ressourcen um. Wie löse ich Problemstellungen, wenn ich nicht mit der Unendlichkeit planen kann. Früher war es der Speicher, oder andere knappe Ressourcen. Heute ist es bei lokaler, selbstgehosteter KI die Fähigkeit der Modelle.
Der One-Prompt-Shot als Gegenmodell
Abseits der klassischen Programmierer und Software-Entwickler gibt es ein Phänomen, wo versucht wird, mit nur einem Mega-Prompt ein Frontier-Modell zu füttern und eine komplett lauffähige Anwendung zu bekommen. Alles inklusive. Natürlich ist das beeindruckend und beweist, was möglich ist, wenn Rechenleistung in Hülle und Fülle zur Verfügung steht. Engineering ist das allerdings nicht. Es ist ungefähr so spannend wie Kirschkernweitspucken am Schulhof, unterhaltsam, aber wenig Wert. Vor allem bei Anwendungen, die viele Abfragen machen, ist diese Lösungskompetenz teuer erkauft. Keine Frage, es funktioniert, nur hunderte Abfragen pro Minute auf so ein Modell und der Tokenzähler freut sich über Umsatz.
Was Prompts können und was nicht
Der Schluss daraus, dass der Prompt alles löst, ist genau der falsche. Man könnte mit dem One-Prompt-Shot glauben, dass die Wahrheit immer im Prompt liegt. Es ist aber schlicht eine Eigenschaft der Spitzenmodelle und der Rechenleistung, dass diese einfach mit riesigen Prompts umgehen können und diese verarbeiten. Ein Prompt ist aber im Wesentlichen:
- Format
- Fokus
- Verhalten
Was ein Prompt nicht ist und kann: Fähigkeit. Man kann mit einem Prompt keine Fähigkeit zu einem Modell hinzufügen, die es nicht hat. Es ist also entscheidend zu wissen, was ein Modell kann und was nicht. Wo wir wieder beim Frontiermodell sind: Es kann gefühlt alles, daher stellt sich die Frage nicht. Bei allem darunter ist diese Frage die wesentliche Aufgabenstellung.
Aufmerksamkeit ist die knappe Ressource
Gerade bei lokal gehosteter KI ist Aufmerksamkeit eine knappe Ressource. Mega große Prompts mit vielen Anweisungen, Eventualitäten (um Fähigkeiten auszugleichen) und Instruktionen überdecken schnell mal die eigentliche Aufgabe und das Modell erscheint schwächer, als es eigentlich ist. Was passiert? Das kleinere Modell kann schlicht nicht so viel Information sinnvoll verarbeiten, es verliert ob der schieren Menge den Fokus und konzentriert sich auf Dinge, die man eigentlich nur erwähnt haben wollte, aber für die Lösung der Aufgabe keinen Wert liefern.
Praxisbeispiel: Vom Monolith-Prompt zum mehrstufigen Agenten
Etwas aus der Praxis. Die Aufgabe war es, einen Programmieragenten zu bauen. Der sollte, wie soll es auch anders sein, möglichst viel können, aber mit einem möglichst kleinen Modell auskommen. Es hat aber einfach nicht befriedigend funktioniert. Einfachste Aufgaben sind gescheitert. Obwohl klar war: Das Modell kann das grundsätzlich. Mit einem deutlich größeren Modell hat es allerdings funktioniert, man wäre verleitet, einfach das bessere Modell zu nehmen. Parallel einen einfachen Test-Stack gebaut, wo das Modell mit relativ wenigen Instruktionen an die Aufgabe herangeführt wurde und siehe da: Es hat gefühlt Wunder vollbracht. Was war passiert? Im ersten Anlauf wurden einfach alle Eventualitäten und Sonderfälle in den Instruktionen verpackt. Der System-Prompt war sehr umfangreich. Die Aufgabe waren 2-3 Sätze. Er hat beim ganzen Lesen, vereinfacht gesagt, vergessen, was er eigentlich tun soll.
Was war die Lösung? Die Aufgabe in Stufen zerlegen:
- Stufe 1: Klassifiziert die Aufgabe: Was ist eigentlich zu tun?
- Stufe 2: Je nach Aufgabe wird ein spezialisierter und knapper Prompt mit Instruktionen gewählt
Ergebnis: Der Agent konnte auf einmal die Aufgaben zuverlässig, schnell und sauber erledigen. Das Modell konnte es grundsätzlich, war aber schon mit ein paar Instruktionen komplett überladen. Eigentlich klassische Softwareentwicklung, allerdings ist man gerade beim Einsatz schnell verleitet zu sagen: Das LLM kann das einfach nicht. Es stimmt meist nicht.
Tipp: Immer wenn man glaubt, das Modell kann das nicht, einfach die wirklichen Basis-Instruktionen und die Aufgabe nehmen und direkt an das Modell schicken. Erst dann weiß man wirklich, ob das Modell es grundsätzlich kann.
Der doppelte Gewinn: Qualität und Durchsatz
Was bringt das kleinere Modell aber zusätzlich? Mehr Durchsatz (Tokens pro Sekunde) und mehr gleichzeitige Requests. Wesentlich für eine angenehme Benutzer-Erfahrung und das auf exakt der gleichen Hardware, nur durch sauberes Engineering. Jetzt möchte man meinen, dass mehr Requests an LLMs mehr kosten und damit ist es ja wieder weniger wirtschaftlich? Nein, denn ein Request an ein schwächeres Modell kostet in der Regel um ein Vielfaches weniger als an ein größeres. Gleichzeitig sind die kleineren Modelle um einen Faktor schneller, sodass zwei kleinere Requests fast immer deutlich schneller sind als ein Request an ein größeres Modell. Vor allem kann bei lokal gehosteter KI ein kleineres Modell auch mehr Requests parallel verarbeiten als ein größeres.
Der Nebeneffekt: Testbarkeit
Was es mit Mehrstufigkeit noch gibt: Flexibilität und Evaluierbarkeit. Ich kann Stufe 1 relativ leicht erweitern, den Agenten spezialisieren, ohne seine eigentliche Lösungskompetenz zu beschneiden. Natürlich ist auch das Thema enden wollend, weil zu viele spezialisierte Prompts auch nur Wiederholungen sind. Aber was noch spannender ist, man kann beim Testen jede Stufe extra betrachten. Wo passiert was, wo entsteht ein Problem, das man lösen möchte. Es wird so auch viel leichter handhabbar. Zusätzlich: Ändere ich einen Prompt von acht verschiedenen, mache ich bei den sieben anderen jedenfalls nichts kaputt. Bei einem Mega-Prompt kann es schon sein, dass auch alles andere in Mitleidenschaft gezogen wird. Die Architektur ist so nicht nur sauberer, sie ist auch viel weniger anfällig für Probleme bei Weiterentwicklung und Änderung.
Handwerk macht lokale KI möglich
Natürlich kann man nicht jede Anwendung komplett in Stufen zerlegen, aber viel mehr als man im ersten Nachdenken glaubt. Es ist generell gut, Systeme, die LLMs in der Ausführung nutzen, in kleinere Aufgaben zu zerlegen und damit die Systeme stabiler und testbarer zu machen. Also eine große Hoffnung für die Programmierer: Die Tugenden der alten Schule gelten immer noch, es ist immer noch ein Bauen rund um knappe Ressourcen. Eigentlich das, was dieses Handwerk seit fast 50 Jahren tagtäglich macht. Wieder mal sind es die Programmierer mit viel Erfahrung, die gefragt sind und die Anwendungen der Zukunft bauen.