Неделя вайб-кодинга с Claude Code: GitOps-медиасервер на k3s с нуля

Этот термин заслужил немало закатывания глаз — в основном потому, что люди представляют себе, как кто-то набирает «сделай мне приложение» в чатбот и выкладывает всё, что вернулось. Если это ваше определение — ладно, отмахнитесь. Но не то делал я, и не это имеет в виду термин для тех, кто действительно пробовал строить что-то нетривиальное таким образом.

Небольшое замечание об инструментах: Claude Code — это не инструмент автодополнения в IDE. Это агентная (agentic) среда — у неё есть полный доступ к вашему репозиторию, она может выполнять команды в оболочке, читать и записывать файлы, и сохраняет контекст на протяжении всего проекта через интерфейс беседы. Если вы пользовались GitHub Copilot, вы знаете автодополнение, понимающее вашу кодовую базу. Claude Code — это другая категория: вы ведёте с ней архитектурный диалог, и она может действовать непосредственно в вашей кодовой базе. Потолок выше, и стоимость тоже выше — неделя интенсивных агентных сессий обходится в десятки долларов за использование API. Это стоит знать заранее.

То, что я практиковал, — итеративный, диалоговый рабочий процесс. Я определял намерение и архитектуру. Claude Code занималась деталями реализации, шаблонным кодом и когнитивной нагрузкой — держать в контексте конфигурацию десяти сервисов одновременно. Я проверял архитектурные решения и возражал, когда что-то было неправильным. Я не проверял каждую строку манифеста контроллера Sealed Secrets — для этого я доверял официальному релизу, — но каждое решение, определявшее, как система работает, было моим.

Ключевым механизмом стал файл CLAUDE.md — живой архитектурный документ, зафиксированный в репозитории, который Claude читает в начале каждой сессии. Думайте о нём как об общей памяти: документ, который ИИ читает перед каждым разговором, чтобы никогда не терять из виду то, что вы уже решили. Характеристики железа, схема хранения, топология сети и каждое проектное решение с обоснованием. Всякий раз, когда я возражал и мы приходили к лучшему варианту, этот ответ попадал в CLAUDE.md. К концу недели это было самое точное описание системы из всех существующих — лучше любой вики, потому что обновлялось в реальном времени по мере принятия решений.

Claude Code умеет моделировать сценарии отказа, рассуждать о том, что первым сломается на пустой системе, читать события подов (pod events) и диагностировать петлю перезапуска в полночь. Чего она не умеет — так это измерять ваше окружение, говорить вам, когда что-то кажется неправильным, или знать, что вам на самом деле важно. Это не живёт ни в какой модели. Это оставалось за мной.

Железо: Lenovo ThinkCentre, процессор Intel i5, 32 ГБ RAM, зашифрованный SSD на 1 ТБ, Intel UHD 630 для аппаратного транскодирования. Ubuntu 24.04 с полнодисковым LUKS-шифрованием и Dropbear SSH для удалённой разблокировки при загрузке.

Хранилище: мне нужно было, чтобы медиафайлы на локальном SSD и в облаке выглядели как единая библиотека. rclone обеспечивает подключение к облаку (iDrive E2); mergerfs объединяет локальный SSD и облачное монтирование в единый путь /data/media, который Plex читает, не зная и не заботясь о том, где физически находятся файлы. Кэш VFS ограничен 20 ГБ на локальном SSD, чтобы «горячий» контент оставался быстрым. Измеренный исходящий трафик из iDrive E2: ~2,1 МБ/с. Это число важно — я вернусь к нему.

