Grok for developers

Grok is a solid rubber duck that talks back. On grok.online it costs nothing and needs no account: Grok 4.20 is fast for quick questions, Grok 4.3 Thinking reasons before it answers and is the better pick for bugs, and Grok 4.7, the newest model, is there for the hardest problems with 10 of your 30 daily messages. All three read screenshots. Here are seven uses, each with a prompt you can open in the chat and adjust.

Find and fix problems

Most debugging time goes into understanding what is happening. These prompts speed that part up.

Decode a stack trace

Paste the full error, not a paraphrase, plus the lines it points to. Ask for the cause in plain words before any fix, so you can judge it.

I'm using [language and version] with [framework]. Here is the full error and stack trace: [paste error]. Here is the code it points to: [paste code]. Explain in plain words what went wrong and why, name the most likely cause first, then show the smallest change that fixes it.

Open it in the chat. The Code Assistant does the same in a single panel.

Get a map of code you didn't write

Inheriting a file with no comments is a rite of passage. Before you change anything, ask for a guided tour that names the risky parts.

I just inherited this [language] file and need to change [feature]. Give me a short tour: what the file is responsible for, the main functions in the order they run, which global state or side effects to watch for, and the safest place to make my change: [paste code]

Get the tour, then ask about any function that still looks odd.

Hunt a logic bug with a thinking model

When nothing crashes but the output is wrong, you need careful tracing. Grok 4.3 Thinking walks through the code before it replies, which suits off-by-one errors and broken conditions.

This [language] function should [expected behaviour], but for the input [input] it returns [actual output] instead of [expected output]. Trace the execution step by step with that input, show the values of the key variables at each step, and point to the exact line where it goes wrong: [paste function]

Trace it with Grok 4.3 Thinking.

Fix a broken layout from a screenshot

Attach a screenshot of the page as it looks now, paste the relevant HTML and CSS, and describe what it should look like.

I've attached a screenshot of a page where [describe the problem, e.g. the sidebar overlaps the content on narrow screens]. Here is the HTML and CSS for that part: [paste code]. Explain what causes it and give me the corrected CSS, changing as little as possible.

Open this prompt and attach your screenshot.

Plan a risky refactor

Untangling a large module is where the newest model earns one of its limited daily messages. Ask for a plan, not a rewrite.

Below is a [language] module that has grown hard to change: [paste code]. Don't rewrite it yet. Describe its responsibilities, the hidden dependencies, and a refactoring plan in small steps where the code still works after each one. Say which tests I should add before step one.

Plan it with Grok 4.7, then send the steps one by one to Grok 4.20.

Write the code around the code

Tests, queries, reviews and docs are the parts that slip when deadlines get close.

Write tests for the edge cases you skipped

Ask for the list of cases first and the test code second. The list is where the value is.

Here is a [language] function: [paste function]. First list the edge cases worth testing, such as empty input, boundaries and invalid types, with one line each on why. Then write the tests using [test framework], one test per case, with clear names.

Generate the tests, run them, and keep the ones that fail for good reasons.

Get a grumpy senior's code review

Grok will happily play the reviewer who has seen every bug twice. Grumpy is fine; vague is not, so ask for line references.

Review this diff like a grumpy but fair senior engineer. Point out bugs, unclear names, missing error handling and anything that will hurt in six months, each with a line reference and a suggested fix. Rank the issues by severity and skip pure style nitpicks: [paste diff]

Request the review before your teammates see it.

Turn a schema into SQL and a README

Give the table definitions and the question in plain words, and ask for a short explanation with the query.

Here are my table definitions for [database, e.g. PostgreSQL]: [paste schema]. Write a query that returns [what you need in plain words]. Explain each join and filter in one line, and tell me which index could speed it up once the tables hold millions of rows.

Write the query, then ask for a README section that documents the tables.

What to avoid

• Pasting secrets. API keys, passwords, tokens and customer records do not belong in any chat. Replace them with placeholders.
• Trusting library details blindly. The models have a knowledge cut-off and no internet access, so a function or option may be outdated or invented. Check the official docs.
• Shipping untested output. Code that reads well can still fail. Run it, test it, review it.
• Sending whole repositories. Very long messages are trimmed. Send the function that matters.

Related pages

• Twenty more starting points in the coding prompts.
• Our guide to coding with Grok and an explainer on reasoning models.
• Building your own app? Read about the Grok API.