LLM-First oder Code-First? Wo Intelligenz in produktiven KI-Systemen hingehört

Wie man entscheidet, was das Modell übernehmen soll, was Ihr Code übernehmen soll und wie man beides verbindet.

Vor ein paar Jahren sah die Architektur einer KI-Anwendung so aus: einen Prompt an ein großes Sprachmodell senden -> eine Antwort erhalten -> sie dem Nutzer anzeigen. Das ist heute nicht mehr die ganze Geschichte. Die Modelle werden gebeten, Absichten zu interpretieren, Informationen abzurufen, Werkzeuge auszuwählen, APIs aufzurufen, Pläne zu erstellen und mehrstufige Workflows auszuführen.

Diese Verschiebung hat das Feld in zwei Bereiche aufgeteilt – LLM-First oder Code-First

In einer LLM-First-Architektur steht das Modell im Zentrum und entscheidet, was als Nächstes geschieht. Es liest die Anfrage, wählt ein Werkzeug, bestimmt die Reihenfolge der Schritte, prüft Zwischenergebnisse und ändert den Kurs, wenn es nötig ist.

In einer Code-First-Architektur bleibt die Software/der Code für die Sequenzierung, Geschäftsregeln, Validierung, Berechtigungen und Ausführung verantwortlich. Das LLM ist hier wie ein Spezialist, den der Code aufruft, wenn Sprachverständnis oder -generierung benötigt wird.

Die Leute streiten gern darüber, was besser ist. Ich denke, das ist das falsche Argument. Die bessere Frage ist, wo jede Art von Intelligenz hingehört. Die stärksten Produktionssysteme, die ich gesehen habe, sind selten rein das eine oder das andere. Sie kombinieren probabilistisches Schließen mit deterministischer Steuerung und tun dies bewusst.

Warum LLM-First so attraktiv ist

Traditionelle Software funktioniert hervorragend, wenn man die Anforderungen klar definieren kann. Zum Beispiel wählt ein Nutzer ein Produkt, gibt einen Betrag ein und führt eine Zahlung aus. Man definiert die zulässigen Zustände, die Validierungsregeln, die Fehlersituationen und die Transaktionsfolge im Code. Fertig.

Natürliche Sprache kooperiert nicht so. Stellen Sie sich vor, ein Nutzer tippt: “Finde die Transaktionen, die ungewöhnlich aussehen, erkläre, was passiert ist, und sag mir, was ich zuerst untersuchen sollte.”

Es gibt keinen festen Pfad für diese Anfrage. Das System muss entscheiden, was “ungewöhnlich” bedeutet, herausfinden, welche Daten relevant sind, eventuell mehrere Werkzeuge aufrufen, die Antwort abwägen und eine Erklärung schreiben, die ein Mensch nutzen kann. Kein Ingenieurteam/keine No‑Code‑Lösung wird jede Formulierung und jede Kombination von Anfragen im Voraus voraussehen.

Hier spielt ein LLM eine zentrale Rolle, indem es als flexible Denk‑Schicht zwischen menschlicher Sprache und Ihren deterministischen Diensten fungiert. Deshalb erhalten Agenten so viel Aufmerksamkeit. Google Cloud’s Leitfaden zur agentischen KI-Architektur beschreibt einen Agenten als eine Anwendung, bei der ein KI‑Modell als Denk‑Engine fungiert, während Werkzeuge ihm den Zugriff auf externe Systeme und Daten ermöglichen.

Anthropic’s Erstellung effektiver KI-Agenten Leitfaden macht eine Unterscheidung, zu der ich immer wieder zurückkehre. In einem Arbeitsablauf, Modelle und Werkzeuge folgen Pfaden, die Ihr Code definiert. In einem Agent, das LLM leitet seinen eigenen Prozess und entscheidet, wie es seine Werkzeuge nutzt. Der gleiche Leitfaden empfiehlt, mit der einfachsten Architektur zu beginnen, die das Problem löst, anstatt durch Reflexion agentische Komplexität hinzuzufügen. Ich würde diesen Rat zweimal unterstreichen.

