Vom Wunsch zur ausführbaren Aufgabe

Vom Wunsch zur ausführbaren Aufgabe

0:00 Im vierten Modul wird es handwerklich. Es geht um den Schritt, der über Erfolg oder Misserfolg jeder KI-gestützten Änderung entscheidet und der trotzdem am häufigsten übersprungen wird: den Zuschnitt der Aufgabe. Die vier Punkte aus Modul eins — Ziel benennen, Kontext geben, Grenzen setzen, verifizieren — werden hier zu konkretem Handwerk.

0:19 Und Sie bekommen einen Satz mit, der in vielen Teams sofort etwas verändert: Die wirksamste einzelne Zeile in einem Auftrag ist meist ein Nicht-Ziel.

Vom Wunsch zur ausführbaren Aufgabe

0:28 Wir sind noch am ersten Tag, aber der Charakter ändert sich. Die ersten drei Module haben Begriffe und Maßstäbe geklärt. Ab jetzt geht es um Vorgehen. Dieses Modul und das folgende gehören eng zusammen: Hier lernen Sie, eine Aufgabe zuzuschneiden, im nächsten führen Sie sie durch einen vollständigen Zyklus. Am Ende des Tages werden Sie ein Feature komplett bearbeitet haben.

Problem, Ziel und gewünschtes Verhalten trennen

0:51 Fangen wir dort an, wo Aufgaben tatsächlich ankommen: unsauber formuliert. Kaum jemand bekommt eine fertige Anforderung auf den Tisch. Was ankommt, ist meist ein Symptom — jemand ärgert sich über etwas. Der erste Schritt besteht darin, aus diesem Ärger drei getrennte Ebenen herauszuarbeiten. Das ist die eigentliche Denkarbeit, und sie lässt sich nicht delegieren.

1:14 Die Abrechnung ist zu langsam — das ist ein Symptom, kein Auftrag. Wenn Sie das so weitergeben, an einen Menschen oder an einen Agenten, bekommen Sie irgendetwas Optimiertes zurück. Vielleicht eine Datenbankabfrage, die schneller läuft, während das eigentliche Problem bestehen bleibt. Denn nur der Mensch kann zurückfragen: Wen stört das eigentlich, wann, und was soll stattdessen möglich sein? Diese Rückfrage ist der Kern des Kapitels.

1:40 Sie kostet zehn Minuten und entscheidet über den ganzen Rest. Sehen Sie sich an, wie weit die Zeilen auseinanderliegen. Ganz oben das Symptom: Die Abrechnung ist zu langsam. Darunter das Problem — der Monatslauf blockiert die Verwaltung am Monatsersten. Das ist schon eine ganz andere Information: Es geht gar nicht um Geschwindigkeit an sich, sondern um Blockade zu einem bestimmten Zeitpunkt. Dann das Ziel, unter fünf Minuten.

2:06 Und ganz unten das gewünschte Verhalten: Die Verwaltung kann während des Laufs weiterarbeiten. Und jetzt merken Sie es selbst — die letzte Zeile lässt sich auch ohne jede Beschleunigung erfüllen. Erst ab der dritten Zeile kann jemand Lösungen ausschließen, die das Ziel verfehlen. Der Unterschied ist im Ergebnis unmittelbar sichtbar.

2:26 Ein Agent, der nur das Symptom bekommt, optimiert irgendetwas Messbares — und liefert etwas, das schneller ist und niemandem hilft. Ein Agent, der alle drei Ebenen bekommt, kann untaugliche Lösungen ausschließen. Und, das ist der unterschätzte Punkt, er kann melden, wenn keine der ihm möglichen Lösungen das Ziel erreicht.

2:45 Diese Rückmeldung ist Gold wert, und Sie bekommen sie nur, wenn das Ziel im Auftrag steht. Die Rückfrage an die Beteiligten bleibt beim Menschen — er allein kann sie stellen.

Akzeptanzkriterien, Beispiele und Gegenbeispiele

2:56 Vom Ziel zum Kriterium. Ein Ziel ist eine Richtung, ein Akzeptanzkriterium ist eine Aussage, die man nachher überprüfen kann. Der Unterschied klingt formal und ist es nicht — an ihm entscheidet sich, ob eine Abnahme überhaupt möglich ist. Und wir sehen uns eine Sorte Kriterium an, die fast immer fehlt und die trotzdem die meiste Information trägt.

