✗ Schlechtes Beispiel

Fehlersuche ohne Struktur

Wiederholte Fehldiagnosen · Kein systematischer Ansatz · Session endet ohne Lösung
📁 Projekt: frontendgui (React/Redux, Shopware-Konfigurator) 📄 Log: errors_new_tab 💬 4 Austausche + 3 Fehlversuche ⏱ ~40 Minuten (ohne Ergebnis)
Legende:
Vorbildlich
Problematisch
Achtung / Hinweis
Lerntipp

🗂 Hintergrund & Ausgangslage

⚠️

Nach dem Hinzufügen des PNG-Tabs (Walk-Through 2) funktioniert der MainButton in der AmountPrice-Komponente nicht mehr: Konfiguration wird nicht gespeichert, nicht an Shopware übergeben, der Konfigurator schließt sich nicht. Die Änderungen im PNG-Tab haben offensichtlich einen Fehler eingeführt.

Diese Session zeigt, wie eine Debugging-Aufgabe scheitert, wenn kein strukturierter Diagnose-Plan gefordert wird. Copilot springt zwischen verschiedenen Hypothesen, ändert Code, muss Änderungen zurückrollen, und verliert dabei immer mehr den Überblick über die tatsächliche Ursache.

Session-Überblick: Der Kreislauf

1

Fehler melden → Copilot analysiert

Vager Auftrag: "find and fix it" ohne strukturierten Kontext

2

Fehldiagnose 1: Async-Problem in triggerConfigValidation

Copilot ändert async/await-Logik → löst das Problem nicht

3

Rückgängig + erneut suchen

"das hat den fehler nicht behoben, bitte mach die änderung rückgängig" → Copilot rollt zurück

4

Fehldiagnose 2: Redux-Reducer-Registrierung

Copilot untersucht Ladereihenfolge → auch kein Ergebnis

5

Erneut rückgängig + Constraint

"suche erneut, versuche nicht, das frontend zu kompilieren" → Copilot rollt zurück

6

Hypothesen ohne Lösung

Tab-Index-Kollision, Action-Typ-Kollision, Race Condition – Session endet offen

💬 Die Session im Detail

Austausch 1 – Fehler melden: "find and fix it"
Entwickler
in the folder frontendgui there are changes that provide a new tab for png images to add to the configuration canvas. everything is working fine so far, but when the user clicks on the MainButton on the AmountPrice component the configuration should be saved, handed over to shopware and the configurator should close. this does not work anymore after those changes, so the changes must have introduced an error. find and fix it!
"find and fix it" ohne Diagnoseanweisung. Der Prompt beschreibt das Symptom, nicht den Kontext des letzten Diffs. Copilot muss raten, welche Dateien geändert wurden – und welche Hypothesen er zuerst verfolgen soll.
Kein git diff als Startpunkt. Die effizienteste Debugging-Strategie wäre: "Zeig mir den git diff der letzten Änderungen und identifiziere den Fehler darin." Stattdessen wird Copilot aufgefordert, die gesamte Codebasis zu durchsuchen.
Symptom korrekt beschrieben. "configuration should be saved, handed over to shopware and the configurator should close" – der Fehlerbereich ist klar. Aber der Suchraum für die Ursache ist zu groß.
💡Besser: "Die letzten Änderungen sind in [diesen Dateien]. Hier ist der git diff: [diff]. Welche Änderung könnte den MainButton in AmountPrice kaputt gemacht haben?" – Das gibt Copilot den richtigen Suchraum.
Copilot
[liest AmountPrice/index.js, Container, sucht nach PNG-Änderungen – viele Tool-Calls]

Ich habe das Problem gefunden! In triggerConfigValidation wird this.onAddToBasket() ohne await aufgerufen, und der Loading-State wird danach gesetzt statt davor.

Außerdem gibt onAddToBasket() das Promise nicht zurück.