Die Grenzen von „Das Modell entscheiden lassen“

Ein Modell kann darüber nachdenken, was geschehen sollte. Denken ist nicht dasselbe wie das Durchsetzen einer Regel.

Nehmen wir zum Beispiel einen Finanz‑Workflow. Ein LLM kann sehr gut verstehen “sende denselben Betrag, den ich letzten Monat an denselben Lieferanten geschickt habe”. Aber sollte es auch entscheiden, ob die Überweisung autorisiert ist, regulatorische Grenzen berechnen, Kontoinhaberschaft prüfen, eine Sicherheitsrichtlinie übersteuern und die Transaktion ausführen?

Wahrscheinlich nicht. Diese Aufgaben sind deterministisch, testbar, prüfbar und durchsetzbar, und genau darin liegt die Stärke herkömmlicher Software. Das Risiko steigt, wenn Modelle Zugriff auf Werkzeuge erhalten. OWASP’s Leitfaden zur generativen KI-Sicherheit kennzeichnet übermäßige Handlungsfähigkeit als ein erhebliches Risiko: einem LLM‑basierten System mehr Funktionalität, Berechtigungen oder Autonomie zu geben, als seine Aufgabe erfordert. Eine seltsame oder manipulierte Modellausgabe ist eine Sache, wenn sie nur Text erzeugt. Es ist eine viel größere Sache, wenn das Modell in der realen Welt handeln kann.

Das bedeutet nicht, dass Modelle niemals Aktionen ausführen dürfen. Es bedeutet, dass die Autonomie von Modellen durch deterministische Autorität begrenzt werden sollte.

Code-First bleibt wichtig

Da sich KI so schnell entwickelt, ist es leicht zu denken, dass konventionelles Engineering aus der Mode gekommen ist. Ich würde das Gegenteil behaupten. KI macht gute deterministische Systeme wichtiger, nicht weniger.

Code ist nach wie vor die richtige Wahl, wann immer eine Aufgabe exakte Wiederholbarkeit erfordert. Authentifizierung ist das einfachste Beispiel. Ein Modell sollte nicht “überlegen”, ob jemand Administratorrechte hat. Ihre Anwendung sollte ein autoritatives Identitäts‑ und Zugriffs‑Management‑System abfragen. Gleiches gilt für Geldberechnungen, Berechtigungsprüfungen, Datenvalidierung, regulatorische Vorgaben, Transaktionslimits, Schema‑Validierung und alles Irreversible. Diese benötigen explizite Verträge, nicht bloße Schätzungen.

Dies entspricht einem breiteren Governance-Denken. NIST AI Risk Management Framework fordert Organisationen auf, KI-Risiken über Design, Entwicklung, Bereitstellung und Nutzung hinweg zu managen. Generative AI Profile fügt hinzu, dass generative Systeme je nach dem damit verbundenen Risiko zusätzliche Aufsicht, Dokumentation, Überprüfung und Kontrollen benötigen können.

Ich finde es hilfreich, jede Designentscheidung in zwei Fragen zu unterteilen:

Was sollte passieren?

und

Was darf passieren?

Ein LLM kann oft beim Ersten helfen. Deterministische Systeme sollten in der Regel das Zweite übernehmen.

Das Hybrid-Muster: Probabilistisch argumentieren, deterministisch ausführen

Für die meisten Unternehmensanwendungen ist die praktische Lösung ein Hybrid. Das LLM fungiert als Interpretations‑ und Argumentationsschicht. Deterministische Dienste fungieren als Ausführungs‑ und Durchsetzungsschicht.

Ein Beispiel: Angenommen, ein KI‑Assistent unterstützt Entwickler beim Aufsetzen temporärer API‑Testumgebungen, und ein Entwickler tippt: “Erstelle mir eine Sandbox für den Kunden‑Onboarding‑Workflow.”

