Моя жена хотела Dior. Я потратил $600 на Claude Code, чтобы вместо этого вайб-кодить базу данных на 2 млн строк.
Мы с женой женаты уже десять лет, и на годовщину она хотела сумку Dior.
Вместо того чтобы что-то купить — потому что я был полностью поглощен экспериментом с ИИ — я провел весь праздник, запершись в кабинете, жонглируя тремя подписками Claude Code по $200 в месяц и пытаясь убедить LLM кросс-компилировать распределенную базу данных на C++ из 2 миллионов строк.
И вы, наверное, догадываетесь, что случилось со мной потом. 😂
Оглядываясь назад, это было не оптимальное распределение ресурсов.
Так что в те выходные я усвоил два урока.
Первый: слушайте свою жену. «Счастливая жена — счастливая жизнь» — это не просто слоган. Это принцип стабильности систем.
Второй: ИИ кажется волшебным на небольших, хорошо ограниченных задачах. Он ведет себя совсем иначе, когда вы направляете его на реальную распределенную инфраструктуру.
Этот пост — о втором уроке.
Предыстория
Я мейнтейнер и один из основных контрибьюторов Milvus, самой популярной open-source векторной базы данных с 42K+ звездами на GitHub на момент написания (~2 млн строк на C++, Go и Python). Система полностью распределенная: proxy-узлы, query-узлы, data-узлы и index-узлы координируются через очереди сообщений. Моя область — слой хранения и индексации.
Я пользовался Claude Code несколько месяцев и был искренне впечатлен. Он дописал все недостающие функции целого CLI за $20 в токенах. Он за день в 5 раз ускорил критический участок производительности запроса — такую оптимизацию, на которую мне понадобилась бы неделя, чтобы хотя бы достаточно хорошо понять код и рискнуть его трогать. Это ощущалось как наличие компетентного junior-инженера, который никогда не спит и не выставляет почасовые счета.
Я решил дать ему настоящую задачу: кроссплатформенную компиляцию.
Урок за $600
Годами никто в команде Milvus не хотел трогать кроссплатформенную компиляцию. Система сборки — это смесь Go, C++ и Rust, скрепленная накопившимися за годы патчами Conan и CMake, к которым никто не хотел возвращаться. Заставить ее работать на Linux уже мучительно. Windows и современная macOS были настолько кошмарны для сборки, что команда относилась к ним как к чужой проблеме.
Я решил, что теперь у меня есть Claude Code. Я справлюсь.
Поначалу казалось, что я прав. Windows скомпилировался, и я отправил патч, думая, что самое сложное позади.
Потом упал Linux. Я починил Linux — упал Mac. Я починил Mac, и упало GPU-окружение. Каждое исправление порождало две новые проблемы на другой платформе, и патчи начали наслаиваться. В итоге у меня был патч на 1000 файлов и ~100 тыс. строк, затрагивающий конфиги Conan, скрипты CMake, C++-шимы совместимости и вещи, которые я не узнавал.
Бесило не наличие багов, а сам цикл. Я продолжал говорить Claude: «Никаких хакерских фиксов», «дай мне чистое решение». Он каждый раз послушно выдавал патчи, которые выглядели чище. Затем каждый чистый патч ломал три другие платформы, и цикл начинался заново. Если бы вы посмотрели в мой .claude/settings.local.json, вы бы нашли 147 вручную одобренных правил доступа. Каждое из них — временная метка момента, когда я думал: «На этот раз сработает».
Я потратил $600 на тариф Max и сжег весь отпуск, а все, что у меня осталось, — это куча команд git reset --hard.
Я сидел и смотрел в терминал, задаваясь вопросом, не является ли все это просто хорошо упакованным хайпом. Потом я понял: проблема была не в Claude. Это было похоже на то, как сказать аспиранту опубликовать статью в Nature, не сформулировав исследовательский вопрос. Я дал ему проблему, так и не определив, что на самом деле означает «решена».
Что на самом деле работает
Провал был не в интеллекте Claude. Это был провал процесса. Поэтому я начал заново — уже с другим процессом.
Ограничения перед кодом. Не «сделать так, чтобы компилировалось на Windows». Настоящие ограничения, явно записанные: все платформы проходят свои unit-тесты, CI везде зелёный, никаких #ifdef-хаков под платформы, никаких обходных shim-слоёв вокруг сломанных зависимостей. Это самая сложная часть — она требует понимания, как выглядит «готово», а для этого нужно внимательно подумать, прежде чем что-либо трогать. В сложной инфраструктуре большая часть работы — это думать.
Ревьюить тесты, а не код. Я пишу тест-кейсы (или прошу Claude сгенерировать их), но ревьюю тесты, а не реализацию. Проверяет ли этот тест, что Conan recipe корректно резолвится на ARM? Покрывает ли он конфигурацию CMake в Docker? Я могу оценить это за минуты. Я не могу с какой-либо уверенностью отревьюить 10 000 строк кроссплатформенных C++-патчей за какое бы то ни было время.
Снизу вверх, по одному слою за раз. Не позволяйте Claude менять 1000 файлов. Сначала зафиксируйте версии зависимостей. Когда эти ограничения проверены, поднимайтесь к конфигурации CMake. Когда она стабильна — к платформенно-специфичному коду. Каждый слой достаточно мал, чтобы его можно было полностью проверить перед переходом выше.
Я переделал кроссплатформенную сборку с нуля, используя этот подход. Два дня. Несколько десятков коммитов. Каждый маленький, каждый с соответствующим тестом. Никаких #ifdef-хаков — настоящим исправлением стало обновление Conan recipes и повышение версий сторонних библиотек, то есть исправление реальной цепочки зависимостей, а не замазывание проблемы.
Та же задача. Совершенно другой результат.
Инсайт про тесты заслуживает отдельного пункта: в распределённой системе со зрелым набором тестов тесты и есть спецификация. Если эти integration tests проходят — все 47, которые стали красными во время моей первой попытки, — значит, контракты seal/flush не нарушены, WAL replay корректен, а query nodes по-прежнему могут mmap-load-сегменты без повреждений. Мне не нужно читать C++, чтобы это знать.
Я перестал ревьюить код. Я начал ревьюить тесты. Код стал деталью реализации.
Бросить на это железо
Когда рабочий процесс стал правильным, появился новый bottleneck: я сидел и ждал.
Один сеанс Claude Code, пережёвывающий кодовую базу на 2 млн строк, — это не быстро. Каждая задача занимает 20–30 минут wall-clock time. Bottleneck был не в интеллекте. Он был в throughput.
Поэтому я сказал жене, что мне нужен сервер с GPU для моих «AI agents». Этот разговор прошёл примерно так, как вы и ожидаете. Я всё равно купил его — плюс Mac Mini в пару к моему MacBook. В итоге у меня было три машины и шесть терминалов, в каждом из которых работал независимый сеанс Claude Code.
Это работает благодаря git worktree. Каждый сеанс получает свою задачу, ветку и рабочую директорию, полностью изолированную от остальных. А поскольку подход «сначала ограничения» означает, что у каждой ветки есть свои acceptance criteria, параллелизм становится тривиально безопасным: если тесты каждой ветки проходят независимо, merge несёт низкий риск.
Для кроссплатформенной сборки это означало, что один сеанс резолвит Linux ARM Conan dependencies, другой чинит конфигурацию CMake для macOS, а третий занимается совместимостью Windows MSVC, и всё это выполняется одновременно без взаимных помех. То, что раньше было последовательным переключением контекста между платформами, стало параллельным выполнением на разных машинах.
Этот паттерн обобщается на повседневную работу. В любой конкретный день один сеанс рефакторит compaction scheduler, другой оптимизирует HNSW search path, а третий пишет integration tests для edge case в streaming insert. Я переключаюсь между терминалами как менеджер, проверяющий подчинённых, только этим подчинённым никогда не нужны перерывы на кофе и у них нет мнений о sprint planning.
Главный урок в том, что vibe coding инфраструктуры упирается в вычисления, а не в талант. Ограничивающий фактор — не то, насколько умён AI; а то, сколько экземпляров вы можете запускать параллельно. Anthropic использовала 16 параллельных экземпляров Claude для создания целого компилятора C, из-за чего мои шесть терминалов кажутся скромными.
То, к чему я постоянно возвращаюсь
AI решает ровно ту проблему, которую вы перед ним ставите, и ничего больше. Если вы неправильно формулируете проблему, вы получаете идеальное решение не той задачи.
"Compiles on macOS 15" — решено за час. Но это локальный оптимум. Настоящая цель была "compiles everywhere without hacks." Это разные задачи. У AI не было никакого способа это понять. Это целиком ответственность инженера.
Создавать что-то для себя с помощью AI поразительно легко — вы знаете свою машину, свои пограничные случаи, и "works for me" — достижимая цель оптимизации. Создавать инфраструктуру, которая работает для каждого пользователя, на каждой платформе, в каждом окружении, — принципиально другое дело. Именно в этом разрыве всё еще живет инженерия. Для инфраструктурного ПО этот разрыв огромен.
Самые сложные баги в нашей production-системе — те, из-за которых приходилось откатываться после merge, — не были пойманы ни одним подходом к AI code review, который мы пробовали. Баги были синтаксически корректными. Проблема была в неявных предположениях разработчика, невидимых в diff и отсутствующих в окружающем коде. Поведение системы имело смысл только если держать в голове ментальную модель того, как три разных компонента должны координироваться, — модель, которая существовала только в голове одного разработчика и нигде не была записана.
Для этого всё еще нужен человек, который понимает систему достаточно хорошо, чтобы знать, какие вопросы задавать.
Три плана по $200 и один потерянный отпуск оказались лучшей инвестицией, которую я сделал. Не потому, что они научили меня пользоваться AI. А потому, что они научили меня, как не надо им пользоваться.
Инструменты действительно хороши. Недостающим звеном всегда был workflow вокруг них. Тесты до кода, ограничения до тестов и достаточно железа, чтобы запускать всё это параллельно. Вот и всё.
Проблемы, которые остаются нерешенными
После всего — провалившегося патча, команд reset, шести параллельных терминалов — самой сложной проблемой по-прежнему остается человеческая.
Сейчас у меня две головные боли, и ни для одной из них нет чистого решения.
Первая: моя жена. Она приехала в отпуск с разумными ожиданиями. А уехала, наблюдая, как я делаю git reset --hard своей жизни. Бюджет на сумку Dior превратился в счет за серверы. Она, что вполне понятно, не впечатлена моими достижениями в кроссплатформенной сборке. Я пока не нашел workflow для "как извиниться за то, что провел годовщину, занимаясь распределенными системами." Claude Code тут не помогает. Я пробовал спрашивать. Он предложил цветы и рукописную записку. Я попросил быть конкретнее. Он сгенерировал двенадцать вариантов искреннего письма в голосе C++-разработчика. Ни один не сработал.
Если кто-то решил проблему сохранения отношений во время vibe-coding в отпуске, я очень открыт к предложениям по workflow. 😂
Вторая: как масштабировать это за пределы меня. Всё вышеописанное — подход constraints-first, параллелизм через git worktree, дисциплина review через test-first — сейчас находится в моей голове и моей локальной настройке. Внедрить это в ежедневный workflow команды сложнее, чем любую кроссплатформенную сборку.
Отчасти это проблема инструментов. Но в основном это проблема людей. Такой workflow требует инженеров, которым по-настоящему нравится разбираться, как всё работает, — людей, которые действительно сначала напишут тест, которые получают удовлетворение от чистого, хорошо определенного ограничения и которые не будут срезать путь до "just make it pass." Такое сочетание встречается реже, чем должно бы.
Так что да — мы нанимаем.
Если вы тот тип инженера, который читает статью про infrastructure vibe coding и тут же начинает формировать твердые мнения о том, в чем я был неправ, вы ровно тот человек, с которым я хочу поговорить.
Milvus — это по-настоящему сложная задача распределенных систем: storage engines, indexing pipelines, compaction, replication, failure recovery — и всё это под реальной production-нагрузкой. Мы не строим демо. Мы строим инфраструктуру, от которой зависят люди.
Если решать проблемы такого уровня звучит интересно, приходите строить вместе с нами.
А план восстановления после годовщины я возьму на себя.
Вы можете ознакомиться с нашими открытыми вакансиями или связаться со мной напрямую в LinkedIn.
А если вы с чем-то в этом посте не согласны, тем лучше — я буду рад обсудить это с вами.
Присоединяйтесь к нашему Slack-сообществу или запишитесь на сессию Milvus Office Hours — мы всегда рады поговорить о распределенных системах, AI-инфраструктуре или о том, в чем, по вашему мнению, мы ошибаемся.
Читать далее
Introducing Loon: A New Storage Engine for Vector Data That Never Stops Changing
Loon is a new storage engine for Milvus 3.0 and Zilliz Vector Lakebase, built to manage evolving vector datasets with ColumnGroups, row ID alignment, and Manifests.
What Is a Vector Lakebase?
A Vector Lakebase is a unified, lake-native data architecture for AI that combines vector-database-grade serving with open lake storage, reusable lake-level indexes, and a shared semantic layer.
Zilliz Skills Breakdown: How AI Agents Master Vector Databases
Zilliz's Milvus Skill (pymilvus, 7 files) and Zilliz Cloud Skill (zilliz-cli, 14 modules) bring vector-DB dev and ops into one Claude Code session.