Grok for coding: prompts, workflow and safe habits

Grok is a capable coding partner for the everyday parts of programming: reading an error message, writing a small function, sketching tests, explaining an unfamiliar file or turning a rough idea into a first version. In our chat it cannot run your code, open your repository or check today's documentation, so the quality of its help depends on what you paste and on how carefully you check what comes back. This guide covers both.

Where Grok helps, and where it does not

Grok works best on problems that fit in a conversation. Good fits:

• decoding a stack trace or compiler error and suggesting likely causes;
• writing a self-contained function, script, SQL query or regular expression;
• explaining what a block of code does, line by line if you want;
• drafting unit tests, including edge cases you might not think of;
• reviewing a short diff for bugs, unclear names and missing checks;
• translating code between languages or between library versions.

Weak fits: changes that touch many files it has never seen, anything that depends on the exact state of your system, and questions about a library release newer than its training. It also cannot test anything. Every snippet it writes is untested until you run it.

Paste the context a new teammate would need

The most common reason for a useless coding answer is missing context. Before asking, gather:

1. Language and versions. "Python 3.12, pandas 2" or "Node 22, Express 5". Version differences cause a large share of wrong answers.
2. The relevant code. The function that fails and whatever it calls, not the whole project.
3. The exact error. Copy the full message and stack trace; do not paraphrase it.
4. Expected versus actual. What should happen, what happens instead, and what you already tried.
5. Limits. No new dependencies, must stay compatible with an older version, must be readable by beginners.

Weak:
my code doesnt work, fix it

Strong:
Python 3.12. This function should return the average order value per
customer, but customers with a single order get NaN. Expected: their
only order's value. Here is the function and a sample of the data.
Explain the cause first, then give the corrected function. Do not add
new libraries.
---
[function]
[five sample rows]

The strong version tells Grok the language, the symptom, the expected result and a rule to respect, and asks for the explanation before the fix, so you learn what went wrong.

Prompts for common coding jobs

Understanding an error

Paste the full trace and the lines it points to, then ask: "List the three most likely causes, most likely first, and tell me how to confirm each one." You get a short diagnosis plan instead of a single guess.

Writing a function

Describe inputs, outputs and edge cases in plain words, then ask for code plus two or three example calls with their expected results. The examples double as a quick test you can run straight away.

Writing tests

Write pytest tests for the function below. Cover: normal input,
empty input, a single item, very large numbers and invalid types.
One test per case, with a clear name. Do not change the function.
---
[function]

Reviewing your own code

Ask for a review with a focus, for example: "Review this for bugs and unhandled errors only; ignore style." A focused review is shorter and easier to act on. Try the review prompt with your own snippet.

Explaining unfamiliar code

"Explain what this does as if I know JavaScript but not this library. Then list anything that looks risky or outdated." Asking for risks turns an explanation into a mini review.

A workflow that keeps you in control

1. Agree on a plan first. For anything bigger than a function, ask for an outline of the approach before any code. Fix the plan, then ask for the code.
2. Work in small pieces. One function or one change per message. Long outputs hide mistakes and can be cut off by the answer length limit.
3. Run it yourself. Paste results or new errors back into the same chat. "This is what happened when I ran it" is the most useful follow-up there is.
4. Read every line before you keep it. If you could not explain a line to a colleague, ask Grok to explain it, or rewrite it.
5. Commit in small steps. Version control makes it cheap to undo a suggestion that turned out badly.

The code assistant tool wraps these habits in a form: choose a task, paste code, get a structured answer. Our page for developers lists more ways to use Grok day to day, and the coding prompts are ready to fill in.

Which Grok model to use for code

• Grok 4.20 (default) is quick for explanations, small snippets, regular expressions and boilerplate.
• Grok 4.3 Thinking thinks before answering, which helps with tracing tricky bugs, algorithm questions and logic with many conditions.
• Grok 4.7 is the newest model in our chat, and xAI describes it as its flagship for coding and agentic tasks. You get up to 10 messages a day with it, so bring it your hardest problem with all the context in one message.

Our guide to reasoning models explains when the extra thinking time is worth it.

Mistakes to watch for

• Invented functions. Grok sometimes calls a method or option that sounds right but does not exist. If you do not recognise it, look it up in the official documentation.
• Old versions. Its knowledge has a cut-off date. A library may have renamed or removed something since. Tell it your version and check the changelog when in doubt.
• Happy-path code. First drafts often ignore empty input, missing files, time zones and network failures. Ask: "What inputs would break this?"
• Quiet changes. When fixing one thing, a model may "tidy" another. Ask for a minimal change, or for only the lines that differ.
• Security gaps. Watch for queries built by gluing strings together, missing input checks and secrets written into the code. Ask directly: "Is this safe against SQL injection?"

Keep secrets out of the chat

Before you paste code, remove API keys, passwords, tokens, connection strings, customer data and internal hostnames. Replace them with placeholders such as YOUR_API_KEY. If your employer has rules about sharing source code with outside services, follow them; when in doubt, reduce the problem to a small example that shows the same behaviour without the private parts. That smaller example often reveals the bug by itself. Our privacy and safety guide explains how messages travel through our chat.

FAQ

Can Grok run my code in your chat?

No. It reads and writes code but does not execute it, so it cannot see the real output. Run the code yourself and paste back the result or the error.

Can I send a screenshot of an error?

Yes, all three models read images. Pasting the text is still better when you can, because Grok can quote it exactly and nothing is misread.

Which programming languages does it know?

Grok is at home in the mainstream ones: Python, JavaScript and TypeScript, Java, C# and C++, Go, PHP, SQL, shell scripts and more. For rare languages and niche frameworks, expect more mistakes and check more carefully.

Why did the code stop halfway?

Answers have a length limit. Ask for "the rest, starting from the function you stopped in", or ask for one part of the program at a time.

Is it fine to use AI-written code at work?

That depends on your employer's rules and your project's license. Treat generated code like any outside contribution: review it, test it and make sure you are allowed to use it.