Grundlagen
Der Agent spielt, du bist jetzt Co-Trainer
Ein Trainer sah sein eigenes Curriculum schrumpfen. Was das über die Fähigkeit verrät, die jetzt zählt, und warum das Warnsignal fehlt, wenn es kippt.
Wenn du wissen willst, welchen Teil deines Handwerks Agenten übernommen haben, frag jemanden, der ihn bisher unterrichtet hat.
Bruce Tate macht das seit Jahren. Er ist Gründer von Groxio, hat "Seven Languages in Seven Weeks" geschrieben, "Programming Phoenix" mitverfasst und bringt Entwicklern Elixir bei. Im Juli 2026 hat er aufgeschrieben, was mit seinem eigenen Geschäft passiert ist, und das ist interessanter als jede Prognose: Sein Curriculum schrumpft.
Weniger Vokabular. Weniger Syntax. Weniger von dem Material, in dem der Agent ohnehin schon gut ist. Was bleibt, fasst er in einem Wort zusammen, das breit genug ist für den Rest: Aufsicht.
Vom Techniktrainer zum Trainer der Trainer
Tates Bild dafür ist ein Sportbild, und es sitzt. Früher war er Co-Trainer: Technik, Stellung, Fußarbeit, dieselbe Übung so lange, bis sie ohne Nachdenken saß. Das macht er kaum noch.
Der Entwickler ist heute der Co-Trainer. Der Agent steht auf dem Platz. Und Tate trainiert die Trainer, also Leute, die den ganzen Tag Technik korrigieren, die nicht ihre eigene ist.
Nach unten geht dabei nichts, nur nach oben. Innerhalb von Elixir, schreibt Tate, sei der Unterricht gestiegen: weniger Vokabular, mehr Architektur. Wo sitzen die Lebenszyklus-Nähte, an denen das System deinen Code aufruft statt umgekehrt? Was gehört in den funktionalen Kern, was in die Schale zur Außenwelt? Diese Fragen entscheiden, ob eine Codebasis überlebt, und der Agent stellt sie nicht. Er erzeugt bereitwillig Code auf beiden Seiten einer Grenze, von deren Existenz er nichts weiß.
Auch das Format hat sich verschoben. Der Dreitageskurs schrumpft, was funktioniert sind laufende Termine über Monate, weil die Fehler dieser Leute nach ihrem eigenen Kalender kommen und ein Feuerwehrschlauch im März im Juni niemandem hilft. Bemerkenswert ist, wer das sagt, denn ein Dreitageskurs dürfte sich als Produkt leichter verkaufen lassen. Es deckt sich mit dem, was wir in KI-Kompetenzlücke: alle nutzen, wenige können empfohlen haben.
Das Warnsignal, das fehlt
Der wichtigste Satz aus Tates Text ist ein anderer, und er ist leise:
Die Zuversicht eines Agenten sinkt nicht, wenn seine Kompetenz sinkt.
Ein datenbankgestütztes Formular hat, wie Tate es zuspitzt, zehn Millionen Beispiele in den Trainingsdaten. Dein spezielles Nebenläufigkeitsmodell hat keines. Die Ausgabe kommt in beiden Fällen im selben Ton: flüssig, sortiert, überzeugt. Genau in dieser Lücke gehen die Räder ab.
Tates Befund aus der Praxis dazu ist entlastend und unbequem zugleich. Niemand, mit dem er gearbeitet hat, ist gescheitert, weil er unvorsichtig war. Gescheitert sind sie, weil das Signal fehlte, das ihnen gesagt hätte, langsamer zu machen.
Bei einem menschlichen Kollegen ist dieses Signal gratis eingebaut. Zögern, ein "ich bin mir nicht sicher", ein Blick, eine längere Pause vor der Antwort. Ein Agent liefert diese Information nicht mit. Sie muss von außen kommen, und das ist die Arbeit, die übrig bleibt.
Die Fähigkeit heißt: kleiner fragen
Agenten laufen voraus. Du fragst nach einer Schnittstelle und bekommst eine Implementierung. Bittest du um eine Gliederung, kommt ein fertiges Modul zurück. Der Agent will helfen, und wenn ihn niemand anhält, trifft er Architekturentscheidungen, von denen du nicht wusstest, dass sie zur Wahl standen.
Tate demonstriert das an einem Beispiel, das mit Software nichts zu tun hat. Er baut Möbel. Für ein Stück, an dem er gerade arbeitete, hatte er eine enge Frage an Gemini: Farbe, und die Seitenverhältnisse, die er abwog. Zurück kam eine Zuschnittliste, eine Materialbeschaffung und ein Lackierplan. Ein selbstbewusster Stapel Dinge, nach denen er nicht gefragt hatte.
Also hat er das Gespräch verlangsamt und eins nach dem anderen gefragt. Danach bekam er genau das, was er wollte.
Derselbe Fehler, dieselbe Lösung, nur ein völlig anderer Preis: Beim Möbelstück kostet ein Irrtum ein Brett. Beim System, das du zwei Jahre pflegst, kostet er mehr.
Praktisch heißt das, den Agenten dort anzuhalten, wo eine Entscheidung fällt:
Schreib noch keinen Code. Beschreibe mir nur die Schnittstelle, die du bauen würdest: Signaturen und Datentypen, keine Implementierung.
Wo du dabei eine Entscheidung triffst, die auch anders ausfallen könnte, nenne sie einzeln und sag mir, warum du dich so entschieden hast.
Danach warte auf mein Okay.
Der zweite Absatz ist der eigentliche Trick. Er holt genau die Information heraus, die sonst fehlt, nämlich wo der Agent geraten hat.
Prompten ist Code schreiben, der Code schreibt
Portionieren ist die eine Hälfte. Die andere ist Tates Antwort auf die Frage, was er anstelle von Syntax und Vokabular überhaupt noch unterrichtet, und sie passt in ein Wort: Schichtung. Wie man Code schichtet, und wie man Prompts schichtet. Das seien dieselbe Fähigkeit in unterschiedlicher Kleidung.
Der Gedanke dahinter räumt mit einer verbreiteten Annahme auf. Prompten gilt als neue Disziplin, für die niemand Erfahrung mitbringt. Tate sieht das anders: Eine Prompt-Kette ist ein Programm, geschrieben in englischer Sprache. Kleine Einheiten, die eine Sache gut machen. Saubere Schnittstellen. Schichten, von denen jede eine Verantwortung trägt, mit Grenzen, die nicht verschwimmen.
Wer fünfzehn Jahre lang brauchbare Module entworfen hat, kann das längst und hat den Übertrag nur nicht bemerkt.
Praktisch übersetzt Tate das in bekannte Bausteine: Skills als Einheiten von Fähigkeit, eine AGENTS.md für die Konventionen, die niemand zweimal erklären sollte, Subagenten für Arbeit, die eigenen Kontext verdient. Entscheidend ist für ihn, wo das liegt. Die Prompt-Architektur gehört versioniert und reviewt in den Quellbaum, nicht in ein Chatfenster, das sich schließt. Für ein Team aus einer Person, das keinen Senior zum Gegenlesen hat, ist genau das der Ersatz: nicht mehr Disziplin, sondern Urteilsvermögen, das irgendwo steht, wo der Agent es lesen kann.
Wie so ein Netz aus Regeln, Skills und Prüfungen konkret aussieht und mitwächst, haben wir in Harness Engineering auseinandergenommen.
Die Anrufe, die zu Recht ausbleiben
Jetzt der Teil, der Tate von den üblichen Warnern unterscheidet. Eine ganze Kategorie von Software gehört seiner Ansicht nach genau so gebaut, ohne Führung, und das sei dann die richtige technische Entscheidung.
Sein Beispiel: Jemand hat ein datenbankgestütztes Formular hochgezogen. Ein paar Tabellen, Authentifizierung, ein Deployment, ein Nachmittag. Es funktioniert, es wird weiter funktionieren, und niemand wird je wieder darüber nachdenken müssen. Diese Person hat ihn nicht angerufen, und Tate sagt dazu: zu Recht.
Machbarkeitsnachweise, ein Prototyp, der in einem Meeting eine Idee zeigen soll, eine kleine Website, ein internes Werkzeug mit einem einzigen Nutzer. Dort ist der Agent wirklich gut, es steht wenig auf dem Spiel, und Beratung wäre Aufwand für ein Problem, das es nicht gibt.
Dazu schärft er den Begriff, was der Debatte guttut. Gemeint ist damit weder Geschwindigkeit noch KI-Nutzung an sich. Vibing ist agentisches Programmieren ohne Führung: Ergebnisse annehmen, ohne sie zu beurteilen, und ausliefern, ohne sie zu verstehen. Das ergänzt die übliche Definition um eine Zeitachse. Sonst wird über die fehlende Nachkontrolle geredet, hier geht es um die fehlende Steuerung währenddessen. Wie sich der Begriff entwickelt hat, steht in Vibe Coding: Was steckt dahinter? und Von Vibe Coding zu Agentic Engineering.
Ein Wort zur Einordnung, weil wir an anderer Stelle strenger klingen: Die Review-Pflicht aus dem Agentic-Engineering-Artikel gilt für tragende Systeme. Wie lang die Leine sein darf, hängt am Risiko, und dieser Abschnitt beschreibt das untere Ende der Skala. Die Frage ist damit nicht, ob man vibed, sondern woran.
Woran es kippt
Tate schreibt dabei über einen bestimmten Zuschnitt, und das lohnt sich zu wissen, bevor man sich angesprochen fühlt: Teams aus einer oder zwei Personen, Gründer, niemand da, der irgendetwas reviewt. Dort unterscheidet er zwei Sorten von Teams.
Die erste Sorte hat vorher hingeschaut und entschieden, es nicht zu vibern, weil etwas daran tragend war: echte Skalierung, langlaufende Prozesse, Daten, die durch genug Hände gehen, dass der Fluss selbst das Schwierige ist, oder ein Domänenmodell mit wirklicher Struktur. Manchmal reicht auch, dass die Sache neu genug ist, dass es keine Vorlage gibt, an die sich der Agent anlehnen könnte.
Woran man merkt, dass man in dieser Kategorie ist, beschreibt Tate über zwei Erlebnisse, die viele kennen dürften: einen Tag lang eine Race Condition zu jagen, um dann festzustellen, dass der Agent in der ersten Stunde den falschen Ansatz gewählt hat. Oder sechs Varianten derselben Funktion in einer Codebasis zu finden, die man zu kennen glaubte.
Die zweite Sorte hat es schon versucht. Es ist kaputt, es wird schlimmer, und das Reparieren dauert länger als das Bauen gedauert hat. Dann bleibt nur noch eine Entscheidung: den Code retten, oder die Codebasis als Anforderungsdokument lesen und wegwerfen.
Tate wählt meistens das Wegwerfen, und begründet es mit einer Analogie, die jeder sofort versteht: Genau das macht man bei einem kurzen Prompt, der nicht funktioniert hat, auch. Man formuliert ihn besser und wirft den alten weg. Dasselbe Manöver, nur auf Systemgröße.
Fazit
Die beste Nachricht bei Tate steht in der Voraussetzung. Man kann nichts beaufsichtigen, dessen Form man nicht versteht. Der vorhandene Erfahrungsschatz ist damit genau das Kapital, auf dem die neue Arbeit aufsetzt.
Neu ist eine einzige Gewohnheit: den nächsten Schritt selbst zu setzen. Tate bringt sie auf drei kurze Sätze, und sie funktionieren bei einem Regal genauso wie bei einem verteilten System.
Langsamer machen. Weniger auf einmal verlangen. Weitergehen, wenn du es entscheidest.