3:17 Überprüfbar ist das entscheidende Wort. Die Buchung soll robust sein — das ist kein Kriterium, das ist ein Wunsch. Niemand kann hinterher sagen, ob es erfüllt ist. Eine Buchung, die sich mit einer bestehenden überschneidet, wird mit einer benannten Fehlermeldung abgelehnt — das ist eines. Man kann es hinschreiben, man kann es testen, man kann es abnehmen. Der Test dafür ist einfach: Wenn Sie ein Kriterium nicht in einen Test übersetzen können, war es keines.

3:44 Und das merken Sie besser jetzt als bei der Abnahme. Hier sehen Sie, warum Gegenbeispiele so wertvoll sind. Das Kriterium lautet: Überschneidende Buchungen werden abgelehnt. Das Beispiel macht es greifbar — zwei Buchungen desselben Fahrzeugs am selben Vormittag. Und dann kommt die Zeile, die alles verändert: Eine Buchung innerhalb eines Werkstatttermins ist zulässig, obwohl sie sich überschneidet.

4:08 Ohne diese eine Zeile baut jeder Bearbeiter eine Regel, die zu viel verbietet — und das fällt erst auf, wenn sich jemand in der Werkstatt beschwert. Drei weitere zutreffende Beispiele hätten diese Information nie geliefert. Der Fall, in dem gerade nichts passieren soll, grenzt die Regel schärfer ein als jeder Fall, in dem sie greift.

4:29 Der erste Punkt sind die Wohlfühlwörter: robust, sauber, performant. Sie stehen in fast jedem Ticket und bedeuten nichts Überprüfbares. Der zweite ist die Verwechslung von Menge und Schärfe — drei weitere zutreffende Fälle sammeln statt eines abgrenzenden Gegenbeispiels. Der dritte ist der ärgerlichste: Man kennt das Gegenbeispiel, schreibt es aber nicht auf, weil es einem selbstverständlich vorkommt.

4:52 Genau dieses stillschweigende Wissen ist es, das ein Agent nicht haben kann. Und der vierte: Kriterien nach der Umsetzung formulieren. Dann beschreiben sie nur noch das Ergebnis.

Scope und ausdrückliche Nicht-Ziele

5:04 Jetzt kommt der Punkt, der in vielen Teams sofort etwas verändert — und er kostet zehn Sekunden. Es geht um Nicht-Ziele: um die ausdrückliche Angabe, was nicht passieren soll. Das klingt nach einer Kleinigkeit und ist die wirksamste einzelne Zeile in einem Arbeitsauftrag. Warum das so ist, hat einen strukturellen Grund.

5:23 Ein Nicht-Ziel verhindert die häufigste Form misslungener Agentenarbeit: die Änderung, die zusätzlich zum Auftrag noch vier andere Dinge verbessert hat. Und jetzt kommt der Punkt, der mir wichtig ist: Das ist keine Misstrauensbekundung. Der Bearbeiter — Mensch wie Agent — sieht unterwegs echte Verbesserungsmöglichkeiten und hat keinen Anhaltspunkt, ob sie erwünscht sind.

5:45 Ohne Angabe entscheidet er sich im Zweifel dafür. Er handelt also vernünftig. Das Problem ist nicht seine Entscheidung, sondern die fehlende Information. Drei Ebenen, und die meisten Teams nennen nur die erste. Fachlich: Die Privatnutzungsberechnung bleibt unverändert — das schreibt fast jeder hin. Strukturell wird schon seltener: Es werden keine neuen Abstraktionsebenen eingeführt. Und technisch fast nie: keine neuen Abhängigkeiten, nichts außerhalb des Buchungsmoduls.

6:14 Dabei sind gerade die letzten beiden Zeilen diejenigen, die den Diff lesbar halten. Und genau darum geht es: Ohne Angabe wird das Ergebnis unprüfbar, weil man nicht mehr unterscheiden kann, was beauftragt war und was dazukam. Der erste Punkt ist der Klassiker: Nicht-Ziele weglassen, weil sie sich von selbst verstehen. Sie tun es nie — was sich für Sie von selbst versteht, ist genau das Wissen, das nirgends steht.

6:39 Der zweite betrifft den Ton: Wer Nicht-Ziele als Misstrauen formuliert, bekommt Widerstand im Team. Es ist eine Abgrenzung des Auftrags, nicht eine Kontrolle der Person. Und der letzte Punkt betrifft den Review: Zusatzverbesserungen durchzuwinken, weil sie ja stimmen, untergräbt die Vereinbarung nachträglich.

Kleine vertikale Inkremente statt Einmal-Prompt

