Преврати ИИ в требовательного ревьюера по читаемости, багам и безопасности и отточи своё суждение, защищая свои решения от его замечаний.
Открыть этот урок в KodokonРевью кода коллегами - один из самых хорошо документированных ускорителей роста в профессии и один из самых труднодоступных, когда работаешь в одиночку. ИИ даёт ревьюера, доступного круглые сутки, при одном условии: его нужно настроить. По умолчанию модель соглашается: хвалит твои старания, отмечает пару мелочей и заключает, что «в целом работа хорошая». Это не ревью, это похлопывание по плечу. Зеркальная ошибка - попросить «перепиши мой код красиво»: ты получаешь код, который никогда не продумывал, и ничему не учишься. Правильный подход: потребовать структурированную критику - читаемость, баги, безопасность - с откалиброванной серьёзностью и обоснованиями.
You're a demanding senior reviewer, as in a team code review. Your goal is to make me improve, not to go easy on me.
Here's my code ([language], context: [what it's for, the project's constraints]):
[paste the code]
Analyze it along three axes:
1. Readability: naming, structure, needless complexity, unclear intent.
2. Bugs: unhandled edge cases, silent errors, inconsistent states, concurrency.
3. Security: unvalidated inputs, injections, exposed sensitive data, permissions.
Output format: for each remark - the line or block concerned, the axis, the severity (blocking / important / minor), and the WHY in one or two sentences.
Constraints: don't rewrite my code. At most 8 remarks, the most serious first. If a debatable choice can be defended depending on the context, say so explicitly instead of counting it as a flaw.Обрати внимание на потолок в 8 замечаний, отсортированных по серьёзности: без него ты получишь 25 придирок, где пропущенная валидация ввода весит столько же, сколько вкусовщина в именовании. Обрати внимание и на оговорку о защитимых решениях: она заставляет модель отделять объективный дефект от спорной договорённости. Дальше идёт самая полезная часть, которую почти все пропускают: защита своих решений. Ревью - не приговор к исполнению, а диалог. Когда замечание кажется необоснованным, спорь. Либо твои доводы выдержат, и ты наконец их сформулируешь, либо они рассыплются, и ты обнаружишь, что это «решение» было просто привычкой.
Let's revisit your remark number [X]: you consider that [restate the remark].
I disagree, and here are my reasons: [your arguments - measured performance constraint, consistency with the rest of the code, deliberate simplicity, deadline...].
1. Honestly assess each of my arguments: which hold, which are rationalizations?
2. Give the strongest possible counter-argument to my position, as an experienced colleague who disagrees would.
3. Conclude: in MY specific context, is the change worth its cost? Answer yes or no, then justify in three sentences maximum.
Don't try to prove me right: if my arguments are weak, say so bluntly.Две классические ловушки ревью от ИИ. Ловушка первая: ложные тревоги, поданные уверенно, - модель указывает на гонку данных, невозможную в твоей архитектуре, или на «баг», который в твоей версии языка багом не является. Относись к каждому замечанию как к словам блестящего коллеги, у которого нет доступа ко всему контексту: правдоподобно, требует проверки. Ловушка вторая: театр безопасности. ИИ отлично замечает классические шаблоны (SQL-инъекции, XSS, секреты в открытом виде), но упускает дыры в бизнес-логике - пропущенную проверку прав на маршруте, эксплуатируемое промежуточное состояние. Ревью от ИИ дополняет, но не заменяет ни аудит, ни твоё знание предметной области.