Wie man KI-Coding-Agenten wie ein Profi steuert

Wie man KI-Coding-Agenten wie ein Profi steuert

Ungefähr sechs Monate lang hatte ich die falsche Berufsbezeichnung in meinem eigenen Kopf. Ich dachte, ich sei ein Entwickler, der Claude Code benutzt. Dann brach ich um 23 Uhr einen Produktions-Build, verfolgte ihn zurück zu einer einzigen Zeile, die der Agent geschrieben hatte und die ich nie wirklich gelesen hatte, und erkannte die Wahrheit: Ich war ein Passagier gewesen. Im Fahrersitz sitzend, Hände am Steuer, aber hauptsächlich hoffend, dass das Auto auf der Straße blieb.

Die Lösung war kein besseres Modell. Opus 4.8 lief bereits. Die Lösung war eine andere Rolle. Ich hörte auf zu versuchen, Code durch den Agenten zu schreiben, und begann den Agenten zu dirigieren — so wie ein Filmregisseur die Kamera nicht bedient, aber für jedes Bild verantwortlich ist. Diese Veränderung, mehr als jede Prompt-Vorlage oder jedes Plugin, hat die Menge an echter, lieferbarer Arbeit, die ich aus einem Tag heraushole, verdoppelt.

Das ist der Teil, den niemand in die schicken Demovideos packt. Um KI-Coding-Agenten gut zu steuern, verbringst du mehr Zeit mit Planen als mit Bauen. Du verwaltest die Aufmerksamkeit des Agenten, als wäre sie eine knappe Ressource, denn das ist sie. Du baust Gerüste um ihn herum, damit er seine eigene Arbeit überprüfen kann. Und du behandelst jeden Fehler als Chance, das System dauerhaft zu verbessern, statt als einmaliges Ärgernis.

Vieles, was mein Denken reorganisierte, kam aus einem Podcast-Interview, das ich immer wieder zurückspulte — Cole Medin, ein Software-Ingenieur, der zum AI-Builder wurde und eine der schärferen Stimmen zum agentischen Coding. Er rahmt Claude Code nicht als Codegenerator, sondern als ein "AIOS", ein KI-Betriebssystem, das man in die Art einbindet, wie man tatsächlich ein Unternehmen führt. Diese Rahmung klang großartig, bis ich anfing, sie anzuwenden. Dann klang sie einfach korrekt.

Hier ist alles, was ich daran geändert habe, wie ich meine Agenten führe — was funktionierte, was mich verbrannt hat, und die genauen Gewohnheiten, die ich jetzt ablehne zu überspringen.

Warum KI-Coding-Agenten steuern besser ist als sie zu prompten

Einen KI-Coding-Agenten zu steuern bedeutet, die Verantwortung für die Absicht, den Plan, die Erfolgskriterien und die Verifizierung zu übernehmen — und den Agenten das Tippen erledigen zu lassen. Der Prompt ist der kleinste Teil der Arbeit. Das Nachdenken um den Prompt herum ist, wo der Hebel liegt.

Die meisten Leute, die sagen, Claude Code "funktioniert nicht für echte Projekte", stecken im Prompt-Modus fest. Sie öffnen eine Sitzung, tippen einen Absatz, schauen zu, wie es generiert, und beurteilen das Werkzeug anhand der ersten Sache, die es ausspuckt. Wenn dieser erste Versuch falsch ist — und das ist er bei allem Nicht-Trivialen meistens — schlussfolgern sie, dass der Agent dumm ist. Ich tat genau das monatelang.

Die Neurahmung ist brutal, aber befreiend: Der Agent ist nicht dein Kollegen-Ingenieur. Er ist ein außerordentlich schneller, außerordentlich wörtlich nehmender Junior, der alles gelesen hat und sich an nichts über dein Projekt erinnert, es sei denn, du sagst es ihm. Deine Aufgabe ist nicht, mit ihm zu chatten. Deine Aufgabe ist, sein Produktmanager zu sein. Du fütterst ihn mit dem Warum hinter jeder Aufgabe, setzt die Grenzen, definierst, wie "fertig" aussieht, und überprüfst den Output gegen einen Standard, den du im Voraus festgelegt hast.

Cole nennt die Kernkompetenz hier etwas, das ich jetzt ständig verwende: die KI wie einen Mentor behandeln, während du als ihr Produktmanager agierst. Du fragst sie nicht herauszufinden, was sie bauen soll. Du überreichst ihr eine Spezifikation, die so klar ist, dass ein wörtlich denkender Junior sie nicht falsch lesen kann, und prüfst dann das Ergebnis, wie ein PM ein Feature gegen das Ticket prüft.

Sobald ich das verinnerlicht hatte, war die Frage nicht mehr "Was ist der perfekte Prompt?" sondern "Was braucht dieser Agent, um erfolgreich zu sein, und wie werde ich wissen, ob er es war?" Diese beiden Fragen reorganisieren deinen gesamten Workflow. Die erste betrifft den Kontext. Die zweite die Verifizierung. Wir verbringen den Großteil dieses Beitrags genau mit diesen Themen.