Вычисления: k3s — лёгкий дистрибутив Kubernetes, подходящий для одноузловых установок. Десять медиасервисов, каждый с ограничениями ресурсов, настроенными под железо, и все три типа проб настроены (startup, liveness, readiness). k3s намеренно не является высокодоступным (high-availability); это одна машина, одна плоскость управления (control plane). Это компромисс, который я принял в обмен на простоту — и тот, от которого конвейер резервного копирования и восстановления спроектирован быстро оправляться, когда железо в конце концов выйдет из строя. Plex получает 4 ядра CPU и 8 ГБ RAM в качестве лимита. /dev/dri/renderD128 монтируется в контейнер для аппаратного транскодирования, LIBVA_DRIVER_NAME=iHD задаётся в окружении, чтобы драйвер iHD VA-API реально подхватывался.

GitOps: Argo CD v3.3.4 и Image Updater v0.15.1. Репозиторий — единственный источник истины. Image Updater опрашивает реестры, закрепляет новые дайджесты в kustomization.yaml каждого сервиса и автоматически коммитит в main. В моём git-логе есть записи вида build: automatic update of plex — это кластер сообщает мне о том, что изменил, а не я что-то делаю вручную. Для сольного проекта прямые коммиты в main вполне подходят. В командном контексте вы бы направляли их через pull-реквесты с гейтами одобрения — механизм тот же, слой управления (governance layer) располагается поверх.

Наблюдаемость (Observability): Dynatrace Kubernetes Operator v1.8.1 в режиме cloudNativeFullStack (DaemonSet OneAgent на узле), OTel Collector, собирающий данные с Prometheus-эндпоинта /metrics rclone и экспортера speedtest, DaemonSet logMonitoring для логов подов. Ежедневные резервные копии отправляются на отдельную машину в домашней сети через rclone; скрипт резервного копирования также выполняет обнаружение дрейфа конфигурации (config drift detection) и передаёт предупреждения в Dynatrace. Тестовое восстановление (restore dry-run) автоматически запускается 1-го числа каждого месяца в 04:00.

Хочу быть прямолинейным в этом вопросе, потому что большинство рассуждений в духе «ИИ не заменит инженеров» — либо расплывчатое успокоение, либо защитный перебор. Вот что я реально встретил.

ИИ не может измерить ваше окружение. Он не знает, что ваш облачный провайдер выдаёт исходящий трафик 2,1 МБ/с вместо 150 Мбит/с. Он не знает задержку вашего диска или топологию вашей сети. Конфигурация, которую он генерирует, структурно корректна — калибровать её к вашей реальности — ваша задача.

ИИ не знает, когда что-то кажется неправильным. 61 секунда — это число. «Это неприемлемо» — это суждение. Этот разрыв — инженерный опыт, и никакая модель его не заполняет.

ИИ не может отлаживать то, что не задокументировано — и не всегда говорит вам, когда застрял. Claude сожгла целое контекстное окно на проблеме logMonitoring, итерируя по манифестам для архитектурной комбинации, которая никогда не тестировалась. Она продолжала пробовать, потому что именно это она и делает. У неё не было способа узнать, что проблема не в манифестах. Именно я должен был заметить, что мы ходим по кругу, и остановиться. Умение распознать, когда нужно остановиться и эскалировать — по-прежнему человеческое суждение.

У ИИ нет архитектурного вкуса. ConfigMap против Secret против переменной окружения. Где живёт конфигурация. Как называются вещи. Эти решения кажутся мелкими и плохо накапливаются. Принять их правильно требует суждения, которое формируется за годы обслуживания систем, а не из чтения спецификаций.

ИИ не может знать, чего вы на самом деле хотите. «Настрой наблюдаемость» охватывает очень много. То, что Dynatrace-native был правильным ответом в моём случае — потому что я там работаю и знаю архитектуру — было информацией, которой только я располагал. ИИ выполнял намерение, которое я ему дал. Намерение было моим.

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

Он сжимает кривые обучения так, как не делает ничто другое. От нулевого практического опыта в Kubernetes до понимания наложений (overlays) kustomize, Sealed Secrets, git write-back Image Updater, сетевых служб k3s и привязки PersistentVolume — за одну неделю. Не через чтение документации, а через построение чего-то реального и вопрос «почему» на каждом шаге с немедленными ответами, точно соответствующими тому, что именно вы строите. Петля обратной связи тесная, потому что контекст специфичен для вашего проекта.

