Wie prüfst du eine Änderung, die eine KI-Assistenz an deinem Spiel gemacht hat, bevor du sie behältst?

Vergleiche die geänderten Dateien mit deiner Aufgabe, lies den Diff von den Löschungen her, führe die Prüfungen selbst aus, spiel die Änderung und committe erst dann.

Schau dir vier Dinge an, in dieser Reihenfolge: welche Dateien sich geändert haben, was der Diff entfernt und hinzugefügt hat, was die Prüfungen sagen, wenn du sie selbst ausführst, und wie sich das Spiel an der Stelle spielt, an der die Änderung gelandet ist. Behalte die Änderung nur, wenn alle vier zu dem passen, worum du gebeten hast, und behalte sie als Commit. Passt eines davon nicht, mach sie rückgängig und frag noch einmal, mit einer besseren Aufgabe. Der Bericht der Assistenz sagt dir, wo du hinschauen sollst; die Prüfung ersetzt er nicht.

Warum reicht „fertig“ nicht?

Weil es eine Behauptung ist, und der Beweis ist die Änderung selbst. Eine Assistenz kann sagen, dass eine Funktion läuft, obwohl sie nur geprüft hat, dass der Code baut, oder dass sie eine Datei angefasst hat, während ein Befehl, den sie ausgeführt hat, drei umgeschrieben hat.

Manches davon ist im Editor gar nicht zu sehen. Die Seite von Visual Studio Code zum Prüfen von KI-Änderungen sagt, dass ausstehende Änderungen schon auf der Festplatte gespeichert sind, dass Änderungen durch Terminalbefehle oder Skripte nicht in ihrer Liste der Änderungen erscheinen und dass ihre Checkpoints weder Terminalbefehle noch Deployments rückgängig machen. So stand es dort am 29. Oktober 2026, zuletzt aktualisiert am 21. Oktober. Welches Werkzeug du auch nutzt, die verlässliche Sicht gibt dir die Versionsverwaltung: jede Datei, die sich von deinem letzten Commit unterscheidet.

Deshalb kommt der erste Schritt, bevor die Assistenz anfängt: Speichere eine funktionierende Version als Commit. Ohne ihn gibt es nichts, womit du die Änderung vergleichen kannst, und nichts, wohin du zurückkannst.

Worauf schaust du zuerst?

Auf die Liste der geänderten Dateien. Zwei Befehle liefern sie:

git status
git diff --stat

git status nennt jede geänderte und jede neue Datei. git diff --stat zeigt zusätzlich, wie viele Zeilen jede Datei gewonnen und verloren hat. Beachte, dass git diff allein keine Dateien zeigt, die neu sind und noch nicht zu Git hinzugefügt wurden; git status zeigt sie, also lies beides.

Vergleiche die Liste jetzt mit deiner Aufgabe. Wenn du eine Aufgabe geschrieben hast, die sagt, wo die Änderung hingehört und was gleich bleiben muss, dauert das Sekunden.

Nichts davon ist für sich ein Fehler. Aber jeder Punkt ist etwas, das du nicht prüfen wolltest, deshalb kommt er zuerst.

Wie liest du einen Diff, wenn du nicht programmierst?

Lies ihn als Liste entfernter Zeilen (rot, mit - markiert) und hinzugefügter Zeilen (grün, mit + markiert), und fang mit den entfernten an. Eine verschwundene Zeile übersieht man am leichtesten und bemerkt sie im Spiel am schwersten: eine Prüfung, die den Spieler davon abhielt, durch Wände zu laufen, das Zurücksetzen der Punkte, ein Schutz gegen einen leeren Spielstand.

Dann achte auf ein paar Muster, die man auch ohne Kenntnis der Sprache erkennt:

• Zahlen, die sich geändert haben: Geschwindigkeiten, Leben, Timer, Preise. Jede davon sollte in deiner Aufgabe stehen.
• Code, der zu Kommentaren gemacht wurde, oder ein ganzer Block, der gelöscht und anderswo neu geschrieben wurde.
• Eine neue Funktion, die einer alten ähnelt: dieselbe Arbeit doppelt erledigt, und die beiden Kopien laufen später auseinander.
• Text, den der Spieler sieht: Menüs, Hinweise, Fehlermeldungen. Ist er noch richtig und an der richtigen Stelle?

Bei jeder Zeile, die du nicht lesen kannst, frag die Assistenz, was sie tut und was sie aufruft. Die Frage kostet nichts, und eine Antwort, die nicht zum Code passt, ist selbst schon ein Befund.

Welche Prüfungen führst du selbst aus?

Die, die deine Aufgabe genannt hat, von dir ausgeführt statt berichtet. Hat die Aufgabe einen Test verlangt, führ die Tests aus und lies das Ergebnis. Hat sie verlangt, dass die Seite ohne Fehler lädt, öffne das Spiel mit offener Konsole des Browsers. Eine Prüfung, die du bestehen gesehen hast, ist mehr wert als ein Satz, der sagt, dass sie bestanden hat.

