14. Dez. 2025·6 Min
Claude Code Aufgabenabgrenzung: Von vagen Anfragen zu Commits
Lerne, wie du mit Claude Code vage Feature‑Anfragen in klare Akzeptanzkriterien, einen minimalen UI-/API‑Plan und ein paar kleine Commits verwandelst.
Lerne, wie du mit Claude Code vage Feature‑Anfragen in klare Akzeptanzkriterien, einen minimalen UI-/API‑Plan und ein paar kleine Commits verwandelst.
Eine vage Anfrage klingt harmlos: „Bessere Suche hinzufügen“, „Onboarding flüssiger machen“, „Nutzer brauchen Benachrichtigungen.“ In echten Teams kommt sie oft als Ein-Zeilen-Chatnachricht, ein Screenshot mit Pfeilen oder ein halb erinnerter Kundenanruf. Alle sind sich einig, aber alle haben etwas anderes im Kopf.
Die Kosten zeigen sich später. Wenn der Scope unklar ist, arbeiten Leute mit Vermutungen. Die erste Demo wird zur nächsten Klärungsrunde: „Das meinte ich nicht.“ Arbeit wird neu gemacht, und die Änderung wächst stillschweigend. Design-Anpassungen lösen Code-Änderungen aus, die weitere Tests benötigen. Reviews verlangsamen sich, weil eine schwammige Änderung schwer zu verifizieren ist. Wenn niemand definieren kann, wie „korrekt“ aussieht, streiten Reviewer über Verhalten statt Qualität zu prüfen.
Vage Tasks erkennst du meist früh:
Gut abgegrenzte Aufgaben geben dem Team eine Ziellinie: klare Akzeptanzkriterien, ein minimaler UI- und API-Plan und explizite Grenzen dessen, was nicht enthalten ist. Das ist der Unterschied zwischen „Suche verbessern“ und einer kleinen Änderung, die sich leicht bauen und prüfen lässt.
Eine praktische Gewohnheit: Trenne „Definition of done“ von „Nice-to-have“. „Done“ ist eine kurze Liste von Prüfungen, die du ausführen kannst (zum Beispiel: „Die Suche liefert Ergebnisse nach Titel, zeigt ‚Keine Ergebnisse‘ bei Leerzustand und behält die Query in der URL“). „Nice-to-have“ sind Dinge, die warten können (Synonyme, Ranking-Anpassungen, Hervorhebungen, Analytics). Das früh zu kennzeichnen verhindert unbeabsichtigtes Scope-Wachstum.
Vage Anfragen starten oft als vorgeschlagene Fixes: „Button hinzufügen“, „auf neuen Flow wechseln“, „ein anderes Modell verwenden“. Stoppe kurz und übersetze den Vorschlag zuerst in ein Ergebnis.
Ein einfaches Format hilft: „Als [Nutzer] möchte ich [etwas tun], damit ich [ein Ziel erreiche].“ Halte es kurz. Wenn du es nicht in einem Atemzug sagen kannst, ist es noch zu schwammig.
Beschreibe als Nächstes, was sich für den Nutzer ändert, wenn es fertig ist. Konzentriere dich auf sichtbares Verhalten, nicht auf Implementierungsdetails. Zum Beispiel: „Nachdem ich das Formular abgeschickt habe, sehe ich eine Bestätigung und finde den neuen Eintrag in der Liste.“ Das schafft eine klare Ziellinie und macht es schwerer, dass „nur noch eine Kleinigkeit“ hereinschlüpft.
Schreibe auch auf, was gleich bleibt. Non-Goals schützen deinen Scope. Wenn die Anfrage „Onboarding verbessern“ heißt, könnte ein Non-Goal sein: „kein Dashboard-Redesign“ oder „keine Änderungen an der Preis-Tier-Logik“.
Wähle schließlich zuerst einen primären Pfad: die einzelne End-to-End-Schicht, die beweist, dass das Feature funktioniert.
Beispiel: statt „Snapshots überall hinzufügen“ schreibe: „Als Projektbesitzer kann ich den letzten Snapshot meiner App wiederherstellen, um eine schlechte Änderung rückgängig zu machen.“ Non-Goals: „kein Bulk-Restore, kein UI-Redesign."
Eine vage Anfrage fehlt selten an Aufwand. Sie fehlt an Entscheidungen.
Beginne mit Einschränkungen, die den Scope still verändern. Deadlines sind wichtig, aber ebenso Zugriffregeln und Compliance-Bedürfnisse. Wenn du auf einer Plattform mit Tiers und Rollen baust, entscheide früh, wer das Feature bekommt und in welchem Plan.
Bitte dann um ein konkretes Beispiel. Ein Screenshot, das Verhalten eines Konkurrenten oder ein früheres Ticket zeigt, was „besser“ wirklich bedeutet. Hat der Anfragende keines, bitte ihn, die letzte Situation zu beschreiben, in der er den Schmerz gespürt hat: Auf welchem Bildschirm war er, was hat er geklickt, was hat er erwartet?
Edge-Cases lassen den Scope explodieren, also nenne die großen früh: leere Daten, Validierungsfehler, langsame oder fehlgeschlagene Netzwerkaufrufe und was „Undo“ wirklich bedeutet.
Entscheide abschließend, wie du den Erfolg verifizierst. Ohne ein testbares Ergebnis wird die Aufgabe zur Meinungsfrage.
Diese fünf Fragen entfernen meist die meiste Mehrdeutigkeit:
Beispiel: „Custom Domains für Kunden hinzufügen“ wird klarer, sobald du entscheidest, zu welchem Tier es gehört, wer es einrichten kann, ob Hosting-Standort für Compliance wichtig ist, welche Fehlermeldung bei ungültigem DNS erscheint und was „done“ heißt (Domain verifiziert, HTTPS aktiv, sichere Rollback-Option).
Unklare Anfragen mischen Ziele, Vermutungen und halb erinnerte Edge-Cases. Die Aufgabe ist, das in Aussagen zu verwandeln, die jeder testen kann, ohne in deinen Kopf zu schauen. Dieselben Kriterien sollten Design, Entwicklung, Review und QA leiten.
Ein einfaches Muster hält es klar. Du kannst Given/When/Then verwenden oder kurze Bullet-Points, die dasselbe aussagen.
Schreibe jedes Kriterium als einen einzelnen Test, den jemand ausführen könnte:
Wende es jetzt an. Angenommen, die Notiz lautet: „Snapshots einfacher machen. Ich möchte zurückrollen können, wenn die letzte Änderung Probleme verursacht.“ Formuliere prüfbare Aussagen:
Wenn QA diese Prüfungen ausführen kann und Reviewer sie in UI und Logs verifizieren können, bist du bereit, UI- und API‑Arbeit zu planen und in kleine Commits aufzuteilen.
Ein minimaler UI-Plan ist ein Versprechen: die kleinstmögliche sichtbare Änderung, die beweist, dass das Feature funktioniert.
Beginne damit, zu benennen, welche Bildschirme sich ändern und was eine Person in 10 Sekunden bemerkt. Wenn die Anfrage „einfacher machen“ oder „aufräumen“ lautet, übersetze das in eine konkrete Änderung, die du zeigen kannst.
Schreibe es als kleine Karte, nicht als Redesign. Zum Beispiel: „Bestellungen-Seite: Filterleiste über der Tabelle hinzufügen“ oder „Einstellungen: neuen Schalter unter Benachrichtigungen hinzufügen.“ Wenn du Bildschirm und genaues Element nicht benennen kannst, ist der Scope noch unklar.
Die meisten UI-Änderungen brauchen ein paar vorhersehbare Zustände. Nenne nur die, die relevant sind:
UI‑Texte gehören zum Scope. Erfasse Labels und Meldungen, die freigegeben werden müssen: Button‑Text, Feldbezeichnungen, Hilfetexte und Fehlermeldungen. Wenn die Formulierungen noch offen sind, markiere sie als Platzhalter und notiere, wer sie bestätigt.
Behalte eine kleine „nicht jetzt“-Liste für alles, was nicht nötig ist, um das Feature zu nutzen (responsives Feintuning, erweiterte Sortierung, Animationen, neue Icons).
Eine abgegrenzte Aufgabe braucht einen kleinen, klaren Vertrag zwischen UI, Backend und Daten. Ziel ist nicht, das ganze System zu entwerfen, sondern das kleinstmögliche Set an Requests und Feldern zu definieren, das beweist, dass das Feature funktioniert.
Beginne damit, die Daten aufzulisten, die du brauchst und woher sie kommen: bestehende Felder, die du lesen kannst, neue Felder, die du speichern musst, und Werte, die du berechnen kannst. Wenn du für jedes Feld keine Quelle benennen kannst, hast du noch keinen Plan.
Halte die API‑Oberfläche klein. Für viele Features reicht ein Read und ein Write:
GET /items/{id} liefert den Zustand zum Rendern des BildschirmsPOST /items/{id}/update nimmt nur das an, was der Nutzer ändern kann, und liefert den aktualisierten ZustandSchreibe Eingaben und Ausgaben als einfache Objekte, nicht als Fließtext. Führe erforderliche vs. optionale Felder auf und beschreibe, was bei gängigen Fehlern passiert (nicht gefunden, Validierung fehlgeschlagen).
Führe vor Änderungen am DB kurz eine Auth-Prüfung durch. Entscheide, wer lesen und wer schreiben darf, und formuliere die Regel in einem Satz (z. B.: „Jeder angemeldete Nutzer kann lesen, nur Admins können schreiben“). Das Weglassen führt oft zu Nacharbeit.
Entscheide schließlich, was gespeichert werden muss und was berechnet werden kann. Ein einfacher Grundsatz: Fakten speichern, Views berechnen.
Claude Code funktioniert am besten, wenn du ein klares Ziel und eine enge Box vorgibst. Füge die unordentliche Anfrage und alle Einschränkungen (Deadline, betroffene Nutzer, Datenregeln) ein. Bitte dann um eine abgegrenzte Ausgabe, die enthält:
Lies die Antwort danach wie ein Reviewer. Wenn du Formulierungen wie „Performance verbessern“ oder „aufgeräumter machen“ siehst, fordere messbare Beschreibungen an.
Anfrage: „Füge eine Möglichkeit hinzu, ein Abo zu pausieren."
Eine abgegrenzte Version könnte sagen: „Der Nutzer kann für 1 bis 3 Monate pausieren; das nächste Abrechnungsdatum aktualisiert sich; Admins sehen den Pausen‑Status.“ Out of scope: „Keine Änderungen an Proration.“
Daraus wird der Commit-Plan praktisch: ein Commit für DB und API‑Form, einer für UI‑Controls, einer für Validierung und Fehlerfälle, einer für E2E‑Tests.
Große Änderungen verstecken Bugs. Kleine Commits machen Reviews schneller, Rollbacks sicherer und helfen dir zu bemerken, wenn du vom Akzeptanzkriterium abweichst.
Eine nützliche Regel: Jeder Commit sollte genau ein neues Verhalten freischalten und eine schnelle Möglichkeit enthalten, es zu beweisen.
Eine übliche Reihenfolge sieht so aus:
Halte jeden Commit fokussiert. Vermeide „bin gerade dabei“-Refactors. Sorge dafür, dass die App Ende-zu-Ende funktioniert, auch wenn die UI einfach ist. Packe Migrationen, Verhalten und UI nicht in einen Commit, außer es gibt einen guten Grund.
Ein Stakeholder sagt: „Können wir Export‑Reports hinzufügen?“ Das verbirgt viele Entscheidungen: welcher Bericht, welches Format, wer darf exportieren und wie wird geliefert.
Stelle nur die Fragen, die das Design ändern:
Nimm an, die Antworten sind: „Sales Summary, nur CSV, Manager‑Rolle, Direktdownload, max. 90 Tage.“ Dann wird das v1‑Akzeptanzkriterium konkret: Manager können auf Export auf der Sales‑Summary‑Seite klicken; das CSV entspricht den sichtbaren Tabellenspalten; der Export respektiert aktuelle Filter; bei mehr als 90 Tagen zeigt der Server einen klaren Fehler; der Download schließt innerhalb von 30 Sekunden für bis zu 50k Zeilen ab.
Minimaler UI‑Plan: ein Export‑Button bei den Tabellenaktionen, ein Ladezustand während der Generierung und eine Fehlermeldung, die dem Nutzer erklärt, wie er das Problem behebt (z. B. „Wähle 90 Tage oder weniger“).
Minimaler API‑Plan: ein Endpoint, der Filter entgegennimmt und ein generiertes CSV als Dateiantwort zurückgibt, wobei dieselbe Query wie die Tabelle wiederverwendet und die 90‑Tage‑Regel serverseitig durchgesetzt wird.
Dann lieferst du es in wenigen kompakten Commits: erst der Endpoint für den festen Happy Path, dann UI‑Wiring, dann Validierung und benutzerseitige Fehlermeldungen, zuletzt Tests und Dokumentation.
Anfragen wie „Teamrollen hinzufügen“ verbergen oft Regeln zu Einladungen, Bearbeitung und was mit bestehenden Nutzern passiert. Wenn du beim Raten erwischt wirst, notiere die Annahme und mache daraus eine Frage oder eine explizite Regel.
Teams verlieren Tage, wenn eine Aufgabe sowohl „funktionieren“ als auch „schick aussehen“ beinhaltet. Konzentriere die erste Aufgabe auf Verhalten und Daten. Styling, Animationen und Abstände kommen in einem Folge-Task, sofern sie nicht nötig sind, um das Feature zu nutzen.
Edge‑Cases sind wichtig, aber nicht alle müssen sofort gelöst werden. Behandle die, die Vertrauen brechen (Doppelte Submits, Konflikte), und verschiebe den Rest mit klaren Notizen.
Wenn du sie nicht aufschreibst, vergisst du sie. Nimm mindestens einen unhappy path und mindestens eine Berechtigungsregel in die Akzeptanzkriterien auf.
Vermeide Begriffe wie „schnell“ oder „intuitiv“, es sei denn, du hängst eine Zahl oder eine konkrete Überprüfung dran. Ersetze sie durch etwas, das du im Review nachweisen kannst.
Fixiere die Aufgabe so, dass ein Kollege ohne Gedankenlesen reviewen und testen kann:
Beispiel: „Saved Searches hinzufügen“ wird zu „Nutzer können einen Filter speichern und später wieder anwenden“, mit Non-Goals wie „kein Teilen“ und „keine Sortieränderungen".
Wenn du einen abgegrenzten Task hast, schütze ihn. Vor dem Coden mache ein kurzes Sanity‑Review mit den Fragestellern:
Speichere die Kriterien dort, wo gearbeitet wird: im Ticket, in der PR‑Beschreibung und überall, wo dein Team wirklich hinsieht.
Wenn du in Koder.ai (koder.ai) baust, hilft es, zuerst den Plan zu sperren und dann Code daraus zu generieren. Der Planning Mode passt gut zu diesem Workflow, und Snapshots sowie Rollback können Experimente sichern, wenn du einen Ansatz testen und wieder zurücknehmen musst.
Wenn während der Arbeit neue Ideen auftauchen, halte den Scope stabil: schreibe sie in eine Nachfolge‑Liste, pausiere und re‑scope, wenn sie die Akzeptanzkriterien verändern, und halte Commits an ein Kriterium gebunden.
Beginne damit, das Ergebnis in einem Satz zu beschreiben (was der Nutzer tun kann, wenn es fertig ist), und füge dann 3–7 prüfbare Akzeptanzkriterien hinzu, die ein Tester verifizieren kann.
Wenn du das „korrekte“ Verhalten nicht beschreiben kannst, ohne darüber zu streiten, ist die Aufgabe noch zu vage.
Verwende dieses schnelle Format:
Füge dann ein konkretes Beispiel des erwarteten Verhaltens hinzu. Wenn du kein Beispiel nennen kannst, spiele die letzte Situation durch, in der das Problem auftrat, und schreibe auf, was der Nutzer geklickt hat und was er erwartet hat zu sehen.
Schreibe zuerst eine kurze „Definition of done“-Liste (die Prüfungen, die bestehen müssen) und dann eine separate „Nice-to-have“-Liste.
Standardregel: Wenn es nicht nötig ist, um zu beweisen, dass das Feature Ende-zu-Ende funktioniert, gehört es in Nice-to-have.
Stelle die wenigen Fragen, die den Scope ändern:
Diese zwingen die fehlenden Entscheidungen ans Licht.
Behandle Edge-Cases als Scope-Einträge, nicht als Überraschungen. Für v1 decke die Fälle ab, die Vertrauen zerstören würden:
Alles andere kann explizit als außer Scope vermerkt werden.
Verwende prüfbare Aussagen, die jeder ohne Raten ausführen kann:
Füge mindestens einen Fehlerfall und eine Berechtigungsregel hinzu. Wenn ein Kriterium nicht testbar ist, formuliere es so lange um, bis es testbar ist.
Benenne die genauen Bildschirme und die eine sichtbare Änderung pro Bildschirm.
Liste außerdem die erforderlichen UI-Zustände:
Behalte auch die Texte (Button-Text, Fehler) im Scope, selbst wenn es Platzhalter sind.
Halte die Oberfläche klein: oft reicht ein Read und ein Write für v1.
Definiere:
Speichere Fakten; berechne Views, wenn möglich.
Bitte um ein abgegrenztes Ergebnis:
Fordere anschließend eine Messung oder konretisiere vage Formulierungen wie „machen schneller“.
Standardabfolge:
Regel: ein Commit = ein neues sichtbares Verhalten + ein schneller Beweis. Vermeide „nebenbei“ Refactors in Feature-Commits.