Getting calibrated mini-projects generated for you - without the code

Make the AI a client who writes a spec at your level, with milestones and verifiable success criteria, but never the code.

8 min · 3 questions

Once you're past the fundamentals, tutorials stop moving you forward: they have you copy solutions along a marked path. What moves a competent developer forward is the project slightly above their level - hard enough to force decisions, framed enough not to get bogged down. The problem: calibrating yourself is nearly impossible, you pick something too easy or too ambitious. The AI excels at that calibration, provided you give it the right role. The wrong approach: "code me an expense-tracking app" - you get the finished product and zero skill. The right approach: the AI plays the client who writes the spec; the developer is you.

You're a project client (product owner). You write specs, you NEVER write code.

My profile: I practice [language/tech] regularly. I already know: [honest list]. I want to improve on: [targeted concepts, e.g.: async error handling, testing, splitting into modules].
Time available: about [X] hours, spread over [duration].

Write a spec for a mini-project:
- The need in 5 lines maximum, phrased as a real client would (the WHAT, never the HOW).
- 3 to 5 ordered milestones, each ending in something functional and demonstrable.
- For each milestone: OBSERVABLE success criteria ("command X displays Y", "case Z is rejected with a clear message" - not "the code is clean").
- One technical constraint that forces me to use the targeted concepts.
- 2 optional extensions if I finish early.

Prohibitions: no code snippets, no imposed function or library names, no implementation hints. The implementation is my job.

The calibration rests on two pieces of information only you have: what you already know (be honest, or the project will be too easy) and what you want to work on (one or two concepts, not six). The milestones turn the project into a feedback loop: each step delivers a demonstrable behavior, which prevents you from getting bogged down building a cathedral of architecture. As for the observable success criteria, they change everything: "the code is clean" can't be verified, "importing a corrupted file shows an explicit error without crashing" can be verified in ten seconds. A non-observable criterion is an opinion; an observable criterion is an acceptance test.

You're the client for the following project: [restate the spec or paste the current milestone].

I think I've finished milestone [X]. Here's what my program does, from a user's point of view: [describe the observable behavior, not the code].

1. Go through each success criterion for the milestone: ask me precise questions to verify it's genuinely met, edge cases included (empty input, out-of-range value, action repeated twice).
2. If a criterion isn't met, say which one and how, without telling me how to fix it.
3. If everything passes, state the next milestone - still without code or implementation hints.

This validation ritual reproduces the acceptance testing of a real project: the client doesn't read your code, they interrogate the behavior. The questions about edge cases are the valuable part - that's where you discover what your implementation doesn't handle. There remains the critical moment of any solo project: getting stuck. The temptation to flip to "write this part for me" is at its peak. Resist it with a graduated hints protocol: each level says a bit more, and you consume only the level you need to get moving again.

I'm stuck on my project [context]. The blocker: [what you're trying to do, what you've tried, where it breaks].

Give me GRADUATED hints, one level at a time:
- Hint 1: the general lead - a concept to revisit or a direction, in one sentence.
- Hint 2 (only if I ask): more precise - which part of MY approach to reconsider.
- Hint 3 (only if I ask): the principle of the solution, explained in plain English, no code.

Start with hint 1 and wait for my reply. Never skip a level, even if I get impatient or insist.

Knowledge check

Make sure you remember the key points of this lesson.

1. What role should you give the AI so a mini-project actually moves you forward?
   • Developer: it codes, you review
   • Client: it writes the spec and signs off milestones, you code
   • Pair: it codes one half, you code the other
2. Which of these success criteria is correctly phrased?
   • "The code must be clean and maintainable"
   • "The architecture must be solid"
   • "Importing an empty file shows an explicit error without crashing the program"
   • "The application must be performant"
3. Mid-project, you've been stuck for an hour. Which reflex preserves learning?
   • Ask for the code of the blocking part to move on
   • Abandon the project and generate an easier one
   • Ask for graduated hints, one level at a time, no code