AI Pair Programming for Junior Developers: Learn First

An AI assistant can explain a confusing error without making you feel awkward about asking. It can also produce a complete solution before you have understood the problem. For a junior developer, the difference between those outcomes is not the model's intelligence; it is the learning workflow around it.

Treat AI pair programming as guided practice with an unreliable partner. You should finish each session with working code and a stronger explanation of why it works. If you can only reproduce the result by reopening the conversation, the session has created dependency rather than useful understanding.

Set a learning goal alongside the task

Separate the delivery goal from the learning goal. “Fix the profile form” describes an output. “Understand why this controlled input resets after validation” describes knowledge you can reuse. Write both down before asking the assistant anything.

Choose a task small enough that you can inspect the entire change. A single failing test, a request parser, or a keyboard interaction is usually better than a whole authentication flow. Large generated features introduce too many unfamiliar concepts at once, making it difficult to distinguish an explanation from a plausible story.

Make an initial attempt without AI. Read the error, locate the relevant code, and write your current hypothesis. Even an incorrect hypothesis gives you something specific to compare against the assistant's reasoning. This is active recall, not an exam you must pass before receiving help.

Agree with your mentor which tasks need human review and which tools the organisation permits. The AI coding assistants directory can help compare options, but repository policy, data handling, and learning needs should govern the choice. Do not install an extension with broad repository access simply because a tutorial recommends it.

Ask for hints before replacement code

Use a hint ladder. First request a question that helps you investigate. If you remain stuck, ask for the relevant concept or documentation section. Only then request a minimal example, preferably separate from your actual implementation. This preserves the work of connecting the concept to your code.

Set the interaction contract explicitly:

Act as a coding tutor, not an implementation service.
My goal is to understand why this test fails.
Ask me for my hypothesis first.
Give one hint at a time and wait for my response.
Do not provide replacement code unless I explicitly request it.
After the fix, ask me to explain an edge case without looking back.

The model may still ignore these constraints. If it dumps a full solution, stop and reduce the scope rather than copying it immediately. Ask it to discuss only the first failing assertion or one unfamiliar operator. Your workflow is responsible for maintaining the boundary.

Use MDN's learning resources to verify language and browser concepts. An assistant can translate documentation into simpler language, but the explanation should still match the platform. Ask which statements are facts from the documentation and which are guesses about your application.

Predict behaviour before running code

Before executing a proposed change, write down what you expect to happen. Which branch runs? What value is returned? Which DOM element receives focus? Prediction before execution makes gaps in your understanding visible instead of hiding them behind a green test result.

For asynchronous code, draw a short sequence in plain language: the user submits, validation runs, a request begins, the response arrives, and state updates. Then ask what happens if the component unmounts or a second request finishes first. This is often more educational than asking the model to “make it robust”.

When an API response is involved, use the JSON formatter with a synthetic payload to inspect nesting and value types. Locate the exact property your code reads and compare it with your prediction. Formatting makes structure visible; it does not prove that the server always returns that shape.

Ask the assistant for a counterexample to your explanation. If you believe a function always returns a number, try an empty string, missing field, or unexpected array. Verify those cases yourself. A useful tutor helps you test a mental model rather than merely praising a correct-looking answer.

Use tests as evidence, not decoration

Write the expected behaviour before accepting generated tests. Otherwise, the assistant may produce assertions that simply repeat its own implementation. A passing test proves little when both the function and the expected value share the same mistaken assumption.

Create one regression test that fails for the original bug and passes for the intended reason after the fix. Temporarily undo the fix to check that failure. Add a nearby edge case that distinguishes your solution from an easy but incorrect shortcut.

Learn the repository's existing test conventions instead of introducing a new framework for every exercise. If the project uses browser tests, the Playwright documentation provides a reference for locators, assertions, and execution. Keep unit and browser responsibilities distinct; a mocked function cannot prove that a real keyboard interaction works.

Review the entire diff, including lockfiles and configuration changes. Ask the assistant to explain unfamiliar lines, then check those explanations against documentation or a mentor. Passing checks are evidence, not permission to merge code you cannot describe. If a change touches credentials, permissions, or payments, escalate rather than relying on your current confidence.

Close the session with an independent explanation

After the task works, close the chat and explain the fix from memory. Describe the original cause, why the change addresses it, and what the tests do not cover. This teach-back step is a practical check on whether you learned the mechanism or only followed instructions.

Try a small transfer exercise the next day. Recreate the relevant pattern in a different component or solve a similar bug without hints. If that fails, revisit the concept rather than collecting another complete answer. Speed during the assisted session is not the same as retained skill.

Bring unresolved questions to a human reviewer. The GitHub pull request documentation explains the mechanics of review, but your description should include your reasoning, not a pasted conversation. State where AI helped and which assumptions you verified. Never submit confidential prompts or customer information as supporting material.

Keep a brief learning log with the concept, mistake, verification, and next exercise. Use the development collection to choose supporting topics when repeated gaps emerge. Over time, you should need fewer hints for familiar problems and ask better questions about unfamiliar ones. That is a more meaningful signal of progress than the number of generated lines you accepted.

Key takeaways

• Pair each delivery task with a specific learning goal.
• Attempt a diagnosis before asking for progressively stronger hints.
• Predict behaviour and test counterexamples yourself.
• Verify generated tests expose the original failure rather than echoing the implementation.
• Explain the solution independently and practise transferring the concept later.