Was diese Woche passiert ist
Am 7. Mai ist auf Hacker News ein Beitrag mit dem Titel „Agents need control flow, not more prompts” (sinngemäß: „Agenten brauchen Steuerlogik, keine zusätzlichen Prompts”) in die Top-Liste gewandert: 406 Punkte, über 200 Kommentare. Der Autor argumentiert, dass die meisten produktiven Agenten-Systeme nicht durch ausgefeiltere Prompts besser werden, sondern durch klassische Software-Architektur drumherum: Bedingungen, Schleifen, Retries, State-Machines, Validierung.
Die Diskussion in den Kommentaren fällt ungewöhnlich einig aus — und das ist im HN-Kontext bemerkenswert. Praktiker aus Anbau und Betrieb von LLM-Anwendungen bestätigen reihenweise: Wer Agenten nur mit längeren Systemprompts oder mehr Tools füttert, baut Systeme, die zu 70% funktionieren und zu 30% unvorhersehbar sind. Genau die 30% sind der Grund, warum viele Pilotprojekte nie in Produktion gehen.
Warum das jetzt für KMU zählt
In der österreichischen Beratungspraxis sehe ich seit etwa einem Jahr ein Muster, das exakt zum HN-Artikel passt: Ein Unternehmen startet mit einem GPT- oder Claude-basierten Agenten, der eine bestimmte Aufgabe lösen soll — Angebote vorbereiten, Kundenanfragen klassifizieren, Rechnungen prüfen. In den ersten Demos läuft alles gut. Dann kommt der Realbetrieb, und plötzlich häufen sich Fehler: Der Agent ruft Tools in der falschen Reihenfolge auf, vergisst Zwischenergebnisse, erzeugt halluzinierte Felder oder läuft in Endlosschleifen.
Die typische erste Reaktion: Man verlängert den Systemprompt. Aus 200 Wörtern werden 800, dann 1.500. Es werden Beispiele eingefügt, Verbote, „Du MUSST...”-Anweisungen in Großbuchstaben. Das hilft kurz — und macht das System mittelfristig schlechter, weil jede Änderung neue Nebenwirkungen produziert.
Aus meiner Sicht ist genau das die Stelle, an der viele KMU-Projekte falsch abbiegen. Ein LLM ist eine Komponente, kein Programm. Wer ihm die gesamte Steuerlogik überlässt, verlagert die Verantwortung an die unzuverlässigste Stelle des Systems.
Konkret: Wenn ein Agent für eine Angebotserstellung die Schritte „Kundendaten holen → Produktverfügbarkeit prüfen → Preis berechnen → Dokument generieren → ins CRM speichern” durchlaufen soll, dann gehören diese Schritte in normalen Code. Das LLM macht innerhalb jedes Schrittes das, was es gut kann — Texte verstehen, klassifizieren, formulieren. Was es nicht macht: entscheiden, ob Schritt 3 vor Schritt 2 ausgeführt werden darf.
Das technische Argument in einem Satz
LLMs sind exzellent darin, unstrukturierten Input in strukturierten Output zu verwandeln. Sie sind schlecht darin, einen mehrstufigen Prozess zuverlässig zu orchestrieren. Steuerlogik gehört in deterministischen Code; Sprachverstehen gehört ins Modell. Wer beides vermischt, bekommt ein System, das man weder testen noch debuggen kann.
Das ist kein neues Argument — aber es ist eines, das durch die Hot-Take-Welle der letzten zwei Jahre („Just add an agent!”) systematisch übertönt wurde. Frameworks wie LangGraph, das aktuelle OpenAI Agents SDK oder das, was Anthropic in den Claude-Skills-Patterns dokumentiert, gehen alle in dieselbe Richtung: explizite Graphen, definierte Zustände, klare Übergänge. Das ist im Kern Software-Engineering aus den 1990ern, nur mit einem LLM in den Knoten.
Was das praktisch für KMU bedeutet
Wenn Sie aktuell ein KI-Agenten-Projekt laufen haben — intern oder mit einer Agentur —, dann lohnen sich diese drei Schritte diese Woche:
1. Stellen Sie eine ehrliche Frage zur Architektur. Lassen Sie sich vom Umsetzer ein Diagramm geben: Welche Schritte laufen im Code, welche im LLM? Wenn die Antwort lautet „das LLM entscheidet selbst, was als Nächstes passiert”, ist das ein Warnsignal. Nicht zwingend ein KO-Kriterium — aber Sie sollten verstehen, wie Fehlerfälle abgefangen werden, wie Wiederholungen funktionieren und wie der Zustand zwischen den Schritten gespeichert wird.
2. Trennen Sie Wahrnehmung von Aktion. Ein praktikables Muster für KMU-Projekte: Das LLM darf interpretieren, klassifizieren, extrahieren, formulieren — also alles, was mit Sprache zu tun hat. Aktionen mit Konsequenzen (Datenbank schreiben, E-Mail versenden, Zahlung auslösen) gehören hinter eine deterministische Schicht, die validiert und gegebenenfalls einen Menschen einbindet. Diese Trennung kostet ein paar Tage Mehrarbeit beim Bauen und spart Wochen beim Betreiben.
3. Definieren Sie messbare Erfolgskriterien pro Schritt, nicht nur fürs Gesamtsystem. „Der Agent funktioniert zu 90%” ist keine Metrik. „Die Kundendaten-Extraktion ist in 98% der Fälle korrekt, die Preisberechnung in 100%, die Dokumentgenerierung in 95%” ist eine. Sobald Sie pro Schritt messen, sehen Sie sofort, wo das LLM überfordert ist — und wo Sie tatsächlich nur Code brauchen.
Mein Rat für die nächsten 30 Tage
Wer 2026 in KI investiert, hat in der Regel ein Budget zwischen 20.000 und 150.000 Euro für ein erstes ernsthaftes Projekt. Mein Rat: Geben Sie nicht mehr als ein Drittel davon für die LLM-Integration aus. Der Rest fließt in Datenanbindung, Steuerlogik, Logging, Monitoring und Fehlerbehandlung. Ein Projekt, dessen Code-zu-Prompt-Verhältnis bei 1:1 oder schlechter liegt, wird mit hoher Wahrscheinlichkeit nicht in den Regelbetrieb kommen.
Die HN-Diskussion bestätigt etwas, das in den letzten Monaten zwischen den vielen Modell-Releases unterzugehen drohte: Der Engpass produktiver KI-Anwendungen liegt nicht mehr beim Modell. Er liegt in der Architektur drumherum. Genau das ist die gute Nachricht für KMU — denn solide Architektur ist eine Disziplin, die in Österreich viele Entwicklungspartner beherrschen. Man muss sie nur einfordern.