Workflow для Claude Code недолговечны — и это нормально

Это неделя, которая словами одного разработчика описывается просто: построил идеальный workflow для Claude Code, рассказал о нём в твите — и в четверг вышла новая модель, которая этот workflow сломала. Для сообщества Claude Code это не жалоба, а констатация ритма, в котором живёт вся индустрия AI-ассистированной разработки.

Workflow для Claude Code как расходный материал

Пост @adocomplete зашёл в комьюнити не как шутка про усталость, а как диагноз: каждый цикл обновлений модели — Sonnet, затем Opus, затем их следующие версии — заставляет пересматривать то, что казалось устоявшейся практикой. Подсказки, которые работали идеально под одну модель, на следующей версии ведут себя иначе: кто-то вдруг слишком дословно выполняет инструкции, кто-то — слишком творчески интерпретирует задачу. Кастомные subagents, цепочки MCP-интеграций, выверенные системные промпты — всё это держится на характере конкретной модели, а характер меняется с каждым релизом.

Отсюда и совет, который разошёлся по цитатам: держать фундаментальные принципы крепко, а конкретные решения — свободно. Фундамент — это понимание, какую задачу решает агент, где граница ответственности человека и модели, как устроена проверка результата. А конкретный workflow для Claude Code — промпты, набор инструментов, структура файлов конфигурации — это расходный материал, который нормально выбрасывать и пересобирать раз в несколько месяцев.

Другая сторона обновлений: что стало возможно с Opus 5.5

Контраст этой усталости от пересборки — ретвит из аккаунта @claudeai с подборкой проектов, сделанных на новой модели. Среди примеров — работающая водяная мельница, построенная на Opus 5.5: не рисунок и не симуляция, а физический механизм, спроектированный и собранный с помощью модели. Это ровно тот случай, когда новая версия не ломает старый workflow, а открывает класс задач, которые раньше были недоступны — не потому что не хватало фантазии, а потому что модель не справлялась с инженерными расчётами и итеративной отладкой в физическом мире.

Для тех, кто следит за обновлениями моделей Claude не из профессионального интереса, а из любопытства, такие примеры — куда понятнее бенчмарков. Процент прохождения тестов на кодирование мало что говорит человеку, который не пишет код каждый день, а работающая мельница — наглядное доказательство роста возможностей.

Что с этим делать разработчику

Практический вывод из обеих новостей один: не стоит инвестировать в автоматизацию с Claude Code так, будто она переживёт модель, под которую написана. Разумнее закладывать в пайплайн явные точки проверки и быстрой переналадки — отдельные файлы с промптами, а не промпты, вшитые в код; логирование решений модели, чтобы быстро увидеть, где новая версия начала вести себя иначе; и привычку к короткому циклу ревизии, а не к одной «финальной» архитектуре.

При этом не нужно шарахаться от обновлений — именно они дают прирост возможностей, который превращает нишевые эксперименты (вроде физических конструкций) в рабочий инструмент. Вопрос не в том, обновлять или не обновлять workflow для Claude Code, а в том, как сделать так, чтобы пересборка занимала час, а не неделю.

Вывод

Два твита одной недели — это, по сути, две стороны одного процесса. Workflow для Claude Code живёт ровно до следующего значимого релиза модели, и это нормально: смысл не в том, чтобы построить вечную систему, а в том, чтобы быстро перестраивать её вокруг неизменных принципов — чёткой постановки задачи, проверяемости результата и границы ответственности между человеком и моделью.