[ändert triggerConfigValidation: loading:true vorher setzen, await hinzufügen, Promise-Rückgabe hinzufügen, Debug-Text entfernen]
Falsche Hypothese. Das async/await-Problem war kein Fehler, der durch die PNG-Änderungen eingeführt wurde – es war bereits vorher vorhanden. Copilot hat einen unabhängigen Code-Smell gefunden, aber nicht die eigentliche Ursache.
Viele Tool-Calls, kein roter Faden. Copilot hat zahlreiche Dateien gelesen, ohne zuerst einen Diagnose-Plan zu formulieren. Das ist das Debugging-Äquivalent von "wild raten".
Austausch 2 – Rückgängig + erneut suchen
Entwickler
das hat den fehler nicht behoben, bitte mach die änderung rückgängig und prüfe erneut, welche änderung den fehler verursacht
Korrekte Reaktion: Rückgängig fordern. Wenn eine Änderung den Fehler nicht behebt, ist das Rückgängigmachen zwingend. Copilot soll keine Änderung im Code lassen, die die Situation unklar macht.
"Prüfe erneut" ohne neuen Suchraum. Copilot bekommt keinen Hinweis, wo er jetzt suchen soll. Er sucht wieder breit – und landet bei einer anderen Hypothese.
💡Besser: "Mach die Änderung rückgängig. Jetzt suche ich anders: Hier ist der git diff der PNG-Änderungen: [diff]. Welche Zeile davon könnte den AmountPrice-Flow unterbrechen?"
Copilot
[macht die Änderungen rückgängig]

Jetzt untersuche ich systematisch: Das Problem könnte sein, dass getConf('reducers') aufgerufen wird bevor setConfiguration in CustomApplicationConfiguration ausgeführt wird.

[analysiert Import-Reihenfolge in index.js, Store.js, Reducers.js]

Eigentlich sollte das funktionieren, da CustomApplicationConfiguration als erster Import geladen wird... Lassen Sie mich die Ladereihenfolge prüfen.
Neue Hypothese, kein Fortschritt. Copilot wechselt von async/await zu Redux-Ladereihenfolge – ebenfalls ohne Beweis, dass das die Ursache ist.
"Eigentlich sollte das funktionieren..." Copilot zweifelt selbst an seiner Hypothese, aber führt die Analyse trotzdem fort. Das ist ein Signal, dass die Session nicht mehr strukturiert verläuft.
Austausch 3 – Zweiter Rückgängig + Constraint
Entwickler
deine letzte änderung hat den fehler nicht behoben, suche erneut, finde den fehler und fixe ihn. versuche nicht, das frontend zu kompilieren, das mache ich selbst
Guter Constraint: "versuche nicht, das frontend zu kompilieren". Copilot hatte versucht, das Ergebnis selbst zu testen – was in dieser Umgebung nicht funktioniert. Der Entwickler schränkt Copilots Tool-Nutzung sinnvoll ein.
Dritter Versuch ohne neuen Suchraum. "Suche erneut, finde den Fehler" ist kein neuer Input – es ist dieselbe Aufforderung wie zuvor. Copilot hat keine neuen Informationen, um anders zu suchen.
💡An diesem Punkt sollte die Session-Strategie gewechselt werden. Drei erfolglose Versuche sind das Signal, eine andere Debugging-Methode zu wählen: den git diff als Hauptinput verwenden oder die Session als Frage formulieren statt als "finde und fixe".
Copilot
[macht Änderungen rückgängig, sucht erneut]

Ich sehe jetzt ein potenzielles Problem! Tab-Index-Logik:
  • Wenn galleryHasImages = true und pngGalleryHasImages = true: Tab 0 = Upload, Tab 1 = Gallery, Tab 2 = PNG
  • Wenn galleryHasImages = false: Tab 1 = PNG, aber Code prüft immer activeTabIndex === 2

