Comments 27
Благодарю за шаблоны, как раз сегодня начал разбираться с cli-инструменами.
При таком воркфлоу удаётся делать самостоятельное ревью каждой строки сгенерированного кода? И насколько это целесообразно? Или вы управляете качеством кода только через агентов, не заглядывая в код?
Хороший вопрос. Нет, каждую строку я не просматриваю — это убило бы весь смысл автоматизации.
Мой подход трёхуровневый:
Автоматический уровень — хуки и тесты. Если тесты проходят и code-reviewer агент не нашёл критических проблем — код скорее всего рабочий. Это фильтрует примерно 80% потенциальных багов без моего участия.
Выборочный ручной ревью — я смотрю diff перед коммитом (git diff), но не построчно, а на уровне «что изменилось, в каких файлах, соответствует ли это плану». Если вижу что Claude тронул файл, который не должен был трогать — откатываю. Это занимает пару минут.
Глубокий ревью — только для критичных мест: авторизация, работа с деньгами, миграции БД. Тут да, читаю каждую строку. Но таких изменений — 5-10% от общего объёма.
На практике: чем лучше написан CLAUDE.md и чем точнее план от planner-агента — тем меньше сюрпризов в коде и тем меньше нужно ручного ревью. Основные проблемы возникают не от плохого кода, а от того что Claude делает не то что нужно — удаляет тесты, рефакторит то, о чём не просили. CRITICAL RULES в CLAUDE.md решают именно это.
globs: ["**/*.py"]
Python Backend Rules
...
Интересно. Не в курсе - это грузится для каждого файла каждый раз или тоже подвержено компрессии?
Rules-файлы из .claude/rules/ ведут себя так же как CLAUDE.md — переживают compaction. После /compact Claude перечитывает их с диска заново.
Но есть нюанс с загрузкой. Они грузятся не «для каждого файла каждый раз», а по другой логике:
Файлы без globs (просто .md в .claude/rules/) загружаются в контекст при старте каждой сессии, как и CLAUDE.md.
Файлы с globs загружаются когда Claude начинает работать с файлами, соответствующими маске. То есть globs: ["**/*.py"] подтянется когда Claude откроет или отредактирует .py-файл, а не раньше.
В этом и смысл разделения: правила для Python не занимают контекст пока вы работаете с фронтендом, и наоборот. С 1M окном Opus 4.6 это менее критично, но при работе с Sonnet (200K) — ощутимая экономия.
Источник: официальная документация https://code.claude.com/docs/en/memory
То есть globs: ["**/*.py"] подтянется когда Claude откроет или отредактирует .py-файл, а не раньше.
Это понятно. Но вот перешли к другому .py-файлу, что происходит? Правило опять перечитывается?
Нет, правило не перечитывается при каждом переходе между .py-файлами. Оно загружается в контекст один раз — когда Claude впервые касается файла, подходящего под маску. После этого правило остаётся в контексте до конца сессии или до compaction. При compaction — перечитывается с диска заново, как и CLAUDE.md. То есть цикл такой: первый .py-файл в сессии — правило загрузилось — работаете с любыми .py — правило в контексте — compaction — правило перечитано — работаете дальше
Смотрю на это все, и накатывает тоска. Во что превращается любимая профессия. Если выбора не останется, то придется сменить род деятельности. Заниматься вот таким др***ом нет никакого желания.
Я, наверное, не тот автор от которого ожидается эмпатия к этой позиции — потому что я сам пришёл в программирование чуть больше пары лет назад и почти сразу с нейросетями. До этого 13 лет работал геологом (и сейчас продолжаю ездить в экспедиции). Код руками в классическом понимании не писал — начинал с сайтов на конструкторах, далее в low-code с написания кастомных функций в FlutterFlow и Google Cloud Functions, и почти с первого дня использовал AI как основной инструмент.
И знаете что — за этот год я отшипил больше продуктов чем многие «классические» разработчики за пять. Не потому что я умнее, а потому что инструменты позволяют.
Нейросети не отбирают работу у программистов. Они отбирают работу у тех, кто решил что учиться больше не нужно. IT-отрасль растёт в геометрической прогрессии — работы становится больше, а не меньше. Просто она другая. Кто адаптируется — тот в порядке. Это обычная эволюция, ничего нового.
Я согласен с вами почти во всем. Вот только описанный в статье процесс очень далек от программирования в классическом его понимании.
Работу у программиста все же отбирают. На его место придет оператор БЯМ. Это сейчас еще переходный период, но чем дальше, тем заметнее будет разница между этими двумя профессиями.
Попробую привести аналогию. Вы - страстный автолюбитель. Обожаете крутить баранку. Переключать скорость. Чувствовать руками весь процесс.
В один момент к вам приходят и говорят, что теперь вы будете ездить на заднем сидении, а повезет вас автопилот. Но расслабиться вы не можете, нужно постоянно контролировать автопилота, так как он в любой момент может намотать вас на столб. Будьте готовы вмешаться в любую секунду. В этот момент любимый процесс(вождение) превращается в ад(оператор автопилота).
Примерно такие у меня ощущения происходящего, моя персональная боль, и я прекрасно понимаю, что полно людей, которым эти изменения в кайф, которые с радостью пересядут на заднее сиденье.
Я бы привел такую аналогию:
- Разработчик - пешком
- Фреймворк - лошадь
- "ИИ" - снегоход.
У человека и лошади есть мозг, у снегохода нет, хотя по скорости он уделает обоих.
Про "продукты" за месяц - это самообман. Тонны нейрослопа - не продукт...
Вот только описанный в статье процесс очень далек от программирования в классическом его понимании.
Любопытно. А можно подробнее про "классическое понимание"? Вот есть, например, Guide to the Software Engineering Body of Knowledge
Содержание
Software requirements
Software architecture
Software design
Software construction
Software testing
Software engineering operations
Software maintenance
Software configuration management
Software engineering management
Software engineering process
Software engineering models and methods
Software quality
Software security
Software engineering professional practice
Software engineering economics
Computing foundations
Mathematical foundations
Engineering foundations
В каждой из этих областей Агенты работают как усилитель. Усиливается, в том числе, и глупость (например, по незнанию). Более близкая мне аналогия - экзоскелет. Если не знаешь, как грамотно колоть дрова - наломаешь дров, на все деньги. А если знаешь - будет быстрее, чем руками топором махать.
Вероятно это нормальный процесс.
Когда появились языки высокого уровня, то количество специалистов умеющих писать в машинных кодах и очень хорошо знающих железо конечно сократились, но они никуда не делись. Зато рядом с ними появились новые специалисты, не хуже, но которые не знают особенности работы с машинными кодами.
Хуже ли они предыдущих?
Кажется нет, но они сосредоточились на других более высокоуровневых задачах.
С внедрением новых подходов разработки (даже таких спорных как LLM) порог входа в программирование естественно снижается. В случае нейросетей так сильно, что кажется позволяет программировать даже обезьянам. В то же время у хороших специалистов освобождается ресурс на погружение и расширение предметной области решаемой задачи, интеграцию её в реальный мир и прочие не менее важные задачи, чем просто написание качественного кода.
Ну а плохой разработчик - он всегда плохо напишет, это не зависит от инструмента.
Полагаться на опыт нейросети тут не получится. Нейросети, даже самые лучшие, это всё ещё большой семантический T9, который не очень понимает что пишет, хотя и очень старается связать контекст из скормленных ему на стадии обучения данных. Из-за этой особенности на выходе периодически случайно нейросеть будет совершать крайне глупые ошибки, потому что датасеты никогда не будут бесконечно точные. Чем больше задач и дольше производится работа, тем накопленных ошибок будет больше. Учитывая что каждая ошибка это точка отказа - накопление ошибок приведет к очень быстрой деградации проекта, если не успевать их отлавливать. Для этого нужно уметь читать код, в том числе в разрезе архитектуры. К сожалению с вайб-кодерами тут часто как в анекдоте: чукча не читатель, чукча писатель.
Если же рассуждать о опытных разработчиках, то нам сейчас никто не мешает изучить нейросети и взять этот инструмент себе на вооружение, сохраняя понимание что ответственность за качество решений всё ещё лежит на людях.
И знаете что — за этот год я отшипил больше продуктов чем многие «классические» разработчики за пять.
Это что за продукты такие которые за несколько месяцев можно "отпшпилить", если не секрет?
есть уже очень похожая статья, по сути что та, что эта - перепечатка мануалов по Клоду
- https://habr.com/ru/articles/1012412/
вы бы лучше промптами поделились. Промпты - это source code нового эпохи, искусство чистого промпта - новые принципы на смену "чистому коду"
спасибо, что вы описали мануал по Клоду, но все что вы описали - второстепенно и к тому же зависит от одной систему
Прежде всего рулят промпты и техники соединения их. Промпт имеет приоритет над любым AGENTS и CLAUDE.md, над любыми скиллами и MCP. Вот где самое интересное
О, Господи... Донни - жги!
Вы правы что промпты — фундамент. Но давайте уточним что такое «промпт» в контексте реальной работы.
Промпт с которым я прихожу в IDE начинать проект — это не раскрученное полотно на тему «хочу приложение как у тех только лучше». Это результат часто нескольких предварительных исследований, систематизации данных, продуманного инженерного архитектурирования. Он содержит ссылки на дополнительные файлы и документы, прикреплённые к проекту — спецификации, результаты ресёрча, архитектурные решения. Каждый такой вводный промпт индивидуален и создаётся отдельно от IDE.
Так вот — claude.md, agents и rules это и есть промпты, только персистентные. claude.md — системный промпт который не нужно повторять каждую сессию. Agent — промпт с изолированным контекстом. Rule — промпт с условием загрузки. Разница между «хорошим промптом в чате» и «промптом в claude.md» в том, что первый исчезнет после compaction, а второй переживёт. На длинных сессиях это критично.
Насчёт «перепечатки мануалов» — мануалы описывают что существует, статья описывает что из этого реально работает вместе и как это собрать в рабочий пайплайн. Это разные задачи.
про хуки хорошо но мало, особено от питон разработчика.
Согласен, хуки заслуживают отдельной статьи. Здесь показал только два базовых, но возможностей больше: PreToolUse для валидации перед любым действием, PostToolUse для автоформатирования, SessionStart для загрузки контекста из внешних источников, TaskCompleted для проверки что задача действительно завершена. Если будет интерес — распишу подробнее в одном из следующих материалов.
я думаю будет полезно если есть опыт. я не разработчик, но прописал в хуки "железные" правила которые ограничивают модель. Перехватывает каждое действие claude перед выполнением и блокирует нарушения правил из CLAUDE.md: запись в запрещеные каталоги, удаление файлов, em dashes в тексте, фейковые credentials. По сути механический enforcement того что модель может "забыть" или проигнорировать из instructions.
Спасибо за статью. Полезный материал.
Я еще прописываю что бы он фиксировал принятые решения и внесенные изменения в RELEASE.md
Отличная практика с release.md — по сути автоматический changelog который ведёт сам агент. Я использую похожий подход через planner-агента с сохранением планов в /plans/, но фиксировать принятые решения и внесённые изменения в отдельный файл — забираю к себе в сетап. Спасибо) 👍
Спасибо за статью.
До Claude пока ещё не добрался, но на Cursor хотелось бы видеть аналогичный подход. Может со временем он появится)
Спасибо вам за интерес! В Cursor часть из этого уже работает — .cursorrules выполняет роль claude.md, а агентный режим поддерживает похожие паттерны. Принципы те же: персистентные правила, план перед кодом, тесты после каждого шага. Инструмент другой — подход универсальный.
Спасибо за статью, очень полезный и своевременный материал.
Автор писши "исчо"! ;)
Спасибо за поддержку! Не остановлюсь — уже опубликовал вторую статью про statusline для Claude Code с мониторингом VPS, и дальше планирую продолжать делиться тем что реально работает в ежедневной практике. К примеру - вчера пока занимался одной задачей, параллельно собрал мощный workflow toolkit для работы с NotebookLM. По принципу - чувствуем где у самого провисание, ресерчим лучшие практики, берем работающий надежный инструмент, и добавляем к нему то что реально улучшит и ускорит работу. Об этом тоже расскажу в ближайших публикациях.
Как я перестал бояться Claude Code и научил его не ломать мои проекты