Выстрой разумное парное программирование с явными личными правилами и запретными зонами, чтобы помощь никогда не превратилась в зависимость.
Открыть этот урок в KodokonУ профессионального риска постоянной помощи есть название в науке о человеческом факторе: самоуспокоенность от автоматики. Пилоты авиалиний знают его хорошо - чем надёжнее автоматика, тем меньше человек проверяет и тем незаметнее разрушаются его ручные навыки. У разработчика симптом вполне конкретный: ты принимаешь всё более длинные подсказки, всё менее внимательно их просматривая, и в день, когда ИИ недоступен или ошибается в какой-то тонкости, обнаруживаешь, что сам уже не умеешь. Противоядие - не воздержание, а явный контракт на использование, записанный чёрным по белому, который ты навязываешь сам себе.
Главное правило этого контракта умещается в три слова: я пишу, оно проверяет. Код ты пишешь сам, первым черновиком, без помощи; ИИ вступает только после, в роли ревьюера. Эта перестановка меняет всё: усилие производства - то самое, что строит и поддерживает навык, - остаётся за тобой, а ИИ вносит то, что умеет лучше всего: дотошный, неутомимый взгляд на твою работу. Это ровно противоположность господствующему рефлексу (пусть сгенерирует, а я потом бегло гляну), который переворачивает когнитивную нагрузку: модель производит, а тебе достаётся самая трудная роль - судить код, который ты не продумывал.
You are a senior code reviewer, demanding but supportive. I just wrote this code myself and I want a review that helps me improve, not a rewrite.
Context: [LANGUAGE, project constraints, what the code is supposed to do].
[PASTE YOUR CODE]
Review rules:
1. NEVER rewrite the code in full, not even a complete function.
2. Classify each remark: likely bug / production risk / readability / style.
3. For each likely bug, describe the exact input scenario that triggers it, WITHOUT giving the fix - I want to find it myself.
4. End by asking me about a design choice I made that seems questionable to you.
Format: numbered list, the most serious remark first. Maximum 8 remarks.Второй пункт контракта: запретные зоны. Заранее определи те части проекта, где ИИ не пишет ни строки, при любых обстоятельствах. Три категории обязательны. Первая - код, критичный для безопасности: аутентификация, управление сессиями, криптография, миграции данных, где правдоподобный, но неверный ответ обходится слишком дорого. Вторая - ядро бизнес-логики, та логика, что делает твой продукт ценным: именно её ты обязан знать досконально. И третья, наименее очевидная, - любое первое знакомство с новым понятием: если ты позволишь ИИ написать твой первый Mutex, твою первую сагу или твой первый воркер, ты никогда по-настоящему этому не научишься. В этих зонах у ИИ остаётся роль: объяснять, задавать вопросы, проверять. Но не производить.
You are my pair programming partner in navigator mode: you guide, I drive. I'm stuck on this problem:
[DESCRIBE THE PROBLEM + paste the error message or the relevant snippet]
Absolute rules:
1. Forbidden to give me code longer than one line.
2. Proceed with Socratic questions: help me form hypotheses, then design the test that verifies them.
3. If I head in the wrong direction, say so clearly and explain why, but let me find the right one.
4. When I've found it, ask me to restate the root cause in two sentences, and correct my wording if it's imprecise.
Start by asking me what I've already tried and what I concluded from it.Последний пункт: измерение. Контракт без метрики не проживёт и шести недель. Верная метрика - не количество промптов, а твой долг понимания: сколько блоков кода, отправленных в репозиторий за эту неделю, ты не смог бы переписать по памяти или подробно объяснить. Веди этот счёт честно, каждую пятницу. Если он растёт две недели подряд, ужесточи контракт: расширь запретные зоны, вернись к строгому «я пишу, оно проверяет». Итоговая проверка та же, что и в авиации: выключи автоматику один день в неделю и посмотри, что ты ещё умеешь.