Aber bevor eines davon wichtig wird, musst du die eine Einschränkung verstehen, die alles regiert, was ein Agent tut: wie viel er tatsächlich auf einmal beachten kann.

Die "Dumb Zone": Warum ein 1-Million-Token-Kontextfenster dich anlügt

Hier ist das teuerste Missverständnis im agentischen Coding, und ich habe es länger gehalten, als mir lieb ist: Ein größeres Kontextfenster bedeutet, dass du mehr reinkippen kannst und das Modell es prima bewältigt.

Das tut es nicht. Opus 4.8 wird mit einem 1-Million-Token-Kontextfenster geliefert — dasselbe Fenster, das Anthropic in der 4.x-Linie beibehalten hat, bestätigt beim 4.8-Release am 28. Mai 2026. Eine Million Tokens klingt nach unendlichem Spielraum. Aber die Zahl, die du hineinpassen kannst, und die Zahl, über die das Modell genau schlussfolgern kann, sind nicht dieselbe Zahl, und die Lücke dazwischen ist, wo Projekte leise auseinanderfallen.

Was Cole die Dumb Zone nennt, entspricht genau dem, was ich in der Praxis sehe: irgendwo jenseits von etwa 250.000 Tokens an angesammeltem Kontext beginnt die Genauigkeit nachzulassen. Nicht katastrophal — das ist die Falle. Das Modell gibt keinen Fehler aus. Es wird einfach subtil schlechter. Es beginnt, eine Einschränkung zu vergessen, die du vor vierzig Nachrichten gesetzt hast. Es liest eine Datei falsch, die es eine Stunde zuvor korrekt gelesen hat. Es "hilft" durch das Bearbeiten von etwas, das du ausdrücklich gesagt hast, in Ruhe zu lassen. Das Fenster ist nicht voll, also nimmst du an, es sei alles in Ordnung. Ist es nicht. Du bist in der Dumb Zone.

Ich habe das auf die harte Tour bei einem Laravel-Refactoring über meine Markenseiten gelernt. Ich ließ eine lange Sitzung den größten Teil eines Nachmittags laufen, fütterte Datei um Datei, dem riesigen Fenster vertrauend. Gegen Stunde drei begann der Agent einen Bug wieder einzuführen, den ich ihn zwei Stunden zuvor hatte fixen lassen — weil dieser Fix jetzt unter 300K Tokens an nachfolgendem Rauschen begraben lag und er die Lektion effektiv "vergessen" hatte, obwohl das Gespräch sie technisch noch enthielt.

Die Regel, die ich jetzt befolge, ist unverblümt: Halte den Kontext bewusst schlank. Behandle das nutzbare Arbeitsfenster als weit kleiner als das beworbene. Drei Gewohnheiten setzen dies durch:

• Lösche aggressiv zwischen unzusammenhängenden Aufgaben. In dem Moment, in dem ein logischer Arbeitsabschnitt fertig ist, setze ich zurück, statt den Ballast in den nächsten mitzunehmen. Ich habe das gesamte Argument dafür in meiner Aufschlüsselung der Claude Code Slash-Befehle, die ich tatsächlich täglich benutze geschrieben — /clear ist der eine, den ich behalten würde, wenn ich nur einen behalten dürfte.
• Lass den Agenten nicht lesen, was er nicht braucht. Jede Datei, die er öffnet, um "die Codebasis zu verstehen", sind ausgegebene Tokens und verdünnte Aufmerksamkeit. Zeig ihm die drei Dateien, die wichtig sind, nicht das ganze Repo.
• Lege dauerhaftes Wissen in CLAUDE.md ab, nicht im Chat. Architektur, Konventionen, Schema — das gehört in den Projektspeicher, wo es ein Clear überlebt und nicht in einem driftenden Gespräch verrottet.

Die Dumb Zone ist der Grund, warum jede fortgeschrittene Technik in diesem Beitrag existiert. Harnesses, Sub-Agenten, der Ralph-Loop — streiche den Fachjargon und es ist alles derselbe Zug: Halte den Kontext jedes einzelnen Agenten klein genug, um scharf zu bleiben. Wenn du das einmal siehst, ergibt der Rest der Architektur Sinn.

Wenn also der Kontext die Einschränkung ist, wo geht die Arbeit dann eigentlich hin? In die Planung — lange bevor eine einzige Zeile geschrieben wird.

Plane mehr als du baust: Die Spezifikation ist die eigentliche Arbeit

Die kontraintuitivste Lektion: Je besser ich im Steuern von Agenten werde, desto weniger meiner Zeit geht dafür drauf, ihnen beim Coden zuzusehen, und desto mehr geht in die Planung, bevor sie anfangen. Bei einem bedeutenden Feature verbringe ich jetzt den Großteil meiner aktiven Zeit mit der Spezifikation und fast nichts mit dem Beaufsichtigen des Builds.

Das fühlt sich falsch an, wenn man mit dem Schreiben von Code von Hand aufgewachsen ist, wo Planung eine Steuer war, die man vor der "eigentlichen" Arbeit zahlte. Mit Agenten kehrt sich das um. Der Agent tippt in Minuten. Der Plan bestimmt, ob diese Minuten etwas produzieren, das du auslieferst, oder etwas, das du wegwirfst. Der Plan ist die eigentliche Arbeit.

