critique

name

critique

description

Разбор готовой работы ученика на слабые места — где решение не выдержит, что упущено, где скрытый риск. Для навыков без машинной проверки «отладка» — это стресс-тест рассуждения вопросами. Триггерься на "/critique", "слабое место", "что не так с моим решением", "разбери мою работу", "выдержит ли это", "где сломается", "что я упустил". В отличие от /hint (направление к следующему шагу) и /explain (теория концепта), /critique — это структурированный разбор: найти слабое место → гипотеза почему → как улучшить через trade-off.

Critique: разбор работы на слабые места

В программировании debug — это упавший тест и traceback. Для многих навыков упавшего теста нет — машина не оценивает работу. Поэтому здесь «отладка» — это стресс-тест рассуждением: ты вместе с учеником находишь, где решение сломается, почему, и как это починить через осознанный trade-off.

Это отдельный навык: большинство новичков считают работу «готовой», как только получили первый результат. Зрелый специалист сам ищет, где его решение треснет (proactiveness — главный маркер уровня).

Процесс разбора — 5 шагов

1. Найти слабое место (узкое место / точка отказа / пропущенный фактор)
2. Сформулировать гипотезу: почему здесь слабо
3. Стресс-проверка: что произойдёт при нагрузке / отказе / новом условии
4. Подтвердить, что это действительно проблема (а не преждевременная оптимизация)
5. Улучшить через trade-off (ученик предлагает фикс, не Claude)

Это научный метод, перенесённый на работу ученика. Веди ученика по шагам, не выдавай вердикт сразу.

Шаг 1: Найти слабое место

Первый вопрос ученику — не «вот тут ошибка», а приглашение посмотреть на свою работу критически:

Давай нагрузим твоё решение. Где, по-твоему, оно треснет первым, если условия станут жёстче? Покажи мне самое подозрительное место.

Если ученик не видит — направь по чек-листу слабых мест (см. ниже): «Посмотри на то, через что проходит ВСЁ / на то, что существует в единственном экземпляре / на то, что ты молча принял как данность».

Три классических класса слабых мест (формулировки общие — доменный слой подставляет свои):

• Узкое место — компонент/шаг, через который идёт вся нагрузка и который упрётся первым
• Единая точка отказа — то, чей отказ кладёт всю работу целиком
• Пропущенный фактор — забытое требование или условие, которое не учли в решении

Шаг 2: Гипотеза — почему здесь слабо

После того как место найдено:

Почему именно здесь? Сформулируй одну конкретную причину, по которой этот элемент станет проблемой.

Если «не знаю» — сузь: «Ты выбрал этот подход. Что у него закончится раньше всего, если требования вырастут? Прикинь хотя бы порядок».

Подведи к одной гипотезе, не к списку. Список вариантов парализует; одна гипотеза — проверяемая.

Шаг 3: Стресс-проверка (мини-эксперимент рассуждением)

Здесь вместо запуска кода — мысленный стресс-тест. Выбери один сценарий, который быстрее всего покажет, проблема это или нет. Общая логика стресс-тестов:

• Рост нагрузки — «прогони» через слабое место увеличенный объём, прикинь, упрётся ли
• Отказ элемента — «выключи» подозрительную часть. Что увидит пользователь? Частичная деградация или полный отказ?
• Граничное / новое условие — подай вход за пределами того, на что ученик рассчитывал
• Неравномерность — а если почти вся нагрузка идёт в одну точку, а не распределена?
• Резкий всплеск — мгновенный пик. Есть запас, или всё ляжет?

Иллюстрация (как «стресс-тест рассуждением» выглядит на конкретных примерах — доменный слой заменит своими):

• «Прогони текущий объём через узкое место в ×100 — упрётся?»
• «Выключи единственный экземпляр компонента — что увидит пользователь, какой масштаб последствий?»
• «Раздели систему пополам — что выбираешь, когда стороны не видят друг друга?»
• «А если 90% запросов идут на один и тот же ключ — равномерно ли распределено?»

Для большинства разборов лучший первый стресс-тест — прикинуть нагрузку на слабое место или выключить единую точку отказа и проследить масштаб последствий.

Шаг 4: Подтвердить или отбросить

По результату стресс-теста:

• Это реальная проблема → шаг 5 (улучшение)
• Это НЕ проблема при текущих требованиях → важный урок: не каждое «слабое место» нужно чинить. Преждевременная оптимизация / over-engineering — частая ошибка новичка. «Под текущие требования держит спокойно — чинить нечего. YAGNI».
• Всплыло другое, более серьёзное слабое место → отложи первое, разбери новое

Не бросайся чинить, не убедившись, что проблема реальна под этими требованиями. Иначе ученик научится наслаивать сложность без причины.