6:58 Kommen wir zu der Frage, wie groß eine Änderung sein darf. Und hier haben wir ausnahmsweise harte Zahlen — aus einer Studie, die nichts mit KI zu tun hat und gerade deshalb belastbar ist. Denn die Prüfkapazität eines Menschen hat sich nicht geändert. Nur die Menge, die auf ihn zukommt. Vertikal ist das entscheidende Wort. Ein vertikales Inkrement ist eine Scheibe, die für sich funktioniert — nicht eine Schicht, die erst mit den anderen zusammen etwas tut.

7:26 Bei der nachträglichen Fahrtkorrektur heißt das: zuerst nur der Fall, dass die Abrechnung noch offen ist. Ohne Berechtigungsprüfung, ohne Protokollierung. Das fühlt sich unvollständig an, ist aber in wenigen Minuten beurteilbar. Erst wenn diese Scheibe steht, kommt die nächste. Die Versuchung geht in die andere Richtung, weil ein großer Auftrag schneller geschrieben ist.

7:48 Diese Zahlen stammen aus einer Untersuchung von zweieinhalbtausend Reviews über gut drei Millionen Codezeilen. Das Ergebnis: Befunde werden am wirksamsten bei zweihundert bis vierhundert Codezeilen je Durchgang gefunden — siebzig bis neunzig Prozent der Defekte. Darüber fällt die Trefferquote ab. Und die dritte Zeile ist die, die man ungern hört: Auch das Tempo zählt. Wer mehr als fünfhundert Zeilen pro Stunde liest, findet weniger.

8:14 Die Folgerung steht rechts und ist unbequem: Nicht schneller lesen, sondern weniger. Es gibt keinen Weg, sich mehr Prüfkapazität zu erarbeiten, außer die Portionen zu verkleinern. Der Mechanismus ist simpel. Fehler bleiben unbemerkt, bis alles fertig ist — und dann ist nicht mehr erkennbar, welcher Schritt sie verursacht hat.

8:34 Dazu kommt der zweite Gewinn kleiner Schritte, der oft übersehen wird: Man merkt früh, wenn die Richtung insgesamt nicht trägt. Zu einem Zeitpunkt, an dem das Verwerfen noch billig ist. Und ich möchte noch einmal betonen, warum die Studie so gut passt: Sie stammt aus der Zeit vor der KI. Die menschliche Aufmerksamkeit ist die Konstante in dieser Rechnung.

Umgang mit Unsicherheit und erzwungene Rückfragen

8:55 Jetzt zu einer Eigenschaft, die man kennen muss, um damit umzugehen. Die gefährlichste Eigenschaft eines Agenten ist nicht, dass er etwas nicht weiß — Menschen wissen auch vieles nicht, und das ist beherrschbar. Die gefährliche Eigenschaft ist, dass er die Lücke stillschweigend füllt: plausibel, nicht gekennzeichnet, nicht nachgefragt.

9:14 Sie merken es also nicht am Ergebnis, sondern frühestens dann, wenn jemand über das Verhalten stolpert. Ein Beispiel aus dem Fahrtenbuch. Im Auftrag steht nichts darüber, was mit Fahrten geschehen soll, deren Kilometerstand nicht nachgetragen wurde. Ein Mensch würde fragen. Ein Agent trifft eine Entscheidung — vielleicht sogar eine vernünftige. Nur steht nirgends, dass er sie getroffen hat.

9:38 Und damit prüfen Sie später Code, ohne zu wissen, dass darin eine unausgesprochene Annahme steckt. Zwei Gegenmittel wirken, und beide gehören in den Auftrag, nicht in die Hoffnung. Das erste Gegenmittel: Verlangen Sie ausdrücklich, dass Annahmen als solche benannt werden, bevor Code entsteht — und zwar als Liste, nicht versteckt im Fließtext.

10:00 Das zweite: Setzen Sie Schwellen, ab denen nicht weitergearbeitet, sondern gefragt wird. Bewährt haben sich drei: Datenmodell, öffentliche Schnittstelle, fachliche Regel. Berührt die Aufgabe eines davon, wird gefragt. Beides verlangsamt scheinbar. Tatsächlich verlagert es die Klärung nur an die Stelle, an der sie billig ist — vor die Umsetzung statt in den Review.

10:22 Der erste Punkt ist praktisch: Annahmen im Fließtext der Antwort suchen. Sie stehen dort manchmal, aber niemand findet sie zuverlässig. Verlangen Sie eine Liste. Der zweite: Schwellen im Einzelfall entscheiden. Im Einzelfall ist man immer geneigt weiterzumachen, deshalb müssen sie vorher feststehen. Der dritte ist der aus Modul eins bekannte — eine plausible Entscheidung übernehmen, weil sie plausibel klingt.

