Grok för utvecklare

Grok är en klockren gummianka som svarar. På grok.online kostar det ingenting och kräver inget konto: Grok 4.20 är snabb för korta frågor, Grok 4.3 Thinking resonerar innan den svarar och passar bättre för buggar, och Grok 4.7 – den senaste modellen – tar sig an de svåraste problemen med 10 av dina 30 dagliga meddelanden. Alla tre kan läsa skärmdumpar. Här är sju användningsområden, vart och ett med en prompt som du kan öppna direkt i chatten och anpassa.

Hitta och fixa problem

Största delen av felsökningen går åt till att förstå vad som händer. De här prompterna snabbar på den biten.

Tyda en stack trace

Klistra in hela felmeddelandet, inte en sammanfattning, plus raderna det pekar på. Be om orsaken i klartext innan någon fix föreslås, så att du själv kan bedöma den.

Jag använder [språk och version] med [ramverk]. Här är hela felmeddelandet och min stack trace: [klistra in fel]. Här är koden det pekar på: [klistra in kod]. Förklara i klartext vad som gick fel och varför, nämn den mest sannolika orsaken först, och visa sedan minsta möjliga ändring som löser problemet.

Öppna i chatten. Vår Code Assistant gör samma sak i en samlad panel.

Få en överblick av kod du inte skrivit själv

Att ärva en fil helt utan kommentarer är ett klassiskt mandomsprov. Innan du ändrar något: be om en guidad genomgång som pekar ut riskerna.

Jag har precis ärvt den här filen i [språk] och behöver ändra [funktion]. Ge mig en snabb genomgång: vad filen ansvarar för, huvudfunktionerna i den ordning de körs, vilket globalt tillstånd eller sidoeffekter jag bör se upp med, samt säkraste stället att göra min ändring på: [klistra in kod]

Få en genomgång, och fråga sedan vidare om funktioner som fortfarande känns oklara.

Jaga logikbuggar med en resonerande modell

När ingenting kraschar men resultatet blir fel behöver du gå igenom koden steg för steg. Grok 4.3 Thinking analyserar koden innan den svarar, vilket passar perfekt för off-by-one-fel och trasiga villkor.

Den här funktionen i [språk] ska [förväntat beteende], men med indata [indata] returnerar den [faktiskt utdata] istället för [förväntat utdata]. Stega igenom körningen i detalj med den indatan, visa värdena på nyckelvariablerna i varje steg och peka ut exakt vilken rad det blir fel på: [klistra in funktion]

Felsök med Grok 4.3 Thinking.

Fixa trasig layout utifrån en skärmdump

Bifoga en skärmdump av hur sidan ser ut just nu, klistra in relevant HTML och CSS och beskriv hur det borde se ut.

Jag har bifogat en skärmdump av en sida där [beskriv problemet, t.ex. sidomenyn överlappar innehållet på smala skärmar]. Här är HTML och CSS för den delen: [klistra in kod]. Förklara vad som orsakar det och ge mig korrigerad CSS med så få ändringar som möjligt.

Öppna denna prompt och bifoga din skärmdump.

Planera en riskfylld refaktorisering

Att reda ut en stor modul är ett perfekt tillfälle att använda ett av dina begränsade dagliga meddelanden med den senaste modellen. Be om en plan, inte en omskrivning.

Här är en modul i [språk] som har blivit svår att ändra i: [klistra in kod]. Skriv inte om den ännu. Beskriv dess ansvarsområden, dolda beroenden och en plan för refaktorisering i små steg där koden fortfarande fungerar efter varje steg. Ange vilka tester jag bör lägga till före steg ett.

Planera med Grok 4.7, och skicka sedan stegen ett i taget till Grok 4.20.

Skriv koden runt omkring koden

Tester, databasfrågor, granskningar och dokumentation är det som ofta bortprioriteras när deadlinen närmar sig.

Skriv tester för specialfallen du hoppade över

Be om listan över testfall först och själva testkoden sedan. Det är i listan det verkliga värdet ligger.

Här är en funktion i [språk]: [klistra in funktion]. Lista först de gränsfall och specialfall som är värda att testa, som tom indata, gränsvärden och ogiltiga typer, med en rad om varför för varje. Skriv sedan testerna med [testramverk], ett test per fall, med tydliga namn.

Generera testerna, kör dem och behåll de som fallerar av rimliga skäl.

Få en kodgranskning av en grinig seniorutvecklare

Grok tar gärna rollen som granskaren som har sett alla buggar förut. Grinigt är helt okej, men luddigt duger inte – be därför om radreferenser.

Granska denna diff som en grinig men rättvis senior utvecklare. Peka ut buggar, otydliga namn, saknad felhantering och allt som kommer att ställa till det om sex månader, komplett med radreferens och lösningsförslag för varje punkt. Prioritera problemen efter allvarlighetsgrad och skippa rent stilpetande: [klistra in diff]

Be om granskningen innan dina kollegor ser koden.

Gör om ett schema till SQL och en README

Ange tabelldefinitionerna och vad du vill ta reda på i klartext, och be om en kort förklaring tillsammans med frågan.

Här är mina tabelldefinitioner för [databas, t.ex. PostgreSQL]: [klistra in schema]. Skriv en fråga som returnerar [vad du behöver i klartext]. Förklara varje join och filter på en rad, och ange vilket index som kan snabba upp frågan när tabellerna innehåller miljontals rader.

Skriv frågan, och be sedan om ett README-avsnitt som dokumenterar tabellerna.

Vad du bör undvika

• Klistra in hemligheter. API-nycklar, lösenord, tokens och kunddata hör inte hemma i någon chatt. Ersätt dem med platshållare.
• Lita blint på biblioteksdetaljer. Modellerna har ett kunskapsstopp och ingen internetåtkomst, så funktioner eller parametrar kan vara inaktuella eller påhittade. Dubbelkolla mot officiell dokumentation.
• Driftsätta otestad kod. Kod som ser snygg ut kan fortfarande krascha. Kör den, testa den och granska den.
• Skicka hela kodbaser. Väldigt långa meddelanden kortas ner. Skicka bara funktionen som faktiskt är relevant.

Relaterade sidor

• Tjugo fler utgångspunkter bland våra prompter för kodning.
• Vår guide till att koda med Grok och en introduktion till resonerande modeller.
• Bygger du en egen app? Läs mer om Grok API.