Eine Spezifikation, die einen Agenten tatsächlich steuert, hat vier Teile, und ich habe angefangen, alle vier explizit zu schreiben:

1. Absicht — das Warum. Nicht nur "baue eine Abrechnungsseite", sondern "baue eine Abrechnungsseite, damit bestehende Kunden ohne Kontaktaufnahme mit dem Support Tiers upgraden können, weil Support-Tickets für Upgrades zwei Stunden pro Tag kosten." Wenn der Agent das Warum kennt, trifft er bessere Mikroentscheidungen bei den tausend Dingen, die du nicht spezifiziert hast. Cole nennt das Intent-Engineering, und es ist der Satz mit dem größten Hebel in jedem Prompt. Der Agent füllt Lücken in Richtung deiner erklärten Absicht, statt zu raten.
2. Der Plan — das Wie. Die beteiligten Dateien, die Reihenfolge der Operationen, der Ansatz, den du gewählt hast, und die, die du abgelehnt hast. Ich spezifiziere lieber zu viel, als mitten im Build zu entdecken, dass der Agent eine Architektur erfunden hat, die ich nie genehmigt hätte.
3. Erfolgskriterien — die Definition von fertig. Konkrete, überprüfbare Bedingungen. "Das Tier-Upgrade aktualisiert das Abonnement in Stripe, wird sofort im Dashboard angezeigt und sendet keinen doppelten Webhook." Wenn ich die Erfolgskriterien nicht schreiben kann, verstehe ich die Aufgabe nicht gut genug, um sie zu delegieren.
4. Validierungsstrategie — wie es überprüft wird. Festgelegt vor dem Build, nicht danach. Welche Unit-Tests, welcher Browser-Flow, welche manuelle Prüfung. Wir gehen gleich tiefer darauf ein, weil hier die echte Zuverlässigkeit herkommt.

Ein Hinweis zu Tooling, weil Cole das ansprach und ich mich dem angeschlossen habe: Er bevorzugt es, seine eigenen kontrollierten Planungs-Prompts zu schreiben, statt sich komplett auf eingebaute Plan-Modi zu verlassen, wegen der Flexibilität. Ich benutze den Plan-Modus von Claude Code ständig — er ist wirklich gut, und die Planungsphase bekommt jetzt ihren eigenen dedizierten Agenten, damit Recherche den Hauptkontext nicht verschmutzt. Aber für alles Knifflige schreibe ich eine Spezifikation von Hand als Markdown-Datei und lasse den Agenten dagegen arbeiten, weil ich jedes Wort davon kontrolliere. Der eingebaute Modus ist der schnelle Weg; die benutzerdefinierte Spezifikation ist der präzise. Nutze den schnellen Weg, bis Präzision wichtig wird, dann wechsle.

Hier ist der Teil, der mich überrascht hat. Die Spezifikation so gründlich zu schreiben hat mich insgesamt nicht verlangsamt. Es hat mein Denken nach vorne verschoben, wo es günstig ist, statt nach hinten, wo eine falsche Annahme bedeutet, fertigen Code herauszureißen. Wenn du jemals das Gefühl hattest, dass Claude Code es "fast" hatte, aber den Punkt immer wieder verfehlt hat, ist das fehlende Stück fast immer eine dünne Spezifikation.

Nun — selbst eine perfekte Spezifikation produziert einen ersten Entwurf, der häufiger falsch als richtig ist. Das ist kein Planungsfehler. Das ist einfach der Boden. Die Frage ist, wie du von diesem Boden zu etwas Vertrauenswürdigem kommst.

Wie verifizierst du, ob KI-generierter Code tatsächlich korrekt ist?

Du verifizierst KI-generierten Code, indem du automatisierte Prüfungen baust, die der Agent gegen seinen eigenen Output laufen lässt — Unit-Tests, Browser-Automatisierung und benutzerdefinierte Harnesses — damit er seine eigenen Fehler fängt und behebt, bevor du sie je überprüfst. Erstversuch-Agenten-Output landet bei etwa 65–70% Korrektheit bei echten Aufgaben; eine solide Selbstverifizierungsschicht schiebt das über 92%. Dieser Sprung ist das gesamte Spiel.

Lass diese Zahlen auf dich wirken, denn sie rahmen alles neu. Wenn du dem ersten Versuch vertraust, lieferst du Arbeit aus, die zwei Drittel der Zeit richtig ist. Wenn du den Agenten sich selbst prüfen lässt, lieferst du Arbeit aus, die neun von zehn Mal richtig ist — ohne mehr von deiner Aufmerksamkeit auszugeben. Der Agent macht die Nacharbeit. Du musst ihm nur einen Spiegel geben.

Die Verifizierungsschicht hat drei Stufen, die ich jetzt ungefähr in dieser Reihenfolge aufbaue:

