Der Spickzettel für die Seite vor dem Agentenlauf: Welches Werkzeug passt, wie ist der Auftrag geschnitten, was steht in der Projektanweisung, welche Rechte bekommt der Agent. Die Methode bringt er nicht bei — dafür ist das Seminar Clean Code und KI-gestützte Entwicklung da. Das Gegenstück für die Seite danach ist das Blatt Prüfen und sauber halten.
Werkzeug nach Aufgabe wählen
Der Agent ist nicht die gehobene Variante des Chats. Die Wahl folgt der Frage, nicht der Gewohnheit.
| Art | Kennt | Stark bei | Schwach bei |
|---|---|---|---|
| Chat | nur Hineingeschriebenes | allgemeinen Konzepten | Projektbesonderheiten |
| IDE-Assistent | offene Dateien | kurzen Änderungen | weit verstreutem Kontext |
| Agent | das Repository | Erkunden und Umbauen | ungewolltem Zusatzumfang |
Mit der Stufe wandert der Zeitpunkt, an dem Verantwortung sichtbar wird: bei der Vervollständigung beim Tippen, beim Dialog beim Einfügen, beim Agenten erst im Review.
Wofür sich KI eignet — und unter welcher Bedingung
| Aufgabe | Eignung | Bedingung |
|---|---|---|
| Erklären und Erkunden | hoch | Aussagen am Quellcode gegenprüfen |
| Planen | hoch | der Plan wird geprüft, nicht abgenickt |
| Reviewen | hoch | zweite Meinung, nicht einzige |
| Implementieren | mittel | klar umrissen, Erfolgskriterium sichtbar |
| Refaktorieren | mittel | Verhalten vorher abgesichert |
| Testen | heikel | Tests gegen die Anforderung, nicht den Code |
| Anforderung aushandeln | gering | bleibt beim Menschen |
Testen ist heikel, weil aus vorhandenem Code abgeleitete Tests das aktuelle Verhalten festschreiben — Fehler eingeschlossen.
Modul: Softwareentwicklung mit Coding-Assistenten und Agenten
Vom Wunsch zur ausführbaren Aufgabe
Ein Symptom ist kein Auftrag. Erst ab der dritten Ebene kann jemand Lösungen ausschließen, die das Ziel verfehlen.
| Ebene | Beispiel |
|---|---|
| Symptom | Die Abrechnung ist zu langsam |
| Problem | Der Monatslauf blockiert die Verwaltung am Monatsersten |
| Ziel | Der Lauf soll unter fünf Minuten bleiben |
| Gewünschtes Verhalten | Die Verwaltung kann währenddessen weiterarbeiten |
Kriterium, Beispiel, Gegenbeispiel
Ohne das Gegenbeispiel baut jeder Bearbeiter — Mensch wie Agent — eine Regel, die zu viel verbietet.
| Rolle | Fall |
|---|---|
| Kriterium | Überschneidende Buchungen werden abgelehnt |
| Beispiel | Zwei Buchungen desselben Fahrzeugs am selben Vormittag |
| Gegenbeispiel | Eine Buchung innerhalb eines Werkstatttermins ist zulässig |
Nicht-Ziele auf drei Ebenen
Ohne Angabe entscheidet der Bearbeiter sich im Zweifel für die Zusatzverbesserung — und macht das Ergebnis unprüfbar. Die strukturelle Ebene wird am häufigsten vergessen.
| Ebene | Beispiel |
|---|---|
| Fachlich | Die Privatnutzungsberechnung bleibt unverändert |
| Strukturell | Es werden keine neuen Abstraktionsebenen eingeführt |
| Technisch | Keine neuen Abhängigkeiten, nichts außerhalb des Buchungsmoduls |
Wie groß ein Inkrement sein darf
| Umfang je Durchgang | Trefferquote | Folgerung |
|---|---|---|
| 200 bis 400 Codezeilen | 70 bis 90 Prozent der Defekte | die wirksame Größe |
| über 400 Zeilen | fällt ab | auf zwei Durchgänge teilen |
| über 500 Zeilen je Stunde | fällt ab | nicht schneller lesen, sondern weniger |
SmartBear und Cisco, 2500 Reviews über 3,2 Millionen Zeilen. Die Studie stammt aus der Zeit vor KI — genau das macht sie belastbar.
Modul: Vom Wunsch zur ausführbaren Aufgabe
Der agentische Zyklus in neun Schritten
| Nr | Schritt | Was er liefert |
|---|---|---|
| 1 | Klären | Auftrag mit Erfolgskriterium |
| 2 | Erkunden | Landkarte des Ist-Zustands, mit Belegen |
| 3 | Annahmen und Risiken | die Liste, auf der der Plan ruht |
| 4 | Planen und prüfen | freigegebener Änderungsplan in Prosa |
| 5 | Umsetzen | die kleinste sinnvolle Änderung |
| 6 | Maschinell prüfen | Build, Tests, Linter, statische Analyse |
| 7 | Diff und Verhalten | Auftragstreue und ein eigenes Beispiel |
| 8 | Nacharbeiten | ein Punkt nach dem anderen |
| 9 | Übergeben | dokumentiertes Ergebnis |
Wer die Erkundung überspringt, plant im Nebel. Wer den Plan überspringt, prüft am Ende die falsche Frage. Der Plan gehört in Prosa — ein Plan in Code lässt sich nicht mehr fachlich beurteilen.
Warum der Umfang in den Auftrag gehört
| Mensch | Agent | |
|---|---|---|
| Zusätzlicher Schritt | kostet Zeit und Mühe | kostet praktisch nichts |
| Zusammenhang erkennen | begrenzt | sehr gut |
| Wer den Preis zahlt | er selbst | der Mensch, der prüft |
Deshalb Änderungsumfang und Dateizahl im Auftrag begrenzen — lieber zweimal beauftragen als einmal zu viel bekommen.
Git als Sicherheitsnetz
| Gewohnheit | Wirkung | Ohne sie |
|---|---|---|
| Sauberer Ausgangszustand | der Diff zeigt nur den Auftrag | der Lauf ist nicht prüfbar |
| Commit je sinnvollem Schritt | benannte Zustandsübergänge | ein großer Sprung ohne Zwischenhalt |
| Bereitschaft zu verwerfen | falsche Richtung kostet wenig | Reparatur einer untragfähigen Lösung |
Wann der Agent stoppen muss
| Kategorie | Beispiel | Warum |
|---|---|---|
| Schwer rückgängig | Migration, Löschung, Außenwirkung | der Rücksprung trägt hier nicht |
| Verträge | Schnittstellen, Formate, Ereignisse | andere hängen daran |
| Kosten und Abhängigkeiten | neue Bibliotheken | Lieferkette und Betrieb |
| Auftrag beruht auf Irrtum | die Aufgabe ist grundlegend anders | der wichtigste Punkt |
Die ersten drei decken sich mit Excessive Agency der OWASP Top 10 for LLM Applications (2026 von Platz 6 auf 3 gestiegen). Der vierte steht in keiner Liste und wird am ehesten vergessen — ein Agent meldet selten von sich aus einen Irrtum.
Modul: Der sichere agentische Entwicklungszyklus
Kontext Engineering
Ein guter Prompt hilft einmal, eine gute Umgebung bei jedem Auftrag — auch dann, wenn der Auftrag schlecht formuliert ist, und für jeden im Team gleich.
| Teil der Umgebung | Woraus er besteht | Muss geglaubt werden? |
|---|---|---|
| Was der Agent liest | Struktur, Code, Tests, Konventionen | ja |
| Was ihm gesagt wird | Projektanweisung, Regeln, Fachlichkeit | ja |
| Was er ausführen kann | Build, Tests, Linter | nein |
Der dritte Teil ist der stärkste. Kontext Engineering heißt vor allem, Wissen aus den ersten beiden dorthin zu holen.
AGENTS.md, Stand 08/2026
| Merkmal | Stand |
|---|---|
| Betreuung | Agentic AI Foundation der Linux Foundation |
| Verbreitung | von über 30 Werkzeugen gelesen, Zehntausende Repositories |
| Verschachtelung | unterstützt; die dem Code nächste Datei gewinnt |
| Empfohlener Umfang | Wurzeldatei knapp halten, nichts aus dem README doppeln |
Verbreitungszahlen sind Größenordnungen aus Sekundärquellen; Werkzeuglisten veralten schnell, die Konvention bleibt.
Die Leitfrage: Nicht aufschreiben, was der Agent ohnehin richtig rät — das kostet nur Aufmerksamkeit. Aufschreiben, was er systematisch falsch rät. Die Datei ist eine Sammlung von Ausnahmen, kein Handbuch.
Was nicht hineingehört
| Was | Warum nicht | Stattdessen |
|---|---|---|
| Geheimnisse | die Datei wird geladen, zitiert, weitergereicht | gar nicht ablegen |
| Umfangreiche Handbücher | füllen den Kontext, das Wichtige geht unter | auf die Datei verweisen |
| Was Maschinen erzwingen | Einrückung, Zeilenlänge, Anführungszeichen | Formatierer und Linter |
Lokale Regeln stehen näher am Code und veralten langsamer — sie geraten beim Ändern desselben Bereichs mit ins Blickfeld. Eine bereichsspezifische Regel global zu stellen macht sie unglaubwürdig.
Prosa gegen ausführbaren Check
| Regel in Prosa | Regel als Check | |
|---|---|---|
| Wird bemerkt | nur wenn jemand hinsieht | immer |
| Gilt für | wer sie gelesen hat | Mensch und Agent |
| Der Agent kann | sie stillschweigend brechen | sich selbst korrigieren |
| Aufwand | in jedem Review erneut | einmalig |
Zur Kontextlänge: Chroma untersuchte 2025 achtzehn Modelle — jedes wird mit wachsender Eingabe schlechter, selbst beim wortgetreuen Wiederholen von Text. Aus wachsenden Kontextfenstern folgt also nicht, dass mehr Inhalt unschädlich wäre.
Modul: Kontext Engineering für Codebasen
Rechte, Sandbox und Prompt Injection
Die beiden großen Sprünge liegen bei Befehle ausführen und Netzwerk. Erkundung braucht Leserechte, mehr nicht.
| Stufe | Was damit möglich wird |
|---|---|
| Nur lesen | Erkundung — mehr braucht sie nicht |
| Im Arbeitsverzeichnis schreiben | Änderungen, begrenzt auf ein Verzeichnis |
| Befehle ausführen | alles, was auf dem Rechner möglich ist |
| Netzwerk | Daten können das Haus verlassen |
| Auf fremde Systeme wirken | Schaden außerhalb des eigenen Zugriffs |
Woher Anweisungen kommen können
| Quelle | Wer dort schreiben kann |
|---|---|
| Fehlerbericht oder Ticket | jeder, der ein Ticket anlegen darf |
| Webseite oder Bibliotheksdokumentation | deren Betreiber, und wer sie kompromittiert |
| Kommentar im Code | jeder mit Schreibrecht im Repository |
| Ausgabe des Bauwerkzeugs | wer eine Abhängigkeit kontrolliert |
Dem Modell das Ignorieren beizubringen ist der aussichtslose Weg. Wirksam sind wenig Rechte, kein unnötiger Netzwerkzugriff und Freigabe für alles, was nach außen wirkt.
Vor dem ersten Einsatz zu klären
| Frage | Wer sie beantwortet |
|---|---|
| Auf welcher Grundlage werden die Daten verarbeitet? | Datenschutzverantwortliche |
| Wo verarbeitet das Werkzeug, speichert es, trainiert es mit? | Betriebsmodell des Anbieters |
| Ist eine betriebliche Mitbestimmung berührt? | Betriebsrat und Personalabteilung |
| Stammen Testdaten aus der Produktion? | das Entwicklungsteam selbst |
Das sind die Fragen und die Zuständigkeiten, keine rechtliche Einschätzung.
Wenn ein Secret im Repository landet: zuerst rotieren, erst danach über die Historie nachdenken. Entfernen aus dem aktuellen Stand entfernt nichts aus der Historie, jeder Klon trägt sie vollständig — ein einmal veröffentlichtes Geheimnis gilt als kompromittiert.
Modul: Sicherheit, Datenschutz und verantwortlicher Werkzeugeinsatz
Team: Definition of Done, Notizen, Metriken
| Punkt | Automatisierbar? |
|---|---|
| Der Diff wurde vollständig gelesen — nicht die Zusammenfassung | nein |
| Tests belegen die fachlichen Kriterien, nicht die Umsetzung | teilweise |
| Die automatischen Prüfungen laufen durch | ja |
| Keine unbeauftragten Änderungen enthalten | teilweise |
| Neue Abhängigkeiten begründet und freigegeben | ja |
| Die Annahmen sind festgehalten | nein |
Die beiden mit nein kosten Lesezeit und Nachdenken — deshalb fallen sie unter Druck als erste weg.
Review-Kapazität als Engpass
| Hebel | Wirkung | Fühlt sich an wie |
|---|---|---|
| Menge begrenzen | kürzere Wartezeit, gründlichere Reviews | Bremsen |
| Größe begrenzen | fünf kleine schlagen eine große | Mehrarbeit |
| Automatisieren | Aufmerksamkeit bleibt für Fachliches übrig | Vorabinvestition |
Entscheidungsnotiz
| Abschnitt | Was hineingehört |
|---|---|
| Kontext | die Kräfte, die zur Entscheidung geführt haben |
| Entscheidung | was beschlossen wurde, in ganzen Sätzen |
| Status | vorgeschlagen, angenommen, abgelöst durch |
| Konsequenzen | alle Folgen, ausdrücklich auch die unangenehmen |
Format nach Michael Nygard, Documenting Architecture Decisions (2011) — eine Seite je Entscheidung genügt. Code entsteht in Minuten, seine Begründung nur in einem Chatverlauf, und der ist morgen geschlossen.
Was misst was
| Zahl | Misst | Als Ziel |
|---|---|---|
| Erzeugte Zeilen, Annahmequote | Aktivität | schädlich |
| Dauer von der Idee bis zur Produktion | Ergebnis | brauchbar |
| Nacharbeit nach der Abnahme | Ergebnis | brauchbar |
| Reviewzeit und Fundrate | Ergebnis | brauchbar |
Auch die brauchbaren taugen als Gesprächsanlass im Team, nicht als Steuerungsgröße von außen.
Modul: Zusammenarbeit im Entwicklungsteam
Typische Fallen
- Das Werkzeug nach Verfügbarkeit wählen statt nach Zuschnitt der Aufgabe — und dem Agenten dieselbe Aufsicht zutrauen wie der Vervollständigung.
- Kriterien formulieren, die niemand nachprüfen kann: robust, sauber, performant. Und Kriterien erst nach der Umsetzung schreiben — dann beschreiben sie das Ergebnis.
- Nicht-Ziele weglassen, weil sie sich von selbst verstehen. Das tun sie nie.
- Erkunden und Ändern im selben Auftrag beauftragen — und die Landkarte für einen Befund halten statt für eine Hypothese.
- Einen Plan in Code annehmen. Dann prüft man Formulierung statt Absicht; der Denkfehler sitzt im Plan, nicht in der Ausführung.
- Den Agenten auf einem bereits veränderten Arbeitsverzeichnis loslassen — danach ist nicht mehr zuzuordnen, was von wem stammt.
- Nur ergänzen und nie streichen. Eine Projektanweisung, die nur wächst, ist ein Warnzeichen; eine Regel, die einen längst entfernten Testbefehl nennt, beschädigt die Glaubwürdigkeit der übrigen.
- Formatierungsregeln in Prosa wiederholen, obwohl ein Werkzeug sie erzwingt.
- Vorsorglich alle Rechte vergeben, damit nichts hakt — und sie nie wieder zurücknehmen.
- Zugangsdaten in die Sandbox durchreichen, weil es sonst nicht läuft. Dann ist sie keine.
- Haltepunkte erst im Einzelfall festlegen, wenn die Lage schon eskaliert ist.
- Die Annahmen nicht festhalten, weil sie beim Schreiben selbstverständlich wirkten.