Сделай ИИ заказчиком, который пишет техзадание под твой уровень, с этапами и проверяемыми критериями приёмки, но никогда не пишет код.
Открыть этот урок в KodokonКогда основы позади, туториалы перестают двигать тебя вперёд: они заставляют копировать решения по размеченной тропе. Уверенного разработчика двигает вперёд проект чуть выше его уровня - достаточно трудный, чтобы вынуждать принимать решения, и достаточно очерченный, чтобы не увязнуть. Проблема: откалибровать себя самому почти невозможно, ты берёшь либо слишком лёгкое, либо слишком амбициозное. ИИ отлично справляется с этой калибровкой, если дать ему правильную роль. Неправильный подход: «напиши мне приложение для учёта расходов» - ты получаешь готовый продукт и ноль навыка. Правильный подход: ИИ играет заказчика, который пишет техзадание; разработчик - ты.
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.Калибровка опирается на две вещи, которые знаешь только ты: что ты уже умеешь (будь честен, иначе проект окажется слишком лёгким) и над чем ты хочешь поработать (одна-две концепции, не шесть). Этапы превращают проект в петлю обратной связи: каждый шаг даёт демонстрируемое поведение, и это не даёт тебе увязнуть в строительстве архитектурного собора. А наблюдаемые критерии приёмки меняют всё: «код чистый» проверить нельзя, «импорт повреждённого файла показывает понятную ошибку и не роняет программу» проверяется за десять секунд. Ненаблюдаемый критерий - это мнение; наблюдаемый критерий - это приёмочный тест.
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.Этот ритуал проверки воспроизводит приёмку настоящего проекта: заказчик не читает твой код, он допрашивает поведение. Ценнее всего вопросы о крайних случаях - именно там ты обнаруживаешь, чего твоя реализация не умеет. Остаётся критический момент любого одиночного проекта: затык. Соблазн перейти к «напиши мне эту часть» достигает пика. Сопротивляйся ему протоколом градуированных подсказок: каждый уровень говорит чуть больше, а ты берёшь только тот уровень, которого хватает, чтобы сдвинуться с места.
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.