Unit-Tests. Die Grundlinie. Ich lasse den Agenten Tests gegen die Erfolgskriterien schreiben, sie ausführen, und beheben, was fehlschlägt — in einer Schleife, ohne mich. Der Schlüssel ist, dass die Tests die Spezifikation kodieren, nicht das, was der Agent zufällig implementiert hat. Tests, die im Nachhinein geschrieben werden, bestätigen nur die Bugs des Agenten. Tests, die aus den Erfolgskriterien geschrieben werden, fangen sie.

Browser-Automatisierung. Für alles mit einer Benutzeroberfläche reichen Unit-Tests nicht aus. Ich binde Playwright ein, damit der Agent die Seite tatsächlich bedienen kann — klicke den Upgrade-Button, bestätige, dass das Dashboard aktualisiert wird, prüfe, ob kein doppelter Webhook gefeuert wurde. Der Agent sieht das tatsächliche Verhalten, statt abstrakt darüber zu schlussfolgern. Diese einzelne Ergänzung hat eine ganze Kategorie von "es hat Tests bestanden, aber der Button hat nichts gemacht"-Fehlern behoben.

Benutzerdefinierte Harnesses. Das ist der fortgeschrittene Zug und der, bei dem ich grinsen musste, als ich Cole ihn das erste Mal beschreiben hörte. Manchmal kann das, was du baust, nicht mit einem normalen Test geprüft werden — es ist interaktiv, Echtzeit oder visuell. Sein Beispiel blieb mir im Gedächtnis: Um einen Agenten ein Videospiel debuggen zu lassen, verlangsamte er die Bildrate des Spiels, damit der Agent Zeit hatte, jedes Bild zu beobachten und zu reagieren. Das ist ein Harness — ein maßgeschneidertes Rig, das den Benutzer simuliert und den Agenten wahrnehmen und auf das reagieren lässt, was tatsächlich passiert. Das Prinzip verallgemeinert: Wenn der Agent etwas nicht verifizieren kann, baue ihm eine Möglichkeit, es wahrzunehmen, und jetzt kann er es.

Das ist auch genau die Art von Urteilskraft, die das Steuern eines Agenten vom Beaufsichtigen unterscheidet. Ich ging tiefer in die umgebende Tooling in meinem Stück über die Werkzeuge, die Claude Codes KI-Schrott beheben — der meiste "Schrott" ist kein Modellproblem, es ist eine fehlende Verifizierungsschicht.

Wenn du diese Gerüste lieber nicht selbst baust, ist das genau die Art von agentischer Infrastruktur, die mein Team für Kunden aufbaut — das Design der Spezifikations-, Verifizierungs- und Harness-Schicht, damit die Agenten in der Produktion zuverlässig bleiben. Du kannst die Art von Builds, die ich annehme, auf fiverr.com/s/EgxYmWD sehen.

Sobald ein Agent sich selbst zuverlässig verifizieren kann, eröffnet sich eine größere Idee: Was, wenn du mehrere verketttest, jeder in seinem eigenen schlanken Kontext, und saubere Arbeit die Linie hinunterreicht?

Harness-Engineering und der Ralph-Loop

Ein Harness ist in dieser Welt die Orchestrierungsschicht um deine Agenten — wie du sie laufen lässt, in welcher Reihenfolge, mit welchen Übergaben und welche Prüfungen dazwischen laufen. Cole rahmt es als das Fundament, das du zuerst baust, mit einer "KI-Schicht" aus Skills, Hooks und MCP-Servern darauf gestapelt. Wenn du den Harness richtig hinbekommst, wird alles darüber zuverlässiger.

Der Grund, warum Harnesses wichtig sind, kommt direkt auf die Dumb Zone zurück. Ein einzelner Agent, der sich durch eine große Aufgabe arbeitet, akkumuliert Kontext, bis er degradiert. Aber wenn du die Arbeit in Phasen aufteilst und jeder Phase ihren eigenen Agenten mit ihrem eigenen frischen Kontext gibst, driftet kein einzelner Agent jemals in die Dumb Zone. Jeder erledigt eine Aufgabe scharf und übergibt dann.

Die sauberste Version davon ist, was die Community den Ralph-Loop nennt — eine Technik, die ursprünglich von Geoffrey Huntley im Jahr 2025 popularisiert und jetzt in Claude-Code-Muster eingebettet wurde. Stell dir ein Fließband vor. Ein Agent plant. Er übergibt eine saubere Spezifikation an einen zweiten Agenten, der implementiert. Der übergibt an einen dritten, der testet und fixt. Jede Station besitzt eine Phase, empfängt sauberen Input, produziert sauberen Output und — entscheidend — startet frisch, sodass der Kontextaufbau der Planungsphase die Testphase nie belastet.

Ich betreibe jetzt ständig eine manuelle Version davon. Selbst ohne ausgefallene Orchestrierung hält die Disziplin von "planen in einer Sitzung, löschen, implementieren in der nächsten, löschen, verifizieren in einer dritten" jeden Schritt scharf. Die dynamischen Workflows von Opus 4.8 haben das weitergebracht — eine einzelne Sitzung kann jetzt viele parallele Sub-Agenten starten, jeder mit seinem eigenen Kontextfenster, und die Ergebnisse aggregieren. Ich habe aufgeschlüsselt, was das erschließt, in meinem Walkthrough von Claude Codes dynamischen Workflows.