Das LLM kann das interpretieren, ermitteln, welcher Workflow wahrscheinlich gemeint ist, die Dokumentation lesen und vorschlagen, welche APIs wahrscheinlich relevant sind. Die eigentliche Erstellung der Umgebung sollte jedoch nicht von frei formuliertem generiertem Text abhängen. Code kann bestätigen, dass die angeforderten APIs existieren, ihre Verträge validieren, die Autorisierung prüfen, Ressourcenlimits durchsetzen, eine genehmigte Konfiguration erzeugen und die Bereitstellung ausführen.

Die grobe Aufteilung sieht folgendermaßen aus:

• Das LLM: verstehen, argumentieren, klassifizieren, vorschlagen, zusammenfassen.
• Der Code: validieren, autorisieren, berechnen, persistieren, durchsetzen, ausführen.

Jede Seite erledigt die Aufgaben, für die sie am besten geeignet ist, und keine wird gebeten, die Stärken der anderen vorzutäuschen.

Grenzen werden wichtiger, je mächtiger Agenten werden

Diese Trennung wird wichtiger, wenn wir von Assistenten zu Agenten übergehen. Ein Assistent, der eine falsche Antwort gibt, verärgert jemanden. Ein Agent mit Schreibzugriff auf die Produktion kann ein viel größeres Chaos verursachen.

Die Lösung besteht nicht unbedingt darin, Autonomie zu entfernen. Es geht darum, Autonomie schrittweise hinzuzufügen, während explizite Kontrollpunkte erhalten bleiben. Google‑Leitfaden für Multi‑Agent‑Systeme empfiehlt, dynamisches KI‑Verhalten mit deterministischen Sicherheitskontrollen, Beobachtbarkeit, klar definierter Autonomie und menschlicher Aufsicht für geschäftskritische Szenarien zu koppeln.

Menschliche Genehmigung kann auch direkt in den Arbeitsablauf eingebaut werden, anstatt ein informelles Sicherheitsnetz zu sein. Microsoft’s agent framework documentation unterstützt zum Beispiel Werkzeugaufrufe, die pausieren, bis eine Person die angeforderte Operation ausdrücklich genehmigt.

Das Prinzip ist einfach: Je höher die Konsequenzen einer Aktion, desto stärker sollten die deterministischen Kontrollen darum herum sein.

Fünf Fragen, die man stellen sollte, bevor man einer LLM eine Aufgabe überträgt

Wenn ich entscheide, ob eine Komponente LLM‑first oder code‑first sein sollte, gehe ich diese Punkte durch:

1. Hat die Aufgabe eine eindeutig richtige Antwort? Falls ja, sollte man zu deterministischem Code tendieren. Steuerberechnungen, Berechtigungen und Schema‑Validierung sollten sich nicht ändern, weil ein Modell sie heute anders interpretiert.
2. Umfasst sie mehrdeutige Sprache oder unstrukturierte Informationen? Falls ja, kann ein LLM echten Mehrwert bieten.
3. Was passiert, wenn das Modell einen Fehler macht? Die passende Architektur für eine Sitzungszusammenfassung unterscheidet sich stark von der passenden Architektur für die Initiierung einer Zahlung.
4. Kann die Ausgabe unabhängig validiert werden? LLM‑generierte Pläne werden deutlich sicherer, wenn deterministische Regeln die resultierende Aktion prüfen, bevor sie ausgeführt wird.
5. Benötigt das wirklich einen Agenten? Wenn Sie die Schritte bereits kennen, ist ein regulärer Workflow mit einigen gezielten LLM‑Aufrufen in der Regel einfacher, günstiger, leichter zu testen und zu betreiben.

Diese letzte Frage verdient besondere Aufmerksamkeit. Agenten sind genau deshalb mächtig, weil sie Situationen bewältigen können, in denen man nicht jeden Schritt vorhersagen kann. Aber wenn Sie kann die Schritte vorhersehen, das Umwandeln in ein offenes Argumentationsproblem führt oft zu Variabilität, ohne Intelligenz hinzuzufügen.