Он рассуждает о режимах отказа, для тестирования которых у вас нет живого окружения. Ежемесячный тестовый прогон восстановления — restore.sh --dry-run, 1-е число каждого месяца в 04:00 — был спроектирован целиком через рассуждение о том, что первым сломается на пустой системе. Никакой пустой системы не потребовалось. Claude проработала порядок зависимостей, сценарии частичного восстановления, как выглядит сломанная резервная копия. Дизайн появился из разговора. Этот тестовый прогон уже поймал сломанный путь резервной копии Bazarr, который я изменил, не обновив скрипт, — тихо, в 4 утра, зафиксировав в Dynatrace ещё до того, как я выпил свой утренний кофе. В этом суть построения надёжности с ИИ: вы не просто устраняете сегодняшние проблемы — вы рассуждаете о тех, на которые ещё не наткнулись.

Он удерживает контекст, который перегрузил бы одну рабочую сессию. CLAUDE.md становится памятью проекта. Каждое решение задокументировано, каждый компромисс записан. После дня отсутствия мне не нужно было восстанавливать состояние — всё было там. Проект длиной в неделю, который обычно живёт в голове одного человека, получил письменную запись каждого значимого выбора.

И да — отладчик в полночь. Поды перезапускаются в петле в 23:00, инструмент умеет читать манифест, читать события пода, точно объяснить, почему /ping возвращает 401 с включённой аутентификацией, и передать вам исправление. Альтернатива — вы, Stack Overflow и постепенно нарастающее осознание того, что придётся не спать ещё долго.

Если вы инженер в компании, которая спустила сверху директиву «AI-first», вы наверняка заметили, что директива не поставляется с определением. И негласный подтекст — иногда высказываемый прямо — в том, что человеческое суждение является узким местом, которое нужно устранить.

Это в корне неверно.

Правильный фрейм проще: ИИ убирает трение между тем, что вы понимаете, и тем, что вы можете построить.

Я понимал Kubernetes концептуально. Я понимал свои ограничения по хранилищу. Я знал, каково это — 61 секунда. Я знал архитектуру Dynatrace, потому что там работаю, и именно это знание в конечном счёте разблокировало конфликт с Operator. Чего у меня не было — синтаксис, шаблонный код, мышечная память с kubectl, способность держать десять сервисов в рабочей памяти при конфигурировании следующего.

ИИ дал мне всё это. Моё суждение дало ему направление.

Инженеры, которые извлекут из этих инструментов максимум, — не те, кто всё передаёт и принимает то, что возвращается. Это те, кто вовлекается критически, привносит то, что знает, в разговор, ставит под сомнение инструмент, когда что-то не сходится, и знает, когда проблема требует человека-эксперта. История с Dynatrace Operator тому доказательство: ИИ был полезен почти для всего в этом проекте, и была ровно одна проблема, которую он не мог решить. Умение видеть это различие — и взять трубку — по-прежнему инженерный навык.

Медиасервер работает. Каждое обновление образа — это git-коммит. Каждая резервная копия ежемесячно проверяется тестовым прогоном, который выполняется без моего участия. Dynatrace видит полную картину. Неделя вечеров, один потребительский ПК, человек, который никогда не писал манифест Kubernetes.

А ловушка хрупкости? Исчезла. Система больше не держится на памяти и мышечной памяти. Она задокументирована, автоматизирована и воспроизводима — файл CLAUDE.md точнее любого runbook, который я когда-либо писал, потому что обновлялся в реальном времени по мере принятия каждого решения. Отказ железа теперь — упражнение по восстановлению, а не перестройка с нуля.

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

Это не ИИ, заменяющий инжиниринг. Это то, что происходит, когда трение исчезает.