Sequenziell vs. parallel ist die Wahl, die du mit einem Harness triffst:

• Sequenziell (der Ralph-Loop) wenn jede Phase von der letzten abhängt — planen, dann bauen, dann testen. Saubere Übergaben, kein Abdriften, läuft lange autonom.
• Parallel wenn sich die Arbeit in unabhängige Teile aufteilt — drei Sub-Agenten, die gleichzeitig drei verschiedene Bibliotheken recherchieren und dann berichten. Schneller, aber sie können nicht einfach miteinander kommunizieren, daher am besten für Auffächern-dann-Sammeln-Arbeit.

Ehrliche Warnung: Harness-Engineering ist der Punkt, an dem dies aufhört, beiläufig zu sein. Du schreibst jetzt Orchestrierung, verwaltest Übergabeformate, debugst, welche Station kaputt gegangen ist. Es ist echtes Engineering. Die Belohnung sind Agenten, die stundenlang zuverlässig laufen, statt dich alle fünf Minuten zu brauchen — aber du greifst nicht bei einem schnellen Fix danach. Du greifst danach, wenn die Aufgabe groß genug ist, dass das Beaufsichtigen mehr kosten würde als der Bau des Rigs.

Es gibt noch eine Denkverschiebung, die mit all dem zusammenwirkt, und es ist diejenige, die leise mein gesamtes Setup im Laufe der Zeit verbessert hat.

Behandle jeden Fehler als ein permanentes Upgrade

Hier ist die Gewohnheit, die die Entwicklung meines Systems mehr verändert hat als jedes einzelne Feature: Jedes Mal, wenn ein Agent Mist baut, behebe ich nicht nur den Output — ich behebe das System, damit genau dieser Fehler nie wieder passieren kann.

Der Agent hat Code generiert, der meine Namenskonvention verletzt hat? Ich benenne es nicht nur um. Ich füge die Konvention zu CLAUDE.md hinzu. Der Agent vergisst ständig, Migrationen nach einer Schemaänderung auszuführen? Ich füge einen Hook hinzu, der den Commit blockiert, bis Migrationen gelaufen sind. Der Agent hat einen Fachbegriff falsch verstanden? Ich schreibe einen Glossareintrag in einem Absatz. Jeder Fix ist ein Baustein. Über Monate werden die Bausteine zu einer Mauer, die Probleme fängt, bevor ich sie je sehe.

Cole rahmt dies als System-Evolutions-Denkweise, und es ist der Unterschied zwischen einem Setup, das mittelmäßig bleibt, und einem, das sich aufbaut. Die meisten Leute beheben dieselbe Fehlerklasse fünfzig Mal, weil sie jede Instanz als isoliert behandeln. Der aufbauende Zug ist, zwei Extra-Minuten damit zu verbringen, jeden Fehler in eine Regel, ein Dokument oder einen Validierungsschritt umzuwandeln. Das fünfzigste Mal tritt das Problem einfach nicht auf — das System hat die Lektion dauerhaft absorbiert.

Deshalb betone ich immer wieder CLAUDE.md und Verifizierung. Sie sind keine Einrichtungsarbeiten. Sie sind das Gedächtnis jedes Fehlers, den deine Agenten gemacht haben, kodiert, damit sie sich nicht wiederholen. Ein sich selbst verbesserndes Setup ist keine Magie — es ist einfach diese Gewohnheit, gnadenlos angewandt. Ich ging tiefer in diesen Kaninchenbau in meinem Post über den Aufbau sich selbst verbessernder Claude-Code-Systeme, aber der Kern ist dieser Absatz.

Es gibt jedoch eine Kategorie von Fehlern, bei der "behebe es beim nächsten Mal" nicht gut genug ist — weil die Kosten des ersten Mals katastrophal sind. Sicherheit.

Sicherheit: Warum "lösche nicht die Datenbank" keine Berechtigung ist

Das ist die Lektion, von der ich am meisten möchte, dass die Leute sie ernst nehmen, denn sie ist die mit Zähnen. Einem Agenten in einem Prompt zu sagen "lösche nicht die Produktionsdatenbank" ist keine Sicherheitskontrolle. Es ist ein Vorschlag. Und ein Agent, der die Anweisung hat, ein Ziel zu erreichen, kann und wird manchmal einen kreativen Weg um deinen Vorschlag herum finden.

Denke darüber nach, was ein Agent eigentlich ist: ein System, das Code schreibt und ausführt, um ein Ziel zu erreichen. Wenn das Löschen und Neuerstellen einer Tabelle der Weg des geringsten Widerstands ist, um einen Test bestehen zu lassen, kann ein hinreichend entschlossener Agent sich seinen Weg dorthin skripten — selbst nachdem du "fass die Datenbank nicht an" getippt hast. Die Anweisung lebt im Prompt, der nur Text ist, gegen den das Modell schlussfolgern, den es uminterpretieren oder stillschweigend unter Druck deprioritisieren kann. Prompt-basierte Leitplanken bestehen aus demselben Material wie das, was du einzuschränken versuchst.