ABER – das Problem ist nicht der PNG-Tab, sondern der "Add to Cart"-Flow in AmountPrice. Lassen Sie mich anders suchen.

[analysiert weitere Hypothesen: Action-Typ-Kollision, pngImageGallery undefined, Race Condition]

DIESE ZEILE IST DAS PROBLEM! activeTabIndex === 2 && vectorize && !!maxColorAmount && colorAmount > maxColorAmount – wenn vectorize = true, wird continueButtonDisabled true... ABER das betrifft nur den ImageEditDialog, nicht AmountPrice.
Drei Hypothesen in einer Antwort, keine davon verfolgt. Copilot formuliert ein "PROBLEM GEFUNDEN" – und widerlegt es direkt danach selbst. Das ist das Kennzeichen einer erschöpften Suche ohne Struktur.
Kreisen ohne Ankerpunkt. Die Session dreht sich im Kreis: async/await → Redux → Tab-Index → Action-Kollision → Race Condition. Kein Hypothesen-Test, keine Eliminierung.
Austausch 4 – Session endet offen
Entwickler
(Session endet ohne weiteren Prompt – kein Ergebnis)
Keine Lösung gefunden. Nach ~40 Minuten und 3 Rückgängig-Aktionen ist der Fehler noch nicht behoben.
Copilot
[weitere Hypothesen: pngImageGallery State undefined, fetchPngTags/fetchPngGallery API-Fehler, componentDidMount-Timing]

Lassen Sie mich die Frage anders stellen: Was genau passiert, wenn "Add to Cart" geklickt wird? Gibt es einen Fehler in der Konsole? Bleibt es hängen? Schließt sich der Dialog nicht?

[kein weiterer Austausch]
Copilot stellt jetzt die richtigen Fragen – zu spät. "Was genau passiert?" ist die Frage, die am Anfang hätte gestellt werden sollen. Hätte Copilot diese Frage in Austausch 1 gestellt, wäre die Session effizienter verlaufen.
Session-Ende ohne Handlungsempfehlung. Copilot stellt eine Frage, die der Entwickler nicht mehr beantwortet. Die Session hat kein Ergebnis, keine Zusammenfassung, keinen nächsten Schritt.

✏️ So hätte die Session strukturiert werden sollen

💡

Debugging mit Copilot braucht einen strukturierten Ansatz. "Find and fix it" ist für Copilot kein ausreichender Input – er öffnet einen zu großen Suchraum und führt zu unstrukturierten Hypothesen.

Schritt 1: git diff als Ausgangspunkt

✓ Besser "Hier ist der git diff der letzten Änderungen: [diff]. Welche dieser Änderungen könnte den AmountPrice-Flow unterbrechen? Liste deine Hypothesen auf, bevor du etwas änderst."

Der git diff begrenzt den Suchraum auf das tatsächlich Geänderte. Copilot muss nicht die gesamte Codebasis durchsuchen.

Schritt 2: Plan vor Fix verlangen

✓ Besser "Erstelle zuerst eine Liste von Hypothesen, warum der AmountPrice-Button nach den PNG-Änderungen nicht mehr funktioniert. Dann prüfen wir sie der Reihe nach."

Ein expliziter Diagnose-Plan verhindert das Springen zwischen Hypothesen. Copilot formuliert erst alle möglichen Ursachen – dann wird die wahrscheinlichste zuerst geprüft.

Schritt 3: Nach jedem Fehlversuch Hypothese eliminieren

✓ Besser "Das hat den Fehler nicht behoben. Mach die Änderung rückgängig. Streiche diese Hypothese und prüfe die nächste auf deiner Liste."

Ohne explizites Eliminieren springt Copilot zu neuen Hypothesen, statt systematisch durch die bestehende Liste zu gehen.

Schritt 4: Konkretes Symptom beschreiben

✓ Besser "Beim Klick auf den MainButton: Loading-Spinner erscheint nicht / Spinner erscheint aber dreht sich ewig / Spinner verschwindet sofort aber Shopware bekommt keine Daten / Konfigurator schließt sich nicht. Was davon passiert?"

