How to Learn Coding With AI and Check What You Understand

Keep a separate goal for what you want to learn

When you use AI to learn coding, define two outcomes: a working program and a concept you can explain without the assistant. They need separate checks. Running code tells you something about the program; predicting its behavior and diagnosing a change tell you something about your understanding.

This evergreen guide takes a question from a March 15, 2026 X discussion by Franziska Hinkelmann about how developers use AI: what are you actually getting better at? We could not verify a relevant discussion from the last 72 hours. We are not treating the post's claims about future careers as evidence or presenting it as current news.

The practice session below is Jobisque's suggested exercise. It has not been tested as an educational intervention, and it does not promise faster learning or a hiring advantage. Its purpose is to give you concrete ways to notice the difference between completing a task and understanding it.

What the research can and cannot tell you

In a January 2026 randomized study, Anthropic examined developers learning an unfamiliar Python library. The AI-assisted group performed worse on an immediate comprehension quiz on average. The study was small and did not establish long-term learning outcomes. Its analysis of different interaction styles was descriptive, so it cannot prove that one prompting habit caused better learning.

Productivity is a separate question. In a February 2026 update, METR explained why selection effects and time measurement problems made its newer developer experiment difficult to interpret. That update is a reason to keep the setting and measurement method attached to productivity claims, rather than importing an old average into your own work.

Our practical takeaway is to record your own learning evidence alongside task completion. Neither study establishes that every learner should avoid AI, or that a particular assistant will help you master a concept. Treat the exercise as something to inspect and adapt.

Choose a small program with an obvious result

For a beginner exercise, write a function that takes a list of fictional support tickets and groups them by status. Use only invented records. Each ticket has an identifier and a status; the output counts how many are open, pending, or closed. Decide what should happen when a status is missing or unfamiliar.

The learning objective might be dictionary lookup and accumulation. Keep that objective narrow. A web interface, database, and deployment would add work without necessarily helping you understand this particular operation.

Before opening the assistant, write an input of five tickets and calculate the expected counts by hand. Include a repeated status and an empty list. These examples give you a reference you understand independently. They also reveal whether you have defined the problem clearly enough to begin.

Make a prediction before asking for help

Try to describe the steps in ordinary language: start with empty counts, inspect each ticket, choose its category, and update that category. Identify the part you do not understand. Perhaps you are unsure how to handle a category that has not appeared before.

Ask one focused question about that gap. For example: “Explain two ways to initialize a missing dictionary entry. Use a different example from my ticket task, then ask me to choose an approach.” This is a proposed prompt, not a requirement for a particular product mode.

Write down your choice and predict what happens on the first ticket. Then implement or revise the code. If you ask for a complete solution, still pause before running it and predict the output on your five-ticket example. Save your prediction even if it turns out to be wrong.

Explain the mismatch when a result surprises you

When a test fails, copy the actual output into a short note beside your expected output. Describe the difference before asking the assistant to fix anything. “It is broken” gives you little to investigate; “the pending count resets for each ticket” points to a specific behavior.

Read the part of the code that changes the count. Form a hypothesis about why the mismatch happened, then use a smaller input to check it. Two tickets with the same status may be enough to reveal an initialization mistake.

You can ask the assistant to critique your hypothesis or explain an error message. After making a change, say why that change should affect the result. The aim is to leave a record of your reasoning, including the moments when your first explanation was incomplete.

Close the chat and change one requirement

After the original examples work, close the assistant and make a small change yourself. For instance, add an “unknown” category for missing statuses. Write the expected result for a new input before editing the function.

Then explain the code to an imaginary teammate: what enters the function, where state changes, and what leaves it? Identify one line that would produce the wrong result if moved inside or outside the loop. If you cannot explain it, mark that topic for review rather than treating the finished program as proof of mastery.

This check is deliberately modest. One successful variation does not establish professional competence. It gives you a specific observation: you could, or could not yet, apply the concept to a nearby problem without immediate assistance.

Keep a learning note you can use tomorrow

Save four things: your first prediction, a mistake you investigated, your explanation of the fix, and the variation you attempted without AI. Distinguish what you wrote from what the assistant supplied. A short honest note is easier to revisit than a long chat transcript with no conclusion.

On another day, try a similar problem with different data, such as counting fictional event registrations by session. Record where you needed help again. Repeated difficulty is useful information for choosing the next practice topic; it is not a reason to manufacture a success story.

If you also want to measure work output, use our AI workflow testing guide. For sharing a completed example, follow the AI skills portfolio guide. Describe the learning check separately from the program's behavior so a reader can see what you actually demonstrated.

Sources

• Anthropic: How AI assistance impacts the formation of coding skills, published January 29, 2026; checked September 29, 2026. Historical study, not a measurement of this exercise.
• METR: Changing the developer productivity experiment design, published February 24, 2026; checked September 29, 2026. Measurement limitations and selection effects.
• Franziska Hinkelmann on X, March 15, 2026. Historical discussion context; career predictions in the post are not adopted here.