Wie schreibst du einer KI-Assistenz eine Aufgabe, deren Ergebnis du prüfen kannst?

Bitte um eine Änderung, sag, wo sie hingehört und was gleich bleiben muss, gib eine Prüfung mit Ja oder Nein und verlange einen Bericht.

Bitte um eine einzige Änderung, klein genug, dass du sie in ein paar Minuten ausprobieren kannst. Sag, wo sie hingehört, was so bleiben muss, wie es ist, wie man prüft, dass sie funktioniert, und was du zurückhören willst. Eine so geschriebene Aufgabe kommt als etwas zurück, das du beurteilen kannst: eine kurze Liste geänderter Dateien, eine Prüfung, die bestanden oder nicht bestanden ist, und ein Spiel, das du spielen kannst, um es zu bestätigen. Eine vage Aufgabe kommt als große Änderung zurück, die „fertig aussieht“, und dann liegt das ganze Prüfen bei dir.

Was macht eine Aufgabe prüfbar?

Fünf Teile. Die meisten Aufgaben brauchen alle fünf, und jeder passt in ein oder zwei Sätze.

Nichts davon ist neu. GitHubs Anleitung zum Schreiben von Prompts für Copilot verlangt eine einfache, konkrete Bitte, in Schritte zerlegt, mit ein oder zwei Beispielen für das, was du erwartest. Die Best Practices für Claude Code stellen eine Prüfung, die die Assistenz selbst ausführen kann, an die erste Stelle, weil ohne sie „sieht fertig aus“ das einzige Signal ist, das sie hat. So lasen sich beide Seiten am 25. Oktober 2026. Im Folgenden wird das auf ein kleines Spiel angewendet.

Wie klein sollte eine Aufgabe sein?

So klein, dass du die Änderung in einem Satz beschreiben und in ein paar Minuten ausprobieren kannst. „Füge einen Pausenbildschirm hinzu“ ist eine Aufgabe. „Füge einen Pausenbildschirm, ein Einstellungsmenü und Sound hinzu“ sind drei, und wenn etwas kaputtgeht, weißt du nicht, welche davon es war.

Braucht eine Aufgabe eine längere Beschreibung, bitte zuerst um einen Plan und heb den Code für später auf. Die Seite zu Claude Code schlägt genau das vor: Lass die Assistenz den Code lesen und vorschlagen, welche Dateien sich ändern würden, lies den Plan selbst, und erst dann lass sie schreiben. Ein Plan, der das halbe Projekt berührt, ist ein Zeichen, dass die Aufgabe geteilt werden sollte.

Es ist dieselbe Regel wie bei einem kleinen ersten Spiel: Jedes Feature muss mit jedem anderen zusammenarbeiten, also vervielfacht eine Aufgabe, die drei davon hinzufügt, das Prüfen.

Wie sieht eine vage Aufgabe neben einer prüfbaren aus?

Hier ist eine Bitte für einen kleinen Shooter, zweimal geschrieben.

Die rechte Spalte ist länger, aber jede Zeile darin lässt sich prüfen. Die dritte kommt dem nahe, was wir getan haben, als wir KittenGalaxy eine Touch-Steuerung gegeben haben: Die Tasten senden die Tastenereignisse, die die Tastatur senden würde, deshalb musste das Spiel selbst nicht geändert werden.

Wie sagst du der Assistenz, wie sie ihre Arbeit prüfen soll?

Gib ihr etwas, das mit Ja oder Nein antwortet.

• Ein Test, den die Assistenz ausführen kann, mit ausgeschriebenen Fällen: „Ein Neustart setzt die Punkte auf 0.“
• Ein Befehl, dessen Ergebnis man lesen kann: Der Build läuft durch, die Seite lädt ohne Fehler in der Konsole.
• Schritte, die du selbst spielst, aufgeschrieben vor der Änderung: „Start, alle Leben verlieren, Neustart drücken, die Punkte zeigen 0.“

Bitte die Assistenz, die Prüfung auszuführen und die Ausgabe zu zeigen, statt nur zu sagen, dass sie bestanden ist. Ein eingefügtes Testergebnis oder ein Konsolenprotokoll ohne Fehler liest du in Sekunden; ein Satz wie „alles funktioniert“ beweist nichts.

