Dobry raport o błędzie dla AI to to samo co dobry raport o błędzie dla człowieka: daj mu wystarczająco dużo kontekstu, aby mógł odtworzyć problem w swojej głowie, i pozbądź się szumu. AI może rozumować tylko na podstawie tego, co wkleisz — niejasne opisy prowadzą do niejasnych zgadnięć.
Nieistotne pliki, całą konfigurację, sekrety/klucze API oraz teorie "Myślę, że to może być X", które wpływają na diagnozę. Podaj fakty, nie domysły.
❌ WEAK: "My login is broken, it throws an error. Why?"
→ no error text, no code, no repro → the AI can only guess
✅ STRONG:
Error (verbatim):
TypeError: Cannot read properties of undefined (reading 'id')
at getUser (auth.js:42)
Code (auth.js:40-43):
function getUser(token) {
const session = sessions.find(s => s.token === token); // returns undefined if not found
return session.user.id; // line 42: crashes when session is undefined
}
Expected: return null for an unknown token.
Actual: throws TypeError above.
Repro: call getUser('expired-token').
Env: Node 20, no framework.
W silnej wersji AI może wskazać bezpośrednio na brakujące sprawdzenie undefined i zaproponować zabezpieczenie, ponieważ każdy potrzebny fakt jest na stronie.
Asystent AI nie ma dostępu do twojego uruchomionego systemu — rozumuje tylko na podstawie tego, co podasz. Słaby raport zmusza go do zgadywania błędu, kodu i środowiska jednocześnie, a złe zgadnięcie marnuje runę. Silny raport (dokładny trace + istotny kod + oczekiwane/rzeczywiste + kroki reprodukcji + wersje) zamienia diagnozę w skoncentrowane zadanie i zwykle daje właściwą poprawkę za pierwszym razem. Nauka pisania zwartych raportów o błędach też czyni cię lepszym debuggerem, ponieważ zmusza cię do izolacji faktów przed pytaniem.