Autonome KI-Agenten gelten seit einiger Zeit als nächster Schritt nach dem Chat-Fenster: Systeme, die nicht nur antworten, sondern Aufgaben zerlegen, Werkzeuge aufrufen, Zwischenergebnisse prüfen und am Ende ein fertiges Arbeitsprodukt abliefern. Ein Forschungsversuch dämpft diese Erwartung. Forschende ließen KI-Agenten wissenschaftliche Studien zu bislang unbeantworteten Forschungsfragen schreiben – die Programme scheiterten an der Aufgabe.

Das Setting ist bewusst hart gewählt. Eine offene Forschungsfrage ist genau der Fall, in dem sich die Antwort nicht aus vorhandenem Material zusammensetzen lässt. Es gibt kein Muster im Trainingsmaterial, an dem sich ein Modell orientieren könnte, und keine Autorität, die das Ergebnis nebenbei bestätigt. Wer hier bestehen will, muss eine eigene Fragestellung sauber abgrenzen, eine Methode wählen, Widersprüche im eigenen Vorgehen erkennen und die eigene Arbeit anschließend selbst als unzureichend verwerfen können. Das ist ein anderer Anspruch als das Erzeugen eines plausibel klingenden Textes.

Plausibel ist nicht dasselbe wie richtig

Der interessante Punkt für Unternehmen liegt nicht darin, dass Agenten Fehler machen. Das tun Menschen auch. Er liegt darin, an welcher Stelle die Fehler auftreten und wie schwer sie zu erkennen sind. Sprachmodelle sind darauf optimiert, Ergebnisse zu erzeugen, die der Form korrekter Ergebnisse entsprechen. Ein Studientext, der wie eine Studie aussieht, ist damit erreichbar. Ein Studientext, dessen Erkenntnis trägt, ist es nicht automatisch.

Übertragen auf Softwareprojekte heißt das: Ein Agent liefert mit hoher Wahrscheinlichkeit Code, der kompiliert, einer Konvention folgt und in der Struktur vernünftig aussieht. Ob er das eigentliche fachliche Problem löst, ob er einen Randfall berücksichtigt, den niemand aufgeschrieben hat, und ob er in drei Jahren noch wartbar ist, entscheidet sich auf einer Ebene, die das Modell nicht bewerten kann, solange es keine echte Rückmeldung aus der Realität erhält.

Selbstverbesserung braucht ein Korrektiv von außen

Die Hoffnung hinter selbstverbessernden Agenten lautet: Das System prüft sein eigenes Ergebnis, erkennt die Schwachstelle und iteriert, bis es passt. In der Praxis setzt das voraus, dass die Prüfung härter ist als die Erzeugung. Genau daran hakt es. Wenn dasselbe Modell Autor und Gutachter ist, prüft es gegen dieselben Annahmen, die schon zum Fehler geführt haben.

Wo dieses Korrektiv maschinell existiert, funktionieren Agenten deutlich besser. Ein fehlschlagender Test, ein Linter-Fehler, ein HTTP-Status 500, eine nicht erfüllte Datenbank-Bedingung – das sind eindeutige Signale von außen, an denen ein Agent sich abarbeiten kann. Wo das Korrektiv fehlt oder nur ein Mensch es liefern kann, endet die Autonomie.

Was das für den Praxiseinsatz bedeutet

Aus dieser Unterscheidung lässt sich eine brauchbare Auswahlregel für Projekte ableiten. Sinnvoll sind Agenten dort, wo drei Bedingungen zusammenkommen:

  • Prüfbares Ergebnis: Es gibt einen automatisierten Test, ein Schema, eine Validierung oder eine Referenz, gegen die das Ergebnis fällt oder besteht.
  • Begrenzter Schaden: Ein Fehlschlag kostet Rechenzeit und eine Wiederholung, nicht Datenintegrität, Vertrauen oder Geld.
  • Klarer Abbruchpunkt: Der Agent kann nicht endlos weiterlaufen, sondern hat definierte Grenzen für Versuche, Laufzeit und Zugriffe.

Kritisch bleiben dagegen Aufgaben, bei denen die Bewertung selbst die eigentliche Leistung ist. Ein Code-Review, das Architekturentscheidungen einordnet. Die Frage, ob eine Anforderung überhaupt so umgesetzt werden soll. Die Auslegung einer vertraglichen oder regulatorischen Vorgabe. In diesen Fällen ist ein Agent ein Vorschlagsgeber und kein Entscheider.

Menschliche Kontrollpunkte gehören in den Workflow, nicht daneben

Wichtig ist die Stelle, an der der Mensch eingreift. Eine Freigabe am Ende einer langen Agentenkette ist wenig wert, weil dort die Prüfung des Gesamtergebnisses aufwendiger ist als die eigene Erstellung gewesen wäre. Nützlicher sind Kontrollpunkte an den Übergängen: bevor ein Agent Schreibrechte auf ein System erhält, bevor er einen Migrationsschritt ausführt, bevor Inhalte veröffentlicht werden.

Ebenso hilfreich ist Transparenz über den Weg zum Ergebnis. Wenn nachvollziehbar bleibt, welche Werkzeuge ein Agent aufgerufen und welche Zwischenschritte er verworfen hat, lässt sich ein Fehler lokalisieren. Ohne diese Spur bleibt nur die Wahl zwischen blindem Vertrauen und vollständiger Nachkontrolle.

Erwartungsmanagement ist Teil der Projektarbeit

Der Befund aus dem Forschungsversuch ist kein Argument gegen KI im Entwicklungsalltag. Er präzisiert lediglich, wofür die Technik heute taugt. Assistenz bei klar umrissenen, überprüfbaren Arbeitsschritten – dafür gibt es belastbare Erfahrungen. Eigenständige Bearbeitung offener Fragen ohne fachliche Aufsicht – dafür nicht.

Für Web- und Softwareprojekte folgt daraus vor allem eine Planungsaufgabe: Agenten sollten mit denselben Anforderungen an Testbarkeit, Rechtevergabe und Protokollierung eingeführt werden wie jede andere automatisierte Komponente. Wer die Prüfschleifen zuerst baut und die Autonomie danach ausweitet, gewinnt Geschwindigkeit ohne unkalkulierbare Risiken. Und wer den Nutzen realistisch beziffert, muss später keine Erwartung zurücknehmen, die technisch nie gedeckt war.

Quellen