Vom Coding-Assistenten zum handelnden Entwicklungsagenten

Vom Assistenten zum Agenten

0:00 Vor zwei Jahren war KI im Entwicklungsalltag vor allem eines: eine bessere Autovervollständigung. Heute gibt es Werkzeuge, die ein Repository durchsuchen, einen Plan fassen, Code schreiben, Tests laufen lassen und einen Pull Request vorbereiten. Zwischen diesen beiden Welten liegt kein technischer Sprung, sondern eine Frage der Verantwortung: Wer entscheidet, und wer führt aus? Dieses Modul zieht diese Grenze.

0:24 Es geht noch nicht um das Model Context Protocol und noch nicht um Code — es geht darum, ein Vokabular zu haben, mit dem sich im Team sauber besprechen lässt, was ein Agent eigentlich darf.

Vom Coding-Assistenten zum handelnden Entwicklungsagenten

0:35 Der erste Tag gehört dem Protokoll und dem eigenen Server. Bevor wir aber eine Zeile davon anfassen, klären wir das Umfeld: Welche Arten von KI-Werkzeugen gibt es im Entwicklungsalltag, wie arbeiten sie, und wo liegt die Schwelle, ab der aus einem Vorschlag eine Handlung wird. Behalten Sie eine Frage im Hinterkopf, sie zieht sich durch das ganze Seminar: Was müsste schiefgehen, damit es wehtut — und wer hätte es gemerkt?

Ausprägungen KI-gestützter Entwicklungswerkzeuge

1:00 Fangen wir mit einer Landkarte an. Die Werkzeuge, die heute unter dem Stichwort KI im Entwicklungsalltag auftauchen, unterscheiden sich weniger in ihrer Technik als in dem, was sie selbstständig tun dürfen. Vier Stufen reichen, um sich zu orientieren. Der Begriff, den die Spezifikation für die Anwendung verwendet, ist Host — und das ist ein sehr passendes Bild.

1:21 Der Host ist der Gastgeber: Er führt das Sprachmodell, er hält die Verbindungen zu den Werkzeugen, und er setzt die Hausregeln durch. Das Modell ist in diesem Bild der Gast, der Vorschläge macht. Wichtig ist die Rollenverteilung: Die Intelligenz sitzt im Modell, die Kontrolle sitzt beim Gastgeber. Wer diese Trennung verliert, hat später niemanden, der die Tür zumacht. Merken Sie sich den Begriff — ab Modul 3 arbeiten wir damit genau.

1:48 Die vier Stufen sind bewusst als Kette gezeichnet, nicht als Liste. Von links nach rechts wächst zweierlei gleichzeitig: der mögliche Nutzen und die Menge dessen, was zwischen Ihrer Entscheidung und der Wirkung liegt. Beim Chat tippen Sie das Ergebnis selbst ab, da kann wenig passieren. Beim asynchronen Auftrag liegt am Ende ein fertiger Zweig vor, den Sie so oder so lesen müssen.

2:10 Die Kette hat keine Stufe, die man überspringen sollte — sie hat nur eine, die zum jeweiligen Auftrag passt. Lesen Sie diese Tabelle nicht als Produktvergleich, sondern als Buchführung. In jeder Zeile steht dieselbe Arbeit, nur anders verteilt. Was oben der Mensch tut, übernimmt weiter unten das Werkzeug — aber die Arbeit verschwindet nicht, sie wandert. Sie wandert vom Schreiben zum Prüfen.

2:33 Das ist der Grund, warum die Einführung eines Agenten so oft enttäuscht: Man plant die eingesparte Stunde ein und vergisst die halbe Stunde, die das Lesen des Ergebnisses kostet. Wer beides in die Rechnung stellt, trifft bessere Entscheidungen darüber, wo sich der Einsatz lohnt. Diese vier Fehler haben einen gemeinsamen Ursprung: Die Wahl fällt nach dem Produkt und nicht nach der nötigen Kontrolle.