Echte Kontrollen leben unter dem Prompt, im Harness:

• Hooks. Ein Hook ist ein kleines Programm, das an einem bestimmten Punkt im Lebenszyklus des Agenten läuft — denke an Git-Hooks, aber für KI. Ein Pre-Execution-Hook kann einen Befehl vor der Ausführung inspizieren und alles, was einem gefährlichen Muster entspricht, hart blockieren (ein DROP, ein rm -rf, ein Schreibvorgang auf einen geschützten Pfad). Der Agent bekommt keine Chance, an einem Hook vorbeizureden. Der Hook ist Code, und Code verhandelt nicht. Das ist strukturell anders als eine Prompt-Anweisung, und deshalb sind Hooks nicht verhandelbar für alles in der Nähe von Produktion.
• Strikte Berechtigungsscopes. Gib dem Agenten keinen breiten Zugang und vertraue darauf, dass er sich benimmt. Beschränke ihn auf genau das, was die Aufgabe braucht — dieses Verzeichnis, diese Befehle, nicht mehr. Der engste tragfähige Berechtigungssatz ist dein echtes Sicherheitsnetz.

Ich behandle das mit der gleichen Ernsthaftigkeit, mit der ich jeden Produktionszugang behandeln würde. Wenn du Agenten in der Nähe echter Systeme und echter Daten laufen lässt, ist die Sicherheitshaltung dieser Agenten eine echte Angriffsfläche — und es ist genau die Art von Ding, die xCyberSecurity für Unternehmen bewertet, die KI-Tooling einführen. Ein Agent mit Datenbankzugang und nur prompt-basierten Leitplanken ist eine Sicherheitslücke, die auf einen schlechten Tag wartet.

Sicherheit abgehakt, es gibt ein leiseres Risiko, das sich über Monate einschleicht: nicht zu wissen, was die eigene Codebasis eigentlich tut.

Das Problem des "dunklen Codes": Verstehe, was der Agent schreibt

Der verführerische Fehlermodus des agentischen Codings ist Code auszuliefern, den du nie gelesen hast. Er funktioniert, die Tests bestehen, du machst weiter. Multipliziere das mit ein paar hundert Merges und du hast eine Codebasis, die für ihren eigenen Besitzer eine Blackbox ist — was manche Leute dunklen Code nennen. Am Tag, an dem etwas kaputtgeht, debugst du ein System, das du nicht verstehst, geschrieben von einem Agenten, der sich nicht erinnert, es geschrieben zu haben.

Ich ziehe jetzt eine Linie: Ich versuche zumindest zu verstehen, was der Agent produziert. Nicht jede Zeile Boilerplate, aber die Architektur, die nicht offensichtlichen Entscheidungen, alles, was Daten, Geld oder Authentifizierung betrifft. Der Trick, auf den ich mich stütze, sind Nebengespräche — eine Begleitsitzung oder separate Sitzung, in der ich den Agenten bitte, einen Codeabschnitt zu erklären, ohne diese Erklärung in meinen Hauptarbeitskontext zu dumpen. Ich bekomme Verständnis, ohne das Kontextfenster zu verschmutzen, das mit dem Bauen beschäftigt ist. Es hält den Hauptagenten schlank, während mein eigenes mentales Modell aktuell bleibt.

Ein ehrlicher Hinweis für die Nicht-Coder, die das lesen — und es werden jeden Monat mehr von euch im agentischen Coding: Wenn du den Code wirklich nicht lesen kannst, muss dein Sicherheitsnetz rigorose Validierung sein, nicht Bauchgefühl. Stütze dich stärker auf die Verifizierungsschicht, als ein Entwickler es tun würde. Wenn du den Motor nicht inspizieren kannst, solltest du besser ausgezeichnete Instrumente auf dem Armaturenbrett haben. Die Validierung ist für dich nicht optional; sie ist tragend.

Verstehen ist eine Aufgabe. Manchmal ist die Aufgabe jedoch schwierigeres Denken — eine echte Entscheidung mit Abwägungen, bei der die selbstsichere Antwort eines einzelnen Agenten genau das ist, was du nicht vertrauen solltest. Da beweisen Agententeams ihren Wert.

Agententeams und Sub-Agenten: Wann man eine Menge aufbietet

Zwei Werkzeuge im Kasten werden ständig verwechselt, also lasse mich die Linie klar ziehen, denn sie lösen verschiedene Probleme.

Sub-Agenten sind leichtgewichtige Agenten, die du für fokussierte, isolierte Arbeit aufbietest — meist Recherche oder Kontextsammlung. Du schickst einen los, um drei konkurrierende Bibliotheken zu untersuchen und die Abwägungen zu berichten. Jeder läuft in seinem eigenen Kontextfenster, das ist der ganze Punkt: Er erledigt die schwere Lesearbeit, damit dein Hauptagent schlank bleibt. Sie sind Token-intensiv und ihre Rückmeldung ist begrenzt, aber für Auffächern-Recherche sind sie ausgezeichnet. Opus 4.8 kann jetzt Hunderte davon parallel in einer einzelnen Sitzung laufen lassen.