Manches kann nur ein Mensch beurteilen: ob sich ein Sprung richtig anfühlt oder ob ein Level fair ist. Schreib dafür auf, worauf du achten wirst, und spiel es selbst. Lass den Bericht der Assistenz das nicht ersetzen.

Was soll die Assistenz dir sagen, wenn sie fertig ist?

Bitte in derselben Aufgabe um einen kurzen Bericht in dieser Reihenfolge:

1. welche Dateien sich geändert haben und, in je einer Zeile, warum;
2. welche Prüfungen sie ausgeführt hat und was dabei herauskam;
3. was sie nicht getestet hat, und warum;
4. alles, was sie geändert hat, ohne dass du darum gebeten hast.

Der letzte Punkt zählt am meisten. Eine Änderung über die Bitte hinaus ist nicht immer falsch, aber sie ist immer etwas, das du nicht prüfen wolltest. Vergleiche die Liste der Dateien mit Teil 3 deiner Aufgabe: Eine Datei, die sich nicht hätte ändern sollen, ist die erste Stelle zum Hinschauen.

Was gehört in eine Projektdatei statt in jede Aufgabe?

Alles, was du sonst wiederholen würdest: wie man das Spiel und die Tests startet, welche Ordner nicht angefasst werden dürfen, die Regeln des Codes. Die meisten Assistenzen lesen eine solche Datei zu Beginn einer Sitzung (bei Claude Code heißt sie CLAUDE.md). Halte sie kurz; die Seite zu Claude Code warnt, dass in einer langen Datei die wichtigen Regeln untergehen.

Eine Regel verdient dort ihren Platz, wenn das Vergessen das Spiel kaputt macht. In unseren Notizen zu KittenGalaxy steht: Wenn eine Taste, ein Bildschirm oder ein Spielzustand hinzukommt, kommt seine Touch-Steuerung in derselben Änderung dazu, sonst erreichen Spieler am Handy ihn nicht. Eine Aufgabe muss dann nur noch sagen, was neu ist.

Was tust du, wenn das Ergebnis falsch ist?

Geh zurück und bitte noch einmal, mit einer besseren Aufgabe.

Sichere vor jeder Aufgabe eine funktionierende Version als Commit in der Versionsverwaltung, damit sich eine schlechte Änderung in einem Schritt rückgängig machen lässt. Wenn eine Prüfung scheitert, kannst du ein- oder zweimal um eine Korrektur bitten. Scheitern zwei Korrekturen, rät die Seite zu Claude Code, eine neue Sitzung mit einer besseren ersten Bitte zu beginnen, statt immer wieder zu korrigieren, weil die gescheiterten Versuche im Gespräch bleiben. Mach die Änderung rückgängig, ergänze die Aufgabe um das, was du gelernt hast, und schick sie noch einmal.

Häufige Fragen

Muss ich programmieren können, um solche Aufgaben zu schreiben? Nein. Die Teile 1, 3 und 5 handeln davon, was das Spiel tut, in einfachen Worten. Für Teil 2 frag die Assistenz, wo die Änderung hingehört, bevor du sie darum bittest, sie zu machen.

Ist eine lange Aufgabe besser als eine kurze? Nicht an sich. Eine lange Aufgabe, die viele Änderungen verlangt, ist schwerer zu prüfen als eine kurze, die eine verlangt. Länge hilft, wenn sie eine Prüfung oder eine Grenze hinzufügt.

Soll ich in einem kleinen Spiel um Tests bitten? Für Regeln, die sich genau sagen lassen (Punkte, Leben, ein Timer, Spielstände), ja. Sie kosten wenig und laufen nach jeder späteren Änderung. Gefühl und Spaß muss man weiterhin spielen.

Was, wenn die Assistenz mir Fragen stellt? Beantworte sie in der Aufgabe, bevor sie zu schreiben beginnt. Eine früh gestellte Frage kostet weniger als eine falsche Änderung.

Wann ist das Spiel bereit, es Leuten zu zeigen? Wenn eine fremde Person es über einen Link starten und ohne deine Hilfe zu Ende spielen kann. Dann kannst du es bei HeapPlay einreichen, und verifizierte Entwickler können jede neue Version und ihre Änderungen festhalten.