2:57 Ein Team führt ein Werkzeug ein, weil es gute Erfahrungen mit der Vervollständigung gemacht hat — und schaltet dabei stillschweigend Schreibrechte frei. Das passiert nicht aus Leichtsinn, sondern weil beide Funktionen im selben Fenster sitzen. Der wirksamste Gegenmittel ist banal: Bevor ein Werkzeug etwas verändern darf, muss benannt sein, wer das Ergebnis abnimmt. Nicht welche Rolle — welche Person.

Die agentische Schleife

3:20 Schauen wir uns an, was so ein Agent eigentlich tut, wenn er arbeitet. Es ist weniger geheimnisvoll, als es klingt, und die Mechanik dahinter erklärt die meisten Probleme, die im Betrieb auftreten. Stellen Sie sich jemanden vor, der in einer fremden Stadt ein Restaurant sucht: umsehen, Richtung entscheiden, eine Straße gehen, wieder umsehen.

3:41 Genau so arbeitet ein Agent — Kontext lesen, Schritt planen, Werkzeug aufrufen, Ergebnis auswerten, von vorn. Der entscheidende Punkt ist das Ende der Schleife. Sie hört auf, wenn das Ziel erreicht ist, wenn ein vereinbartes Abbruchkriterium greift, oder wenn eine Entscheidung ansteht, die der Agent nicht treffen darf. Fehlen diese beiden letzten Ausgänge, läuft die Schleife bis zum Budget.

4:04 Wir begleiten diese Schleife an unserem Beispiel, das uns durch das ganze Seminar trägt: dem Anliegenbuch, einer internen Anwendung für Serviceanfragen. Der Agent liest zuerst das Architekturhandbuch und die betroffenen Module, überlegt dann, wo die neue Prüfung hingehört, und sucht die bestehende Validierung. Jetzt kommt der interessante Teil: Der Treffer passt nicht, also verfeinert er die Suche.

4:26 Und im letzten Schritt stößt er auf eine fachliche Frage, die er nicht beantworten kann — und gibt ab. Beachten Sie, dass der Abbruch hier ein regulärer Schritt ist und kein Scheitern. Hier steckt die vielleicht wichtigste Einsicht des Moduls. In dieser Schleife treffen zwei völlig verschiedene Naturen aufeinander. Die Werkzeuge sind deterministisch: Derselbe Aufruf liefert dasselbe Ergebnis, heute wie morgen. Die Auswahl des nächsten Schritts ist probabilistisch, sie schwankt.

4:55 Daraus folgt eine praktische Regel, die uns bis zum letzten Modul begleitet: Verlässlichkeit entsteht am deterministischen Teil. Prüfungen gehören in die Werkzeuge und in die Pipeline — nicht in die Anweisung an das Modell. Alles, was Sie dem Modell zusagen lassen, ist eine Bitte. Alles, was der Server prüft, ist eine Regel.

5:15 Die vier Punkte sind nichts anderes als die Schleife, die aus dem Ruder läuft. Besonders verbreitet ist der zweite: Fehlermeldungen, die keine Handlungsanweisung enthalten. Ein Agent, der liest „Fehler beim Verarbeiten", kann daraus nichts ableiten und beginnt zu raten — und Raten kostet Runden, Geld und am Ende Vertrauen.

5:33 Wir kommen in Modul 6 ausführlich darauf zurück, weil sich hier mit wenig Aufwand sehr viel gewinnen lässt. Der vierte Punkt ist der unangenehmste: Ein falscher Zwischenstand vergiftet alles, was danach kommt.

Assistenz, Delegation und autonome Ausführung

5:46 Kommen wir zu der Unterscheidung, die im Team am häufigsten für Missverständnisse sorgt — und die man in zwei Minuten klären kann, wenn man die richtigen Begriffe hat. Drei Stufen, und der Unterschied liegt nur an einer Stelle: wo die Prüfung sitzt. Bei der Assistenz prüfen Sie jeden Vorschlag, bevor er wirkt. Bei der Delegation prüfen Sie das Ergebnis, nachdem es fertig ist, aber bevor es wirkt.