Ein grüner Test beweist nur, was er testet. Hat sich im selben Diff eine Testdatei geändert, lies diesen Teil: Ein Test, der nach einem Neustart früher 0 Punkte erwartet hat und jetzt erwartet, was auch immer der Code liefert, prüft nichts mehr.

Was spielst du, bevor du die Änderung behältst?

Zuerst die Änderung selbst, so wie deine Aufgabe sie beschrieben hat. Dann eine kurze Runde durch den Rest des Spiels, jedes Mal dieselbe, weil eine Änderung an einer Stelle oft eine andere kaputt macht:

1. starte das Spiel von einer frischen Seite;
2. benutze jede Steuerung einmal, auf der Tastatur und auf dem Handy, wenn das Spiel Touch-Steuerung hat;
3. pausieren, verlieren, neu starten;
4. speichern, Seite neu laden, laden.

Die Runde dauert ein paar Minuten und findet, was Tests selten abdecken: einen Knopf, der nicht mehr reagiert, einen Bildschirm, den man nicht verlassen kann, einen Spielstand, der nicht zurückkommt. Hat die Änderung eine Taste oder einen Bildschirm hinzugefügt, prüfe, dass sie auch per Touch funktionieren; diese Regel halten wir für KittenGalaxy ein, seit wir ihm Touch-Steuerung gegeben haben.

Wie behältst du die Änderung, oder wie wirfst du sie weg?

Um sie zu behalten, committe sie, mit einer Nachricht, die in den Worten des Spielers sagt, was sich geändert hat: „jede Welle 10 % schneller, bis zur doppelten Startgeschwindigkeit“. Eine Aufgabe, ein Commit. Wenn später etwas kaputtgeht, findest du heraus, welche Änderung es war, und machst genau diese rückgängig.

Um sie wegzuwerfen, geh zu deinem letzten Commit zurück. In Git setzt git restore . die Dateien, die Git schon verfolgt, auf den Stand deines letzten Commits zurück, sofern die Änderungen nicht mit git add vorgemerkt wurden; Dateien, die die Assistenz neu angelegt hat, entfernt der Befehl nicht, also schau noch einmal mit git status nach und lösch sie von Hand. Editoren mit eigenem Rückgängig oder eigenen Checkpoints können dasselbe, in den Grenzen, die sie beschreiben. Dann schreib eine bessere Aufgabe: Sag, was schiefgegangen ist, und füge eine Prüfung hinzu, die es erkannt hätte.

Es ist verlockend, eine Änderung zu behalten, die größtenteils stimmt, und den Rest in der nächsten Aufgabe zu reparieren. Tu das nur, wenn du benennen kannst, was falsch ist, und es klein ist. Eine Änderung, die du nicht verstehst, wird nicht verständlicher, wenn die nächste darauf aufbaut. So geraten Spiele, die mit Assistenzen gebaut werden, außer Kontrolle, und deshalb lässt sich ein kleines erstes Spiel leichter am Laufen halten.

Kann eine andere KI die Prüfung übernehmen?

Sie kann den Diff mit dir lesen: Zeilen erklären, auf entfernte Prüfungen hinweisen, fragen, wozu eine neue Funktion da ist. Das hilft, besonders wenn du keinen Code liest. Sie kann aber nicht entscheiden, ob das Spiel noch tut, was du wolltest, denn das weißt nur du, und sie kann das Spiel nicht für dich spielen. Nutze sie als zweite Leserin, nie als Freigabe.

Häufige Fragen

Wie lange sollte eine Prüfung dauern? Ungefähr so lange, wie die Änderung klein ist. Dauert das Lesen des Diffs länger als das Schreiben der Aufgabe, war die Aufgabe wahrscheinlich zu groß; teile die nächste.

Brauche ich dafür Git? Du brauchst irgendeine Möglichkeit zu sehen, was sich geändert hat, und zurückzugehen. Git ist der übliche Weg und kostenlos; die meisten Editoren und Assistenzen arbeiten damit.

Was, wenn die Änderung stimmt, der Code aber unordentlich aussieht? Behalte sie, wenn sie funktioniert und du sie verstehst, und schreib eine eigene Aufgabe zum Aufräumen, mit denselben Prüfungen. Misch Aufräumen nicht in eine neue Funktion.

Soll ich Änderungen an Grafik, Ton und Level-Dateien prüfen? Ja, durch Hinsehen und Spielen statt durch Lesen des Diffs. Die Liste der geänderten Dateien sagt dir trotzdem, welche du ansehen musst.

Wann können andere es spielen? Wenn die Runde oben auf einer frischen Seite klappt und eine fremde Person das Spiel ohne deine Hilfe durchspielen kann. Dann kannst du es bei HeapPlay einreichen.