Zuverlässigkeit ist eine architektonische Eigenschaft, nicht ein Prompt

Viele Teams versuchen zunächst, die Zuverlässigkeit fast ausschließlich durch Prompt‑Engineering zu verbessern. Prompts sind wichtig, aber sie können die gesamte Last nicht tragen.

Ein Produktionssystem sollte davon ausgehen, dass Modellausgaben manchmal unvollständig, fehlerhaft, unerwartet oder einfach falsch sind. Die OWASP Top 10 für LLM‑Anwendungen listet Risiken wie Prompt‑Injection und unsachgemäße Ausgabe‑Verarbeitung, was eine zentrale Gewohnheit bestärkt: Modellausgaben als nicht vertrauenswürdige Eingaben für nachgelagerte Systeme behandeln, nicht als Anweisungen, die automatisch ausgeführt werden.

Das ändert die Frage, die Sie stellen. Statt „Wie schreibe ich ein Prompt, das das Modell immer die Regel befolgen lässt?“, fragen Sie: „Wie entwerfe ich das System, sodass die Regel selbst dann nicht gebrochen werden kann, wenn das Modell einen Fehler macht?“

Das ist ein Problem der Softwarearchitektur, nicht ein Prompt‑Problem. Ein Prompt kann einem Agenten sagen, keine unautorisierte Aktion auszuführen. Ein Autorisierungsservice kann dies tatsächlich verhindern. Diese beiden Kontrollen sind nicht gleichwertig.

Jenseits der Debatte: Intent‑First‑Systeme

Wenn ich darüber nachdenke, bin ich zu der Überzeugung gelangt, dass die Debatte LLM‑first versus code‑first auf eine dritte Idee hinausläuft: Intent‑First-Architektur.

In einem Intent‑First‑System beginnt die Anwendung damit, zu verstehen, was der Nutzer erreichen möchte. Dort ist ein LLM am wertvollsten, weil Menschen selten exakt angeben, was sie wollen. Von dort aus wandelt das System diese Unschärfe schrittweise in strukturierte, deterministische Vorgänge um.

Eine Anfrage wie „Hilf mir, das Zahlungsproblem des Kunden zu lösen“ könnte zu einer Pipeline werden: Intent verstehen, Transaktion abrufen, Fehlgrund identifizieren, eine Lösung empfehlen, Genehmigung anfordern, die genehmigte Operation ausführen.

Einige dieser Phasen profitieren vom Reasoning des Sprachmodells. Andere sollten feste Services sein. Die Architektur wird nicht dadurch definiert, ob KI oder Code „gewinnt“. Sie wird dadurch definiert, wo Unsicherheit tolerierbar ist.

Fazit

Während sich die Modelle verbessern, wird es verlockend sein, ihnen die Kontrolle über immer größere Teile des Stacks zu geben. Manchmal wird das die richtige Entscheidung sein. In anderen Systemen wird das ausgeklügeltste Design dasjenige sein, das dem Modell bewusst weniger Autorität einräumt.

Production‑AI‑Engineering dreht sich letztlich darum, Intelligenz an der richtigen Grenze zu platzieren. Setzen Sie Sprachmodelle dort ein, wo Interpretation, Reasoning, Synthese und Anpassung Mehrwert schaffen. Verwenden Sie deterministische Software dort, wo Konsistenz, Autorisierung, Präzision und Durchsetzung wichtig sind. Verbinden Sie dann beides über enge, beobachtbare, gut getestete Schnittstellen.

Die Zukunft von Enterprise‑AI wird wahrscheinlich weder rein LLM‑first noch rein code‑first sein. Es ist LLM dort, wo Unsicherheit Intelligenz erfordert, und Code dort, wo Sicherheit Kontrolle verlangt.

Diese Unterscheidung könnte weitaus wichtiger sein als die Wahl des Modells.