6:08 Bei der autonomen Ausführung tritt die Wirkung ein, und die Prüfung kommt danach — wenn überhaupt. Deshalb ist die dritte Stufe die einzige, die eine bewusste Entscheidung erzwingt. Und deshalb ist der Satz, den man am häufigsten hört — „wir lassen den Agenten einfach mal laufen" — fast immer eine Entscheidung, die niemand getroffen hat.

6:29 Zwei Achsen genügen für die Entscheidung im Alltag: Wie groß ist die Änderung, und ist sie umkehrbar. Links oben, klein und umkehrbar, ist der ideale Fall für die Delegation — hier gewinnen Sie am meisten und riskieren am wenigsten. Rechts unten, groß und endgültig, sollte niemand delegieren; das ist die Migration, die Datenlöschung, der Umbau der Schnittstelle.

6:50 Die beiden interessanten Felder sind die anderen. Klein und endgültig heißt: delegieren ja, aber mit Bestätigung vor der Ausführung. Groß und umkehrbar heißt: in Schritte schneiden, und dann ist es wieder Fall eins. Das ist keine Vorsichtsmaßnahme, die wir uns hier ausdenken — es steht in der Spezifikation des Protokolls selbst.

7:10 Dort ist festgehalten, dass es aus Gründen der Sicherheit stets einen Menschen in der Schleife geben soll, der einen Werkzeugaufruf ablehnen kann. Anwendungen sollen sichtbar machen, welche Werkzeuge dem Modell überhaupt zur Verfügung stehen, und sollen vor Aufrufen nachfragen. Das ist bemerkenswert für ein technisches Protokoll: Es regelt normalerweise Nachrichtenformate, hier regelt es eine Erwartung an die Bedienoberfläche.

7:34 Die Zustimmung ist also kein Komfort, den man später ergänzt — sie ist Teil des Entwurfs. Der zweite Punkt ist der, den ich in der Praxis am häufigsten sehe, und er ist tückisch: Die Bestätigung wird zur Gewohnheit. Wer zwanzigmal am Tag denselben Dialog wegklickt, liest ihn beim einundzwanzigsten Mal nicht mehr — und genau das ist die Stelle, an der etwas durchrutscht.

7:56 Daraus folgt eine unbequeme Konsequenz: Wenige, gut gewählte Bestätigungen sind wirksamer als viele. Wir schauen uns in Modul 15 an, wie man sie so baut, dass sie tatsächlich etwas prüfen — nämlich indem sie die konkreten Argumente zeigen und nicht nur den Namen des Werkzeugs.

Geeignete und ungeeignete Aufgaben

8:13 Bleibt die praktische Frage, mit der Sie am Montag nach dem Seminar konfrontiert sind: Woran erkenne ich eigentlich, ob sich eine Aufgabe für den Agenten eignet? Drei Kriterien, und sie müssen alle drei erfüllt sein. Das Ziel muss prüfbar formuliert sein, es muss ein Testorakel geben — also eine Instanz, die sagt, was richtig ist —, und die Wirkung muss umkehrbar bleiben.

8:34 Fehlt eines davon, verschwindet der Zeitgewinn. Das dritte Kriterium wird dabei am häufigsten übersehen, weil es technisch klingt, aber eine Managemententscheidung ist: Irreversible Wirkung macht jeden Zeitgewinn wertlos, denn der eine Fall, in dem es schiefgeht, kostet mehr als hundert Fälle eingespart haben. Die interessante Zeile ist die mittlere. Der fachliche Schnitt eignet sich nicht, weil niemand sagen kann, wann er richtig ist — da hilft kein Test.

