Grok per developer

Un revisore veloce e gratuito per il codice su cui ti blocchi: stack trace spiegati, bug off-by-one risolti, test per casi limite e documentazione pronta all'uso.

4 min di letturaAggiornato

Grok è un ottimo rubber duck che ti risponde davvero. Su grok.online è gratis e non serve un account: Grok 4.20 è veloce per le domande rapide, Grok 4.3 Thinking ragiona prima di rispondere ed è la scelta migliore per i bug, mentre Grok 4.7, il modello più recente, è perfetto per i problemi più complessi con 10 dei tuoi 30 messaggi giornalieri. Tutti e tre leggono gli screenshot. Ecco sette modi per usarli, ciascuno con un prompt da aprire direttamente in chat e personalizzare.

Trova e correggi i problemi

Gran parte del tempo di debug se ne va nel capire cosa stia succedendo. Questi prompt servono ad accelerare proprio questo passaggio.

Decodifica uno stack trace

Incolla l'errore completo, senza parafrasarlo, insieme alle righe di codice indicate. Chiedi la causa a parole semplici prima di qualsiasi fix, così da poterla valutare.

Sto usando [linguaggio e versione] con [framework]. Ecco l'errore completo con lo stack trace: [incolla errore]. Ecco il codice a cui punta: [incolla codice]. Spiega a parole semplici cosa è andato storto e perché, indica prima la causa più probabile e poi mostra la modifica minima necessaria per risolvere.

Aprilo in chat. Il Code Assistant fa la stessa cosa in un unico pannello.

Orientati nel codice scritto da altri

Ereditare un file privo di commenti è un rito di passaggio. Prima di toccare qualsiasi cosa, chiedi una panoramica guidata che segnali le parti a rischio.

Ho appena ereditato questo file in [linguaggio] e devo modificare [funzionalità]. Fammi una breve panoramica: di cosa è responsabile il file, le funzioni principali nell'ordine in cui vengono eseguite, lo stato globale o gli effetti collaterali a cui fare attenzione e il punto più sicuro in cui inserire la mia modifica: [incolla codice]

Ottieni la panoramica, poi chiedi chiarimenti sulle funzioni che ti sembrano ancora poco chiare.

Trova un bug logico con un modello di ragionamento

Quando non ci sono crash ma l'output è sbagliato, serve un'analisi riga per riga. Grok 4.3 Thinking esamina il flusso del codice prima di rispondere, l'ideale per errori off-by-one o condizioni errate.

Questa funzione in [linguaggio] dovrebbe [comportamento atteso], ma con l'input [input] restituisce [output effettivo] invece di [output atteso]. Esegui un trace passo dopo passo con questo input, mostra i valori delle variabili chiave a ogni passaggio e indica la riga esatta in cui si verifica l'errore: [incolla funzione]

Fai il trace con Grok 4.3 Thinking.

Correggi un layout rotto partendo da uno screenshot

Allega uno screenshot della pagina così com'è adesso, incolla l'HTML e il CSS pertinenti e spiega quale dovrebbe essere il risultato finale.

Ho allegato lo screenshot di una pagina in cui [descrivi il problema, ad es. la sidebar si sovrappone al contenuto sugli schermi piccoli]. Ecco l'HTML e il CSS della sezione: [incolla codice]. Spiega la causa del problema e forniscimi il CSS corretto, modificando il meno possibile.

Apri questo prompt e allega il tuo screenshot.

Pianifica un refactoring rischioso

Riorganizzare un modulo complesso è il compito ideale per sfruttare uno dei messaggi giornalieri del modello più recente. Chiedi un piano, non una riscrittura immediata.

Qui sotto trovi un modulo in [linguaggio] diventato difficile da modificare: [incolla codice]. Non riscriverlo subito. Descrivi le sue responsabilità, le dipendenze nascoste e un piano di refactoring a piccoli passi, assicurando che il codice continui a funzionare dopo ciascuno. Indica quali test dovrei aggiungere prima di iniziare il primo passo.

Pianificalo con Grok 4.7, poi passa i singoli passaggi a Grok 4.20.

Scrivi il codice di contorno

Test, query, review e documentazione sono le prime cose che si sacrificano quando le scadenze si avvicinano.

Scrivi test per i casi limite trascurati

Chiedi prima l'elenco dei casi e solo dopo il codice dei test. Il vero valore sta proprio in quella lista.

Ecco una funzione in [linguaggio]: [incolla funzione]. Per prima cosa elenca i casi limite che vale la pena testare, come input vuoti, valori limite e tipi non validi, spiegando il motivo in una riga per ciascuno. Poi scrivi i test usando [framework di test], un test per caso, con nomi chiari.

Genera i test, eseguili e tieni quelli che falliscono per motivi validi.

Ottieni una code review da un senior esigente

Grok vestirà volentieri i panni del reviewer severo che ha già visto ogni tipo di bug. Va bene essere pignoli, ma non vaghi: chiedi sempre i riferimenti alle righe.

Fai una review di questo diff come un senior engineer severo ma imparziale. Segnala bug, nomi poco chiari, gestione degli errori mancante e qualsiasi cosa che creerà problemi tra sei mesi, indicando per ciascuno il riferimento alla riga e una proposta di correzione. Ordina i problemi per gravità e tralascia le mere questioni di stile: [incolla diff]

Richiedi la review prima di sottoporre il codice al team.

Trasforma uno schema in SQL e un README

Fornisci la definizione delle tabelle e la tua richiesta a parole semplici, chiedendo una breve spiegazione insieme alla query.

Ecco le definizioni delle mie tabelle per [database, ad es. PostgreSQL]: [incolla schema]. Scrivi una query che restituisca [cosa ti serve a parole semplici]. Spiega ogni join e filtro in una riga, e indicami quale indice potrebbe velocizzarla quando le tabelle conterranno milioni di righe.

Genera la query, poi chiedi una sezione di README che documenti le tabelle.

Cosa evitare

  • Incollare dati sensibili. Chiavi API, password, token e dati dei clienti non vanno mai inseriti in chat. Sostituiscili con dei segnaposto.
  • Fidarsi ciecamente dei dettagli delle librerie. I modelli hanno una data limite di conoscenza e non accedono a internet: una funzione o un'opzione potrebbero essere obsolete o inventate. Verifica sempre sulla documentazione ufficiale.
  • Mandare in produzione codice non testato. Un codice ben scritto all'apparenza può comunque fallire. Eseguilo, testalo e controllalo.
  • Inviare interi repository. I messaggi troppo lunghi vengono troncati. Invia solo la funzione su cui devi lavorare.

Pagine correlate

Vuoi fare una domanda a Grok?

Niente account, download o carta di credito. Apri la chat, scrivi la tua domanda e leggi la risposta di Grok in tempo reale.

Apri Chat