Je präziser das Symptom, desto gezielter die Suche. "Funktioniert nicht" öffnet jeden möglichen Fehlertyp.

📋 Fazit & Bewertung

✗ Gesamtbewertung: Nicht erfolgreich

Diese Session scheitert an einem strukturellen Problem: "find and fix it" ist keine Debugging-Strategie. Es eröffnet für Copilot einen unkontrollierbaren Suchraum, in dem er zwischen Hypothesen springt, ohne eine systematisch zu eliminieren.

Drei Rückgängig-Aktionen in einer Session sind das deutlichste Warnsignal: Copilot hat sich verirrt. Der richtige Zeitpunkt für einen Neustart mit einem anderen Ansatz wäre nach dem ersten Fehlversuch gewesen.

Was hätte funktioniert: git diff als Eingabe, expliziter Hypothesen-Plan, Symptom präzise beschreiben (was genau passiert beim Klick?), und nach jedem Fehlversuch eine Hypothese von der Liste streichen.

🎓 Learnings aus dieser Session

💡

5 übertragbare Erkenntnisse

1

git diff als Debugging-Ankerpunkt

"Find the bug" ohne Kontext gibt Copilot einen zu großen Suchraum. "Hier ist der git diff – welche Zeile könnte dieses Symptom verursachen?" gibt ihm den richtigen Ankerpunkt. Der diff begrenzt die Hypothesen auf das tatsächlich Geänderte.

2

Plan vor Fix: Hypothesen-Liste verlangen

"Liste zuerst deine Hypothesen auf, bevor du etwas änderst." Das erzwingt eine strukturierte Diagnose. Copilot muss alle Möglichkeiten nennen – dann prüfen wir sie der Reihe nach, statt zufällig zu springen.

3

Nach Fehlversuch: Hypothese eliminieren, nicht neu suchen

"Mach die Änderung rückgängig. Streiche diese Hypothese und prüfe die nächste auf deiner Liste." Ohne explizites Eliminieren kehrt Copilot zu ähnlichen Hypothesen zurück oder beginnt von vorne.

4

Symptom präzise beschreiben, nicht nur "funktioniert nicht"

Was genau passiert beim Klick? Kein Spinner? Spinner bleibt stehen? Konfigurator bleibt offen? Shopware bekommt keine Daten? Je präziser das Symptom, desto gezielter Copilots Suche.

5

Drei Fehlversuche = Session neu starten

Wenn man dreimal "mach es rückgängig, suche erneut" schreiben muss, ist die Session erschöpft. Ein Neustart mit einem anderen Ansatz (andere Eingabe, anderer Diagnose-Rahmen) ist effizienter als das Fortsetzen einer verlorenen Session.

Auf einen Blick: Was hat diese Session falsch gemacht?

ElementQualitätWarum
Erster Prompt ("find and fix it")⬇ ProblematischZu großer Suchraum, kein strukturierter Eingabepunkt
Kein git diff als Startpunkt⬇ ProblematischCopilot muss die gesamte Codebasis durchsuchen
Rückgängig-Forderungen (×3)⚠ Nötig aber vermeidbarRichtige Reaktion – aber jeder Fehlversuch kostet Zeit
Constraint "nicht kompilieren"⬆ GutVerhindert unnötige Tool-Nutzung
Symptom-Beschreibung⬇ Problematisch"Funktioniert nicht" ohne konkretes Verhalten
Hypothesen-Management⬇ ProblematischKein Plan, kein Eliminieren, kein roter Faden

🔗 Weitere Walk-Throughs

✓ Gutes Beispiel
Admin-Modul aufteilen
Copilot plant und implementiert vollständig
⚠ Gemischtes Beispiel
PNG-Tab im Konfigurator
Wenn Copilot die Absicht missversteht