9:01 Die Validierungsregel eignet sich gut, das ist der Lehrbuchfall. Aber die Abhängigkeiten sind der Regelfall im Alltag: prüfbar, aber mit breiter Wirkung. Und hier entscheidet nicht die Aufgabe, sondern der Zuschnitt. Ein Auftrag „alle Abhängigkeiten aktualisieren" ist ungeeignet. Ein Auftrag „diese eine Abhängigkeit aktualisieren, Tests müssen grün bleiben, nichts anderes anfassen" ist geeignet. Dieselbe Arbeit, anderer Schnitt.

9:29 Ich formuliere es zugespitzt: Generierter Code ist schnell erzeugt und langsam verantwortet. Der zweite Punkt ist dabei der entscheidende. Ohne Test bleibt nur das Lesen des Diffs, und das skaliert nicht — ein Mensch liest zweihundert Zeilen sorgfältig, bei zweitausend überfliegt er. Deshalb ist die ehrlichste Frage vor jedem Agentenauftrag nicht „kann der das?", sondern „wie prüfe ich das Ergebnis?".

9:52 Wer bei dieser Frage ins Stocken gerät, hat die Antwort auf die erste Frage schon bekommen. Jetzt sind Sie dran. Nehmen Sie die drei Aufträge und ordnen Sie jeden entlang der drei Kriterien ein — prüfbar, Testorakel vorhanden, umkehrbar. Wichtig ist mir dabei nicht das Ergebnis, sondern die Begründung: Ein Satz je Auftrag, warum er geeignet ist oder nicht.

10:13 Und für den ungeeigneten kommt eine zweite Frage dazu, die im Alltag die nützlichere ist: Was müsste sich ändern, damit er geeignet wird? Meistens ist die Antwort ein anderer Zuschnitt und kein anderes Werkzeug.

Übung

10:27 Zum Abschluss des Moduls bauen wir aus all dem ein Werkzeug, das Sie ab morgen verwenden können — und das uns in Modul 10 als Grundlage für die ausführbare Spezifikation wieder begegnet. Der Agent-Task-Canvas ist bewusst klein gehalten: fünf Felder auf einer Seite. Ziele, Nicht-Ziele, Akzeptanzkriterien, zulässige Werkzeuge, erforderliche Freigaben.

10:47 Mehr braucht es nicht, um die häufigsten Unfälle zu verhindern, und weniger reicht nicht. Sie werden merken, dass die zweite Spalte — die Nicht-Ziele — beim ersten Mal die schwierigste ist und im Alltag die wertvollste. Sie ist die einzige Stelle im Auftrag, die verhindert, dass er während der Bearbeitung wächst. Der Auftrag lautet: Serviceanfragen ohne Kostenstelle sollen künftig abgelehnt statt stillschweigend angenommen werden.

11:14 Ein Satz, der harmlos aussieht und mindestens vier Fragen offenlässt. Füllen Sie den Canvas — mit mindestens zwei Nicht-Zielen, drei prüfbaren Akzeptanzkriterien, dem erlaubten Werkzeugsatz und der Stelle, an der ein Mensch freigeben muss. Nehmen Sie sich zwanzig Minuten. Und achten Sie darauf, wo Sie ins Stocken geraten — genau dort sitzt im echten Projekt später das Problem.

11:37 Zum Schluss die vier Fallen, die Ihnen gleich bei der Übung begegnen werden. Der häufigste Fehler sind leere Nicht-Ziele — sie fühlen sich beim Ausfüllen überflüssig an und sind es nie. Der zweite ist subtiler: Akzeptanzkriterien, die die Lösung beschreiben statt das beobachtbare Verhalten. „Prüfung im Formular ergänzen" ist eine Lösung; „Anfragen ohne Kostenstelle werden abgelehnt" ist ein Kriterium.

12:00 Und der vierte Punkt ist der, den man erst im Betrieb merkt: Eine Freigabe, die genannt, aber niemandem zugeordnet ist, findet nicht statt. Damit sind wir bereit für das Protokoll selbst.