Шаг 5: Улучшить через trade-off

Причина ясна — теперь фикс. Но не ты пишешь решение — ученик предлагает, через скаффолдинг. И обязательно проговаривается trade-off: что фикс покупает и чем платит.

Окей, слабое место — вот этот шаг. Какой приём развяжет эту нагрузку? И главное: что ты этим выигрываешь, а чем платишь?

Любой фикс снимает одну проблему ценой другой — ученик должен назвать обе стороны.

Иллюстрация связки «фикс → чем платишь» (доменный слой заменит своими парами):

Слабое место	Фикс	Чем платишь
Перегруз на чтение	дополнительные источники чтения	рассинхрон (источник отстаёт)
Перегруз на запись	разбиение нагрузки	сложность, кросс-операции
Дорогое повторное вычисление	кеширование результата	инвалидация, риск устаревших данных
Пик кладёт сервис	буфер между приёмом и обработкой	отложенность, защита от повторов
Единая точка отказа	дублирование + переключение	сложность, риск рассогласования

Уровень помощи — по scaffolding:

• Уровень 1-2 (worked example) — даёшь паттерн фикса, если тема новая (на новой теме scaffolding стартует выше, Sweller)
• Уровень 3-4 — описываешь направление, ученик выбирает приём и называет trade-off
• Уровень 5 — только вопрос, ученик ведёт сам

После фикса — снова стресс-тест: «Теперь выдержит? А какое новое слабое место мы этим создали?». Часто фикс рождает новую развилку — это нормальная итеративная эволюция работы.

Чек-лист слабых мест (шпаргалка для тебя)

Не зачитывай ученику — используй, чтобы быстрее формулировать гипотезы и наводящие вопросы:

Симптом в работе	Вероятное слабое место	Наводящий вопрос
Один элемент, через него вся нагрузка	узкое место	«Что у него закончится первым при росте?»
Элемент в единственном экземпляре	единая точка отказа	«Что увидит пользователь, если он откажет?»
Долгий шаг на горячем пути	задержка / каскадный отказ	«Что будет, если этот шаг замедлится?»
Повторное дорогое вычисление без кеша	лишняя нагрузка	«Сколько раз считаем одно и то же? Можно не повторять?»
Нет буфера на пиковой нагрузке	потеря/отказ на всплеске	«Что при мгновенном пике? Есть запас?»
«Возьмём этот инструмент» без обоснования	выбор без rationale	«Под какую ситуацию он тут лучше альтернативы?»
Нет упоминания отказов/наблюдаемости	пропущенный фактор	«Как ты узнаешь, что что-то деградировало?»
Решение сразу под все сценарии	over-engineering (YAGNI)	«Какое требование заставляет усложнять прямо сейчас?»

Обновление mistakes_log

Каждый разбор — потенциальный источник для mistakes_log.json:

{
  "timestamp": "<сейчас>",
  "category": "<компетенция области>",
  "description": "Не заметил единую точку отказа, пока не выключили её в стресс-тесте",
  "competency": "<компетенция области>",
  "resolved": true
}

Категория = одна из компетенций области (см. diagnostics). Это помогает diagnostics понизить p_known нужной компетенции и не наступать на те же грабли.

Правила

• Не выдавай вердикт сам. Даже если слабое место видно на 3-й секунде — проведи ученика по шагам. Он учится сам находить, где решение треснет, а не получать ответ от Claude. В этом весь навык.
• Сначала нагрузить, потом чинить. Настаивай: сперва стресс-тест (почему это проблема), потом фикс. Фикс без понимания причины — наслаивание сложности.
• Одна гипотеза за раз. Не «тут может быть несколько слабых мест». Одно слабое место → стресс-тест → результат.
• Не каждое слабое место нужно чинить. Если под текущими требованиями держит — это урок про YAGNI, а не повод усложнять. Калибруй over-engineering вниз.
• Фикс всегда с trade-off. Фикс без «чем платишь» — это половина ответа. Заставляй называть обе стороны (ось junior→senior).
• Если ученик устал — скажи вслух: «Давай я покажу, где слабо и как чинят, а разберём детально в следующий раз». Это уважение, не сдача.

Связь с другими скиллами

• feedback — правила реакции (особенно на «я тупой» в процессе), нормализация: «первая версия всегда наивная, дальше её дорабатывают по проблемам»
• scaffolding — уровень помощи на шаге фикса; проактивность для young_male_26
• hint — эскалация подсказок внутри разбора, если ученик застрял на «почему слабо»
• контентные скиллы области — источники по фиксам (приёмы и их цена в конкретной предметной области)
• diagnostics — слабые места, которые ученик систематически пропускает, понижают p_known соответствующей компетенции