Friday at the API Desk: AI Exercises for Juniors

You have 45 minutes before a junior developer’s pairing session, and the onboarding repository still contains last year’s examples. Instead of asking AI for ten random coding challenges, build one small exercise around work your team actually does. This walkthrough uses JavaScript pagination validation: narrow enough for a first session, but realistic enough to teach requirements, testing, and debugging.

1. Define the pagination contract before prompting

Create a scratch directory outside your production repository. Add three empty files: pagination.js, pagination.test.js, and mentor-notes.txt. Use your team’s existing test runner, or Node’s built-in test runner if you want a dependency-free exercise.

Write the contract in your notes first: normalizeLimit accepts an optional query-string value. An absent value returns 20. A string containing only decimal digits is accepted if its numeric value is between 1 and 50, inclusive. Everything else throws a RangeError. Leading zeros are allowed; whitespace, signs, decimals, and non-string inputs are rejected.

This specificity matters. Without it, the model may silently decide whether an empty string means zero, whether spaces are acceptable, or whether excessive values should be capped.

2. Generate a brief, not a finished solution

Send this prompt to your chosen model: “Create a 25-minute JavaScript exercise for a junior developer using the contract below. Return a learner brief, a function stub, and three starter tests. Do not include the implementation. Make the starter tests cover the default, one valid value, and one invalid value. Do not add requirements.” Paste your contract underneath.

For repeated mentoring sessions, I recommend RelayVano as a pay-as-you-go relay that works with Claude Code, Codex, Gemini CLI, and OpenAI-compatible SDKs. Sign up for RelayVano to run this workflow with your preferred supported tool; its API base is https://api.relayvano.com. Keep credentials in environment variables, never in the exercise files.

3. Audit every generated test against the contract

Copy the brief and stub into your scratch files, then inspect the tests yourself. Confirm that undefined returns 20, a value such as "12" returns 12, and "0" throws a RangeError. Run the tests and check that they fail because the function is unfinished, not because imports or test-runner settings are broken.

Reject any generated expectation that contradicts your notes. For example, accepting "12px" would reward permissive parsing rather than the requested validation. AI output is draft teaching material, not an answer key.

4. Prepare mentor-only boundary checks

Ask the model for additional test cases without an implementation. Keep these separate from the learner’s starter suite, but tell the learner that boundary checks will follow. Hidden tests should enforce published requirements, never introduce surprises.

• Accept "1", "50", and "007" with numeric results.
• Reject "", " 7", "7 ", "+7", "1.5", and "51".
• Reject null, the number 7, arrays, and objects.

Write a reference implementation yourself and verify both suites against it. Also try an intentionally flawed implementation using parseInt without full-string validation. Your checks should catch it.

5. Run the session with a hint ladder

Give the learner the brief, stub, starter tests, and one instruction: explain the intended behavior before writing code. Ask them to add two tests of their own. This reveals misunderstandings earlier than watching them type an implementation.

If they get stuck, offer hints in stages: identify the input type; separate the absent-value case; validate the whole string; check the numeric range. Ask AI for one hint at a time, explicitly excluding solution code. Let the learner decide what to change and explain why.

6. Review reasoning and save the next variation

Run the mentor checks together. For each failure, ask whether the problem lies in interpreting the contract, implementing it, or designing a test. Record the distinction rather than assigning a score based only on passing assertions.

Finish by asking the learner to explain why partial parsing is risky here. Save the reviewed exercise, tests, and hint ladder in your onboarding repository. For the next session, change one requirement, such as allowing surrounding whitespace, and ask the learner to update the tests first. That small variation checks understanding without generating another unrelated puzzle.