Un buon report di bug per un AI è lo stesso di un buon report per un umano: forniscigli abbastanza contesto per riprodurre il problema mentalmente, e riduci il rumore. L'AI può ragionare solo su ciò che incolla — descrizioni vaghe producono indovinazioni vaghe.
File non correlati, l'intera configurazione, segreti/chiavi API e teorie "penso che possa essere X" che influenzano la diagnosi. Dai fatti, non intuizioni.
❌ 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.
Con la versione forte, l'AI può puntare direttamente al controllo undefined mancante e proporre una protezione, perché ogni fatto di cui ha bisogno è sulla pagina.
Un assistente AI non ha accesso al tuo sistema in esecuzione — ragiona solo da ciò che fornisci. Un report debole lo costringe a indovinare l'errore, il codice e l'ambiente tutto insieme, e un'indovinazione sbagliata spreca un round-trip. Un report forte (traccia esatta + codice rilevante + atteso/effettivo + repro + versioni) trasforma la diagnosi in un compito focalizzato e di solito ottiene la correzione giusta al primo tentativo. Imparare a scrivere report di bug compatti ti rende anche un debugger migliore, perché ti costringe a isolare i fatti prima di chiedere.