Лео Годин в своей заметке Claude Code is Great формулирует мысль, которую я повторяю себе и коллегам не меньше раза в неделю: using LLMs effectively is a skill we all need in 2026
. С этим я согласен полностью — и при этом считаю, что бóльшая часть споров вокруг LLM застревает именно потому, что люди обсуждают модели, а не свой собственный навык работы с ними. Я провёл с Claude Code последние полтора года в роли DevOps-инженера, и хочу пройтись по нескольким его тезисам — где соглашаюсь, где добавил бы свой опыт, а где осторожно спорю.
Контекст — единственный важный навык
Годин называет это «зоной Голдилокс»: не слишком много, не слишком мало, ровно столько, сколько нужно. У меня тот же опыт. На практике у меня сформировалось разделение: глобальные правила живут в CLAUDE.md и грузятся каждую сессию, а извлекаемая память — в отдельной системе с индексом, который подтягивается по релевантности. Между ними жёсткая граница: если правило универсальное — оно в CLAUDE.md; если оно специфично для проекта или темы — это память. Дубли запрещены, потому что они расходятся.
Почему это работает: модель не помнит то, что ей не дали в контекст. Любая попытка «положить всё на всякий случай» оборачивается тем, что Claude теряет нить уже на пятом-шестом шаге. У Година есть на это хорошая метафора: тридцать минут разговора про кофе и сыр перед вопросом про Krokus — и собеседник, конечно, не вспомнит, какой кавер ты имеешь в виду. С LLM ровно то же.
Context management is the difference between success and failure.
Подпишусь. Я бы только уточнил: дисциплина с контекстом — это не разовое усилие, а постоянная гигиена. Раз в неделю я прохожу по своим CLAUDE.md и индексу памяти и выкидываю всё, что устарело. Без этой рутины любая разумная система за месяц превращается в кладбище правил, которые модель честно прочитает и так же честно применит — невпопад.
Оркестратор должен быть слепым
Самый прикладной кусок статьи — про то, что your job is orchestration, not comprehension
. У Година это правило в скилле implement-sprint, у меня — в командах агентов: ведущий агент знает только текущий шаг и не имеет права читать архитектурные документы. За это отвечают исполнители-субагенты с собственным контекстным окном.
Эта картина устроена нелогично с человеческой точки зрения. Хороший тимлид как раз держит в голове весь контекст. Но LLM-оркестратор не человек: он деградирует тем быстрее, чем шире его кругозор. Я наступил на это самостоятельно, ещё до того как прочитал Година — у меня power-plan и self-improve уходили в бесконечный обход проекта, пока я не вынес «прочитать только эти два файла» в явное правило. Эффект совпал с тем, что описывает он: автономное завершение задачи вместо вечной потери темы.
«Виновны процессы, не люди и не LLM»
Годин предлагает приём: когда Claude после провала уходит в самобичевание, переключить его фразой I believe in blaming processes not people or LLMs
. Я попробовал — и подтверждаю, работает. Дело не в магии конкретных слов. Дело в том, что вы перенаправляете внимание модели с что я сделал не так на что в процессе позволило этому произойти. Это два разных режима рассуждений, и второй гораздо продуктивнее.
От себя добавлю смежный приём: когда сессия сорвалась, я прошу Claude проанализировать собственный лог — что именно произошло, какие именно решения привели к тупику. Дальше из этого анализа рождается правка процесса: новое правило в CLAUDE.md, новая ветка скилла, новый чек-лист. Без такого цикла улучшения не накапливаются. Без него фраза «LLM поглупели» — это не диагноз модели, а диагноз отсутствующей инженерной практики.
Фреймворк или своя сборка
Годин признаётся: пробовал Spec Kitty, BMAD, Open Spec — в итоге пользуется собственной сборкой. Я тоже. И здесь интересен не результат, а аргументация: внешний фреймворк decreases your learning
. Это редкая, но честная позиция. Готовая обёртка ускоряет первые пять задач и замедляет рост в следующих пятидесяти — вы не понимаете, почему она работает, и в момент, когда она ломается (новая модель, новый релиз Claude Code, изменение бэкенда), у вас нет инструмента отремонтировать её.
Я бы только добавил оговорку: писать с нуля имеет смысл, если вы каждый день работаете с инструментом. Для разового скрипта или хоум-проекта возьмите готовое. Для постоянной работы — соберите свою лёгкую обвязку и эволюционируйте её. Мои /power-plan, /self-improve, /publish-note — именно такая обвязка, которая выросла из конкретных регулярных болей.
Что я бы оспорил
Годин пишет: /clear is your friend. /compact is not
. Согласен по сути, но добавлю нюанс. /compact не зло — это инструмент с очень узким применением. Если вы поймали сессию до деградации (а не когда модель уже путается), компакция работает: сохраняет нить и даёт продолжить. Проблема не в команде, а в том, что её обычно вызывают слишком поздно. Это типичная ошибка человеческого восприятия: мы замечаем, что контекст переполнен, только когда модель уже сбилась — а к этому моменту сжимать уже нечего.
Главный вывод
Хорошая статья. Не про инструмент — про навык. И в этом её основная ценность: она лечит фрустрацию через ответственность. Если у вас сегодня не работает — значит, у вас сегодня неправильный процесс. Это неприятная новость и одновременно очень хорошая: процесс можно починить, навык можно прокачать, контекст можно подрезать. А ждать, пока Anthropic «вернёт нормальный Claude», бесполезно — он никуда не уходил.
В оригинале статья короче моего разбора и читается легко: Claude Code is Great. Рекомендую.