Agententeams sind ein anderes Tier. Hier bietest du mehrere persona-basierte Agenten auf und lässt sie beraten — eine Entscheidung debattieren, Grenzfälle bestreiten, einander herausfordern. Das ist das Gegenmittel zu einer der gefährlichsten Eigenschaften eines einzelnen Agenten: Unterwürfigkeit. Frag einen Agenten, ob dein Plan gut ist, und er neigt dazu, dir zuzustimmen. Stelle ein adversariales Team auf — eines argumentiert für den Ansatz, eines sucht nach allem, was daran falsch ist — und die Meinungsverschiedenheit bringt Grenzfälle und Fehlermodi zum Vorschein, an denen ein einzelner freundlicher Agent vorbeigelächelt hätte.

Ich benutze Agententeams für wirklich folgenreiche Entscheidungen — eine Architekturwahl, mit der ich ein Jahr leben muss, ein Sicherheitsmodell, einen Migrationsplan. Das adversariale Debatte ist, wo ich meine schlimmsten Annahmen ertappt habe. Aber ich bin ehrlich über die Kosten: Das ist sehr Token-intensiv. Mehrere Agenten, die parallel argumentieren, verbrennen den Verbrauch schnell. Es ist ein Präzisionsinstrument für Entscheidungen mit hohem Einsatz, kein Standard. Für Routinearbeit ist es übertrieben. Ich ging tiefer auf Multi-Agenten-Orchestrierung in meiner Aufschlüsselung der Claude Code Agenten-Schwarm-Architektur ein, wenn du die strukturellen Details willst.

Also welche Features tragen die Last Tag für Tag? Nach Monaten davon stechen drei hervor.

Die drei Claude-Code-Features, die am meisten zählen

Cole nannte seine Top drei Claude-Code-Features, und nachdem ich meine eigenen Marken auf diesem Setup laufen lasse, lande ich an der gleichen Stelle. Das sind die, die die echte Arbeit machen:

1. Skills. Wiederverwendbare, parametrisierte Prompts, die du namentlich aufrufst. Statt jedes Mal eine komplexe Anweisung neu zu tippen, speicherst du sie einmal und rufst sie wie eine Funktion auf. So hört ein Workflow auf, etwas zu sein, das du dir merkst, und wird zu etwas, das das System weiß. Ich habe Skills für alles gebaut, von SEO-Entwürfen bis hin zu Deployment-Checks über meine Seiten.
2. Hooks. Event-getriggerte Code, der an definierten Punkten im Lebenszyklus des Agenten läuft. Wir haben ihre Sicherheitsrolle behandelt, aber sie sind ebenso mächtig für Qualität — automatische Formatierung beim Speichern, Tests vor einem Commit laufen lassen, einen Merge blockieren, der eine Prüfung nicht besteht. Mechanische Garantien, keine hoffnungsvollen Anweisungen.
3. Sub-Agenten. Fokussierte Recherche und Kontextsammlung in isolierten Fenstern, die deinen Hauptagenten scharf halten. Die Dumb-Zone-Verteidigung, operationalisiert.

Beachte den roten Faden. Skills machen deine Workflows wiederholbar. Hooks machen deine Garantien mechanisch. Sub-Agenten halten deinen Kontext schlank. Keines davon geht darum, das Modell "schlauer" zu machen — sie gehen darum, ein System um das Modell herum zu bauen, das zuverlässig bleibt. Das ist die gesamte Philosophie in drei Features.

So würde ich also all das in die Praxis umsetzen, ab morgen.

Die Regisseur-Checkliste, die ich tatsächlich verwende

Pinne das an. Es ist das Betriebsverfahren, das ich jetzt bei jeder nicht-trivialen Aufgabe durchführe:

• Plane mehr als du baust. Schreibe Absicht, Plan, Erfolgskriterien und Validierungsstrategie, bevor der Agent eine Zeile schreibt. Wenn du die Erfolgskriterien nicht schreiben kannst, bist du nicht bereit zu delegieren.
• Halte den Kontext schlank. Behandle das nutzbare Fenster als Bruchteil der beworbenen 1 Million. Lösche zwischen Aufgaben. Lass den Agenten nicht lesen, was er nicht braucht. Bleib aus der Dumb Zone.
• Baue automatisierte Verifizierung. Unit-Tests aus der Spezifikation, Playwright für UI, benutzerdefinierte Harnesses für alles Interaktive. Verschiebe die Erstversuch-Korrektheit von ~65% auf 92%+, ohne deine eigene Aufmerksamkeit zu investieren.
• Designe Harnesses mit sauberen Übergaben. Ralph-Loop für sequenzielle Phasen, parallele Sub-Agenten für unabhängiges Auffächern. Jeder Agent bleibt schlank.
• Behandle jeden Fehler als permanentes Upgrade. Jeder Bug wird eine Regel, ein Dokument oder ein Hook. Das System baut sich auf.
• Sperre Sicherheit unter dem Prompt ab. Hooks für harte Blockaden, strikte Berechtigungsscopes. "Lösche nicht die Datenbank" ist keine Kontrolle.
• Verstehe den Code. Nutze Nebengespräche zum Lernen, ohne Kontext zu verschmutzen. Nicht-Coder: stütze dich stärker auf Validierung.
• Nutze Agententeams für Entscheidungen mit hohem Einsatz. Adversariales Debatte tötet Unterwürfigkeit und bringt Grenzfälle zum Vorschein. Token-intensiv — spare es für Entscheidungen, die zählen.
• Füttere das Warum. Intent-Engineering. Jede Aufgabe trägt ihren Zweck. Der Agent füllt Lücken in Richtung deiner Absicht.

