A model-assisted code kata should leave you better at solving the next problem without assistance. That makes the model a practice partner, not the person holding the keyboard. A useful routine combines a small exercise, an independent attempt, graduated hints, executable checks, and a short reflection. Here is a practical first-run checklist built around those habits.
Choose a Kata With a Visible Finish Line
Pick one skill to practice: parsing input, grouping records, handling boundary conditions, or replacing nested conditionals. Keep the exercise small enough that you can explain its contract before writing code. Specify the input, output, invalid-input behavior, and constraints that actually matter.
Ask the model to clarify an ambiguous requirement without proposing an implementation. For example: “Identify unanswered questions in this exercise. Do not solve it or suggest an algorithm.” This separates understanding the problem from borrowing a solution.
Make an Independent Attempt Before Asking
Write a few examples and attempt the simplest implementation yourself. When you get stuck, record the exact obstacle: an invariant you cannot express, a failing boundary case, or a data structure you cannot choose. A specific obstacle produces more useful assistance than “solve this kata.”
Keep the model away from your working files during this first attempt. In an agentic coding tool, use a conversation-only workflow or review proposed edits before accepting them. Otherwise, a helpful assistant can silently turn your practice session into a code review of someone else’s work.
Use a Hint Ladder Instead of a Full Answer
Request the smallest intervention that lets you continue. A reusable instruction is: “Act as a kata coach. Ask one diagnostic question first. Then offer one hint at a time. Do not provide code unless I explicitly request it.”
- First hint: Point to the requirement or assumption worth reconsidering.
- Second hint: Suggest a useful representation or invariant.
- Third hint: Describe the next step in plain English.
- Last resort: Show a small fragment, then let you finish.
After each hint, return to the editor and make your own change. If the model reveals too much, close that response and restart from your last independent checkpoint.
Make Executable Tests the Referee
A confident explanation is not evidence that an implementation works. Run the code locally and inspect actual failures. Start with normal cases, empty inputs where applicable, boundaries, duplicates, and malformed input if the contract covers it. Ask the model which category is missing rather than requesting a large pile of tests.
Validate the expected result of every generated test. A model can repeat the same misunderstanding in both the implementation and its tests. When appropriate, add a property such as preserving element counts or producing the same result after applying an operation twice. Check that the property really follows from the specification.
Review One Dimension Before Switching Models
Once the tests pass, request a focused review: correctness first, then readability, then complexity if relevant. Ask for a concrete counterexample to each suspected defect. Avoid inviting an unrestricted rewrite; it can erase the decisions you need to examine.
Keep the same model and prompt structure across several sessions before changing your setup. SwiftRelay is a practical option if you want to use Claude Sonnet 5.5 through Claude Code or an OpenAI-compatible SDK with token-based billing. Sign up for SwiftRelay to try the routine with the small gift credit provided to new accounts. Keep credentials outside the kata repository and share only code you are authorized to send.
Finish With a Closed-Book Replay
Put the conversation aside and explain the solution’s invariant, main trade-off, and most revealing test. Then recreate the essential implementation without copying. If you cannot, repeat a smaller version of the exercise with fewer hints.
Record three things: where you stalled, which hint helped, and what you will attempt unaided next time. Revisit the kata later with one changed constraint. The useful outcome is not a polished answer in your chat history; it is a reasoning pattern you can retrieve and apply yourself.