Before you begin

No previous experience required unless you choose a coding exercise. Use an account you are allowed to access; features vary by product and region.

What you will learn

  • Separate model claims from a verified code change.
  • Spot an incorrect average in a tiny example.
  • Choose tests before requesting a fix.
  • Explain why reasoning about code and executing it are different checks.

What the September 21 launch says

SpaceXAI announced Grok 4.7 on September 21, 2026, describing improvements in coding, extended tasks and checking its own work. The announcement lists access through Grok Build, Cursor and the API, among other routes. This is a September 28 source check, not an independent performance review.

A model is the system generating responses. A coding application adds tools such as file access and program execution. Availability through an integration does not mean every account has the same permissions, price or features. Check your chosen product's current conditions. This lesson requires no paid access or installation.

Sources: SpaceXAI: Introducing Grok 4.7

Begin with a mistake you can understand

Prerequisite: understand that a function takes inputs and returns an output. If those words are new, take the Learn Python course first. Our exercise uses ordinary arithmetic and can be completed on paper in about 20 minutes.

Imagine a Python function named average that accepts numbers. Its original return expression is sum(numbers) / 2. The sum function adds the numbers, while / divides. The fixed divisor is the bug: two happens to be the correct count for a list containing two items, but not for every list.

For [4, 8], the result is 6, which is correct. For [4, 8, 12], the sum is 24 and the average should be 8; dividing by two produces 12 instead. One passing example therefore fails to expose the mistake. These results are derived by arithmetic, not reported from running Grok or a Python program.

Define behavior before accepting a correction

A plausible replacement divides the sum by len(numbers), where len reports the number of items. But what should happen when the list is empty? There is no ordinary arithmetic mean of zero observations, and dividing by zero is not a useful result.

For this exercise, choose a clear contract: accept a nonempty list of finite numbers and reject an empty list with a helpful error. We are deliberately not designing a general statistics library. Text values, missing entries and infinities are outside the promised input; a real project would need to decide how to handle them.

A contract states what inputs are allowed and what result is expected. A test checks a particular case against that contract. Decide both before asking for a fix, so you can reject a response that quietly returns zero for missing data. Zero can be a genuine average and should not disguise an absent measurement.

Review a small test table before running code

Use four cases: [4, 8] should return 6; [4, 8, 12] should return 8; [-2, 2] should return 0; an empty list should be rejected. The first checks ordinary behavior, the second exposes the fixed divisor, the third checks mixed signs, and the fourth checks the input boundary.

Ask the assistant to explain each case and suggest the smallest change. If it rewrites your whole application, adds unrelated packages or asks for a network connection, it has expanded the task unnecessarily. An arithmetic function does not need those things.

Reading through a change and predicting its results is sometimes called a dry run. It can catch obvious mistakes without execution, but it cannot establish that real code parses, imports correctly or works in your environment. Later, run reviewed code in a suitable local learning environment and compare actual outputs. Never label a predicted test as executed.

Give the coding assistant a bounded brief

Weak prompt: 'Fix my program.' It provides neither the intended behavior nor a limit on changes. The improved prompt below specifies the bug, allowed inputs, empty-list rule and four expected results. It asks for a proposal, not permission to modify a project.

Follow-up: 'Explain why your fix passes the three-item case and what it does with an empty list. Mark every result as predicted unless you actually executed it.' Then manually recheck the arithmetic. A model's statement that tests pass is a claim until supported by the test output.

This exercise does not need a repository, an API key or access to your Downloads folder. If you later use an agent with files, begin with a disposable copy of a tiny project and inspect the proposed change. Keep secrets out of prompts, and do not approve unrelated installs or publication just because a coding assistant requests them.

Terms and the next step

Function: reusable code that performs a task. Input contract: the accepted inputs and promised behavior. Edge case: a boundary situation, such as an empty list. Regression: breaking previously working behavior during a change. Dry run: reasoning through steps without executing them.

The source's description of stronger self-checking is a reason to evaluate, not a replacement for your own tests. Continue with 'Learn Grok: Research Without Confusing Freshness With Truth' to practise checking claims, then the Learn Python course for functions, errors and executable tests.

Try this prompt

This is a suggested exercise, not a tested guarantee of any model’s output.

Review this Python return expression without executing anything or changing files: sum(numbers) / 2. It belongs to a function called average. The contract accepts a nonempty list of finite numbers; an empty list must raise a helpful error. Explain the bug and propose the smallest function-level fix. Predict results for [4, 8], [4, 8, 12], [-2, 2], and an empty list. Clearly label predictions, explain every new function used, and do not install packages or claim you ran tests.

Mini project & challenge

  1. Set aside 20–30 minutes. Calculate the four expected results yourself.
  2. Use the review prompt in a permitted tool, or ask a partner to propose the correction on paper.
  3. Inspect whether the proposal uses the actual item count and handles the empty list according to the contract.
  4. Record each suggested test as predicted or executed; this no-install exercise only produces predictions.
  5. Finish when you can explain both the divisor bug and the missing-data rule without looking at the response.
  6. Challenge: change the contract so an empty list returns None, then explain how a caller must distinguish None from the valid average 0. Do not silently mix both contracts.

Common mistakes

  • Testing only two numbers: include a different list length to expose the fixed divisor.
  • Returning zero for an empty list without deciding that behavior: distinguish missing data from a real zero.
  • Calling a predicted result a passed test: keep reasoning and execution evidence separate.
  • Granting broad file access for a small arithmetic question: start with the exact excerpt and a narrow task.

Check your understanding

  1. When was Grok 4.7 announced in the checked source?
  2. Does this article independently verify its coding performance claims?
  3. Why can dividing by two appear correct for [4, 8]?
  4. What is the correct average of [4, 8, 12]?
  5. What does len(numbers) represent?
  6. What is the chosen empty-list behavior in the main exercise?
  7. Why include [-2, 2] in the test cases?
  8. Does a dry run show that code successfully executed?
  9. What is a regression?
  10. Why does the challenge require callers to distinguish None from zero?
Show answers
  1. September 21, 2026.
  2. No. It attributes launch claims and provides an original paper-based exercise.
  3. That list has exactly two items, so the fixed divisor accidentally matches the count.
  4. 8: the sum is 24 and there are three items.
  5. The number of items in the list.
  6. Reject it with a helpful error, rather than inventing an average.
  7. It checks mixed-sign inputs and a legitimate average of zero.
  8. No. It predicts behavior without running the program.
  9. A change that breaks behavior that previously worked.
  10. None signals no average under the revised contract, while zero can be a valid numeric result.

In short

Start AI-assisted coding with a small contract and examples whose answers you know. Inspect the proposed fix, preserve edge-case behavior and distinguish predicted outcomes from real test evidence.

Continue the Understand AI course →

Sources & review notes

  1. SpaceXAI: Introducing Grok 4.7

    Announcement dated September 21, 2026; checked September 28. Provider performance claims have not been replicated. The arithmetic exercise is original and no model or code execution is claimed.

Product information was checked on 2026-09-28. This is a selected beginner guide, not an exhaustive archive of every announcement. Recheck access, pricing and compatibility before relying on a current product detail. Supplied screenshots remain unreplicated claims.