Grok voor developers

Grok is een uitstekende rubber duck die ook nog eens antwoord geeft. Op grok.online is het helemaal gratis en heb je geen account nodig: Grok 4.20 is snel voor korte vragen, Grok 4.3 Thinking redeneert eerst na voordat het antwoordt (ideaal voor bugs) en Grok 4.7, het nieuwste model, staat klaar voor de lastigste problemen met 10 van je 30 dagelijkse berichten. Alle drie kunnen ze overweg met screenshots. Hier zijn zeven toepassingen, elk met een prompt die je direct in de chat kunt openen en aanpassen.

Problemen vinden en oplossen

De meeste tijd bij het debuggen gaat zitten in begrijpen wat er eigenlijk gebeurt. Deze prompts versnellen dat proces.

Een stacktrace ontcijferen

Plak de volledige foutmelding, geen samenvatting, inclusief de regels waar deze naar verwijst. Vraag eerst om de oorzaak in gewone mensentaal voordat je om een oplossing vraagt, zodat je het zelf goed kunt beoordelen.

Ik gebruik [taal en versie] met [framework]. Hier is de volledige foutmelding en stacktrace: [plak foutmelding]. Hier is de code waar het naar verwijst: [plak code]. Leg in duidelijke taal uit wat er misging en waarom, noem de meest waarschijnlijke oorzaak eerst en laat dan de kleinst mogelijke wijziging zien die het oplost.

Open dit in de chat. De Code Assistant doet precies hetzelfde in één overzichtelijk paneel.

Code doorgronden die je niet zelf hebt geschreven

Een bestand erven zonder enig commentaar hoort er nu eenmaal bij. Vraag om een rondleiding die de risicovolle onderdelen aanwijst voordat je iets aanpast.

Ik heb zojuist dit [taal]-bestand overgedragen gekregen en moet [functionaliteit] aanpassen. Geef me een korte rondleiding: waar het bestand verantwoordelijk voor is, de belangrijkste functies in de volgorde waarin ze draaien, op welke globale status of side-effects ik moet letten, en de veiligste plek om mijn wijziging door te voeren: [plak code]

Vraag de rondleiding aan en stel daarna gerichte vragen over functies die er nog steeds vreemd uitzien.

Een logische bug opsporen met een denkmodel

Wanneer er niets crasht maar de uitvoer simpelweg niet klopt, moet je de code stap voor stap nalopen. Grok 4.3 Thinking analyseert de code grondig voor het antwoordt — perfect voor off-by-one-fouten en foute voorwaarden.

Deze [taal]-functie zou [verwacht gedrag] moeten doen, maar voor de invoer [invoer] geeft het [werkelijke uitvoer] terug in plaats van [verwachte uitvoer]. Doorloop de uitvoering stap voor stap met die invoer, toon de waarden van de belangrijkste variabelen bij elke stap en wijs de exacte regel aan waar het misgaat: [plak functie]

Loop het na met Grok 4.3 Thinking.

Een kapotte lay-out herstellen vanaf een screenshot

Voeg een screenshot toe van hoe de pagina er nu uitziet, plak de relevante HTML en CSS erbij en beschrijf hoe het er eigenlijk uit zou moeten zien.

Ik heb een screenshot bijgevoegd van een pagina waarop [beschrijf het probleem, bijv. de zijbalk overlapt de content op smalle schermen]. Hier is de HTML en CSS van dat onderdeel: [plak code]. Leg uit wat dit veroorzaakt en geef me de gecorrigeerde CSS, waarbij je zo min mogelijk aanpast.

Open deze prompt en voeg je screenshot toe.

Een risicovolle refactor plannen

Het ontwarren van een omvangrijke module is hét moment om een van je schaarse dagelijkse berichten voor het nieuwste model te gebruiken. Vraag om een plan, niet meteen om een herschreven versie.

Hieronder staat een [taal]-module die lastig aan te passen is geworden: [plak code]. Schrijf deze nog niet direct helemaal opnieuw. Beschrijf de verantwoordelijkheden, de verborgen afhankelijkheden en een refactorplan in kleine stappen, waarbij de code na elke stap blijft werken. Geef aan welke tests ik vóór stap één moet toevoegen.

Plan het met Grok 4.7 en stuur de stappen vervolgens een voor een door naar Grok 4.20.

Schrijf de code rondom je code

Tests, queries, reviews en documentatie schieten er vaak bij in zodra deadlines dichterbij komen.

Tests schrijven voor randgevallen die je hebt overgeslagen

Vraag eerst om een overzicht van de scenario's en pas daarna om de testcode. De echte waarde zit namelijk in de lijst zelf.

Hier is een [taal]-functie: [plak functie]. Maak eerst een lijst van randgevallen die de moeite waard zijn om te testen, zoals lege invoer, grenswaarden en ongeldige typen, met telkens één regel uitleg waarom. Schrijf daarna de tests met [testframework], één test per geval, met duidelijke namen.

Genereer de tests, voer ze uit en behoud de tests die om een goede reden falen.

Vraag om een code review van een knorrige senior dev

Grok kruipt met plezier in de rol van de reviewer die elke mogelijke bug al twee keer heeft gezien. Streng mag best, maar vaag niet — vraag dus altijd om regelnummers.

Beoordeel deze diff als een strenge, maar rechtvaardige senior engineer. Wijs bugs, onduidelijke namen, ontbrekende foutafhandeling en alles wat over zes maanden voor problemen zorgt aan, telkens met regelnummer en een voorgestelde oplossing. Sorteer de punten op ernst en laat puur cosmetische opmerkingen achterwege: [plak diff]

Vraag de review aan voordat je teamgenoten ernaar kijken.

Een schema omzetten in SQL en een README

Geef de tabeldefinities en je vraag in gewone taal door, en vraag om een korte toelichting bij de query.

Hier zijn mijn tabeldefinities voor [database, bijv. PostgreSQL]: [plak schema]. Schrijf een query die [wat je nodig hebt in gewone taal] ophaalt. Leg elke join en filter in één regel uit en vertel me welke index dit sneller kan maken zodra de tabellen miljoenen rijen bevatten.

Genereer de query en vraag daarna meteen om een stukje documentatie voor je README over de tabellen.

Waar je op moet letten

• Plak geen geheime gegevens. API-sleutels, wachtwoorden, tokens en klantgegevens horen niet thuis in een chat. Vervang ze altijd door placeholders.
• Vertrouw library-details niet blindelings. De modellen hebben een vaste kennisgrens en geen live internettoegang, waardoor een functie of optie verouderd of verzonnen kan zijn. Controleer altijd de officiële documentatie.
• Gebruik nooit ongeteste code in productie. Code die er logisch uitziet, kan alsnog fouten bevatten. Uitvoeren, testen en controleren blijft nodig.
• Stuur geen complete repositories mee. Heel lange berichten worden ingekort. Deel alleen de functie waar het daadwerkelijk om gaat.

Gerelateerde pagina's

• Bekijk nog twintig voorbeelden bij onze coding-prompts.
• Lees onze gids over programmeren met Grok en de uitleg over redeneermodellen.
• Bouw je een eigen app? Lees alles over de Grok API.