Der Faden, der alle neun verbindet, ist die eine Idee, mit der ich begonnen habe: Du bist der Regisseur. Der Produktmanager. Der Mentor, der einem brillanten, wörtlichen, vergesslichen Junior genau das gibt, was er braucht, um erfolgreich zu sein — und das Ergebnis gegen einen Standard prüft, den du im Voraus festgelegt hast.

Erinnerst du dich an den Produktions-Build, den ich um 23 Uhr kaputt gemacht habe? Den mit der Zeile, die ich nie gelesen hatte? Ich denke immer noch darüber nach, aber nicht mehr mit Bedauern. Es war der Abend, an dem ich aufhörte, Passagier zu sein. Am nächsten Morgen schrieb ich meine erste echte Spezifikation, fügte meinen ersten Hook hinzu und begann den Agenten als das zu behandeln, was er wirklich ist — kein magischer Coder, sondern ein System, für dessen gute Steuerung ich verantwortlich bin.

Also hier ist die eine Sache, die du in den nächsten 24 Stunden tun solltest: Nimm die repetitivste Aufgabe, die du derzeit durch Prompten erledigst, und schreibe ihr eine echte Spezifikation — Absicht, Plan, Erfolgskriterien, Validierung. Nur eine. Dann beobachte, wie anders sich der Agent verhält, wenn du aufhörst, mit ihm zu chatten, und anfängst, ihn zu dirigieren. Diese eine Übung ist, wo der Rollenwechsel beginnt.

Häufig gestellte Fragen

Was bedeutet es, einen KI-Coding-Agenten zu steuern?

Einen KI-Coding-Agenten zu steuern bedeutet, die Verantwortung für Absicht, Plan, Erfolgskriterien und Verifizierung zu übernehmen, während der Agent das Tippen erledigt. Du agierst als Produktmanager und Regisseur statt als Gesprächspartner — du fütterst dem Agenten das Warum hinter jeder Aufgabe und prüfst seinen Output gegen einen Standard, den du im Voraus festgelegt hast. Siehe den Planungsabschnitt oben für die vierteilige Spezifikation, die ich verwende.

Was ist die "Dumb Zone" in einem Kontextfenster?

Die Dumb Zone ist der Punkt jenseits von ungefähr 250.000 Tokens, an dem die Genauigkeit eines Modells leise nachlässt — Einschränkungen vergisst und Dateien falsch liest — obwohl das 1M-Token-Fenster nicht voll ist. Die Gefahr ist, dass es nie einen Fehler ausgibt; es wird einfach subtil schlechter. Halte den Kontext schlank, um draußen zu bleiben.

Wie genau ist KI-generierter Code beim ersten Versuch?

Erstversuch-KI-Coding-Agenten-Output ist bei echten Aufgaben ungefähr 65–70% korrekt. Das Hinzufügen einer Selbstverifizierungsschicht — Unit-Tests, Browser-Automatisierung und benutzerdefinierte Harnesses — schiebt das über 92%, weil der Agent seine eigenen Fehler fängt und behebt, bevor du sie überprüfst. Der Verifizierungsabschnitt oben schlüsselt auf, wie man jede Stufe baut.

Was ist der Ralph-Loop in Claude Code?

Der Ralph-Loop ist ein Fließband-Workflow, bei dem jeder Agent eine Phase besitzt — planen, bauen, testen — und sauberen Output an den nächsten weitergibt, wobei jeder mit frischem Kontext startet. Von Geoffrey Huntley im Jahr 2025 popularisiert, hält er jeden einzelnen Agenten während langer autonomer Läufe aus der Dumb Zone.

Sind Prompt-Anweisungen ausreichend, um einen KI-Agenten sicher zu halten?

Nein. Einem Agenten im Prompt zu sagen "lösche nicht die Datenbank" ist ein Vorschlag, keine Kontrolle — ein zielgetriebener Agent kann seinen Weg drum herum skripten. Echte Sicherheit kommt von Hooks (kleinen Programmen, die gefährliche Befehle vor der Ausführung hart blockieren) und strikten Berechtigungsscopes, die einschränken, was der Agent überhaupt anfassen kann.

Lass uns zusammenarbeiten

Du willst KI-Systeme bauen, Workflows automatisieren oder deine technische Infrastruktur skalieren? Ich helfe dir gerne.

• Fiverr (maßgeschneiderte Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io