10:48 Und der vierte ist eine Haltungsfrage: Rückfragen sind kein Zeitverlust. Sie sind vorgezogene Reviewzeit, und zwar zum günstigeren Kurs.

Plan-first: erkunden, planen, erst dann ändern

10:57 Und damit zur wirkungsvollsten einzelnen Angewohnheit im Umgang mit Coding-Agenten. Wenn Sie aus diesem Modul nur eine Sache übernehmen, dann diese — sie kostet wenig Zeit, wirkt sofort und braucht keine Werkzeugumstellung. Der Grund, warum sie so gut funktioniert, ist erfreulich unspektakulär und hat mit Sprachmodellen wenig zu tun. Er hat damit zu tun, wo ein Denkfehler leichter zu erkennen ist.

11:21 Die Idee ist, den Plan vom Code zu trennen. Erst erkunden lassen: Welche Dateien sind betroffen, welche Regeln bestehen bereits, welche Tests decken den Bereich ab? Dann einen Änderungsplan verlangen — in Prosa, ausdrücklich ohne Code. Diesen Plan lesen, korrigieren, freigeben. Erst danach umsetzen lassen. Der Grund dafür ist einfach: Ein falscher Plan ist in zwei Minuten erkannt und in einem Satz korrigiert.

11:46 Dieselbe falsche Annahme, einmal in Code gegossen, kommt über zwölf Dateien verteilt daher und ist im Diff kaum noch als Denkfehler erkennbar. Vier Schritte, und bei zweien lohnt ein Hinweis. Das Erkunden ist rein lesend und damit ohne Risiko — Sie können es großzügig beauftragen. Beim Plan ist wichtig, dass Sie ausdrücklich Prosa verlangen; kommt Code, prüfen Sie am Ende Formulierung statt Absicht.

12:10 Beim dritten Schritt geht es um den Blick: Prüfen Sie die Annahmen im Plan, nicht die Schritte. Die Schritte sind meist plausibel, in den Annahmen sitzt der Fehler. Und mit der Freigabe wandert die Verantwortung zu Ihnen — der Plan muss also kurz genug sein, dass Sie ihn wirklich lesen. Der erste Punkt ist der teuerste: Man überfliegt den Plan und prüft dann gründlich die Ausführung. Damit prüft man das Falsche, denn der Denkfehler sitzt im Plan.

12:38 Der zweite ist die Code-Falle von eben. Der dritte ist ein Einwand, der im Raum regelmäßig kommt — das sei doch Wasserfall durch die Hintertür. Ist es nicht: Der Plan gilt für ein Inkrement von Minuten bis Stunden, nicht für ein Projekt. Er ersetzt keine Iteration, er macht eine einzelne prüfbar. Und der vierte: Ohne Erkundung plant man im Nebel.

Übung: Eine vage Feature-Anfrage zuschneiden

12:59 Zum Abschluss dieses Moduls eine Übung, in der Sie alles zusammenbringen, was wir heute besprochen haben. Sie bekommen genau einen Satz von der Verwaltung — mehr nicht, so wie es im Alltag eben ankommt. Daraus soll ein bearbeitbarer Auftrag werden, mit Zielen, Kriterien und Grenzen. Und am Ende wartet eine Frage, die viele überrascht, weil sie mit Technik zunächst gar nichts zu tun hat.

13:22 Der Satz lautet: Wir brauchen eine Auswertung, wer wie viel privat fährt. Mehr kommt nicht. Ihre Aufgabe ist, daraus Ziel, Kriterien, Nicht-Ziele und Prüfschritte zu machen. Und dann kommt der Punkt, der diese Übung von einer reinen Formalübung unterscheidet: Sie sollen die datenschutzrechtliche Frage benennen, die dieser Auftrag aufwirft.

13:43 Denn Fahrten sind Bewegungsdaten — sie sagen, wer wann wo war. Wer das erst nach der Umsetzung merkt, hat mit erheblichem Aufwand das Falsche gebaut. Fünf Schritte in gut einer Stunde. Zuerst klären, welches Problem dahintersteckt und wer die Antwort wirklich braucht — allein diese Frage verändert den Auftrag oft grundlegend.

14:03 Dann Ziel und gewünschtes Verhalten getrennt formulieren. Dann drei Akzeptanzkriterien mit je einem Beispiel und einem Gegenbeispiel. Dann mindestens zwei Nicht-Ziele und die Prüfschritte für die Abnahme. Und zum Schluss die Datenschutzfrage: Benennen Sie sie und begründen Sie, ob sie vor oder nach der Umsetzung geklärt sein muss.