Mi esposa quería Dior. Gasté 600 dólares en Claude Code para vibe-codear una base de datos de 2 millones de líneas en su lugar.
Mi esposa y yo llevamos diez años casados, y ella quería un bolso Dior para nuestro aniversario.
En lugar de comprar algo — porque estaba completamente absorto en un experimento de IA — pasé todas las vacaciones encerrado en mi estudio, manejando tres suscripciones de Claude Code de $200/mes, intentando convencer a un LLM de que compilara de forma cruzada una base de datos distribuida en C++ de 2 millones de líneas.
Y probablemente puedas adivinar lo que me pasó después. 😂
En retrospectiva, esta no fue una asignación óptima de recursos.
Así que aprendí dos lecciones ese fin de semana.
Primera: escucha a tu esposa. “Esposa feliz, vida feliz” no es solo un eslogan. Es un principio de estabilidad de sistemas.
Segunda: la IA parece mágica en tareas pequeñas y bien delimitadas. Se comporta de manera muy diferente cuando la apuntas a una infraestructura distribuida real.
Esta publicación trata sobre la segunda lección.
Antecedentes
Soy el mantenedor y colaborador principal de Milvus, la base de datos vectorial de código abierto más popular con más de 42K estrellas en GitHub al momento de escribir esto (~2M de líneas de C++, Go y Python). El sistema es completamente distribuido: los nodos proxy, nodos de consulta, nodos de datos y nodos de índice se coordinan mediante colas de mensajes. Mi área es la capa de almacenamiento e indexación.
Había estado usando Claude Code durante unos meses y estaba genuinamente impresionado. Completó todas las funciones faltantes de una CLI entera por $20 en tokens. Multiplicó por 5 una ruta crítica de rendimiento de consultas en un día, el tipo de optimización que a mí me llevaría una semana solo para entender el código lo suficiente como para tocarlo. Se sentía como tener un ingeniero junior competente que nunca dormía y no cobraba por hora.
Decidí darle un problema real: compilación multiplataforma.
La lección de $600 aprendida
Durante años, nadie en el equipo de Milvus quería tocar la compilación multiplataforma. El sistema de compilación es una mezcla de Go, C++ y Rust sostenida por años acumulados de parches de Conan y CMake que nadie quería volver a revisar. Hacer que funcione en Linux ya es miserable. Windows y macOS moderno eran una pesadilla tan grande de compilar que el equipo los trataba como el problema de otro.
Pensé que ahora tenía Claude Code. Podía encargarme.
Al principio, parecía que tenía razón. Windows compiló, y envié el parche, pensando que la parte difícil había terminado.
Entonces Linux falló. Arreglé Linux y Mac falló. Arreglé Mac, y el entorno GPU falló. Cada arreglo introducía dos problemas nuevos en una plataforma diferente, y los parches empezaron a acumularse. Al final, tenía un parche de 1000 archivos y ~100k líneas tocando configuraciones de Conan, scripts de CMake, adaptadores de compatibilidad de C++ y cosas que no reconocía.
La parte enloquecedora no eran los bugs; era el bucle. Seguía diciéndole a Claude: "Nada de arreglos chapuceros", "dame la solución limpia". Cumplía cada vez, generando parches que parecían más limpios. Luego cada parche limpio rompía otras tres plataformas, y el ciclo volvía a empezar. Si miraras mi .claude/settings.local.json, encontrarías 147 reglas de permisos aprobadas manualmente. Cada una es una marca de tiempo de mí pensando: "Esta vez funcionará."
Gasté $600 en el plan Max y quemé unas vacaciones enteras, y todo lo que tenía era un montón de comandos git reset --hard.
Me quedé ahí sentado mirando mi terminal, preguntándome si todo esto no era más que hype bien empaquetado. Entonces me di cuenta de que el problema no era Claude. Era como decirle a un estudiante de posgrado que publicara un artículo en Nature sin especificar la pregunta de investigación. Le había entregado un problema sin definir nunca qué significaba realmente "resuelto".
Qué funciona realmente
El fracaso no fue la inteligencia de Claude. Fue un fracaso de proceso. Así que empecé de nuevo con uno diferente.
Restricciones antes que código. No "hacer que compile en Windows." Las restricciones reales, escritas explícitamente: todas las plataformas pasan sus pruebas unitarias, el CI está en verde en todas partes, sin hacks de plataforma con #ifdef, sin parches para rodear dependencias rotas. Esta es la parte difícil: requiere saber cómo se ve "terminado", lo que exige pensar cuidadosamente antes de tocar nada. Con infraestructura compleja, la mayor parte del trabajo está en pensar.
Revisar pruebas, no código. Escribo casos de prueba (o hago que Claude los genere), pero reviso las pruebas, no la implementación. ¿Esta prueba comprueba que la receta de Conan se resuelve correctamente en ARM? ¿Cubre la configuración de CMake en Docker? Puedo evaluar eso en minutos. No puedo revisar 10.000 líneas de parches de C++ multiplataforma con ninguna confianza, en ninguna cantidad de tiempo.
De abajo arriba, una capa a la vez. No dejes que Claude cambie 1000 archivos. Primero fija las versiones de las dependencias. Una vez verificadas esas restricciones, sube a la configuración de CMake. Una vez que eso esté estable, al código específico de plataforma. Cada capa es lo bastante pequeña como para verificarla por completo antes de subir.
Rehice la compilación multiplataforma desde cero usando este enfoque. Dos días. Unas pocas decenas de commits. Cada uno pequeño, cada uno con una prueba correspondiente. Sin hacks con #ifdef: la solución de fondo fue actualizar recetas de Conan y subir versiones de bibliotecas de terceros, arreglando la cadena de dependencias real en lugar de taparla con parches superficiales.
Misma tarea. Resultado completamente distinto.
La idea sobre las pruebas merece un punto propio: en un sistema distribuido con una suite de pruebas madura, las pruebas son la especificación. Si esas pruebas de integración pasan —las 47 que se pusieron en rojo durante mi primer intento— entonces los contratos de seal/flush están intactos, la reproducción del WAL es correcta y los nodos de consulta todavía pueden cargar segmentos con mmap sin corrupción. No necesito leer el C++ para saberlo.
Dejé de revisar código. Empecé a revisar pruebas. El código se convirtió en un detalle de implementación.
Echándole hardware
Una vez que el flujo de trabajo era el correcto, apareció un nuevo cuello de botella: estaba ahí sentado esperando.
Una sesión de Claude Code masticando una base de código de 2 millones de líneas no es rápida. Cada tarea lleva 20-30 minutos de tiempo de reloj. El cuello de botella no era la inteligencia. Era el rendimiento.
Así que le dije a mi esposa que necesitaba un servidor con una GPU para mis “agentes de IA.” Esa conversación salió más o menos como cabría esperar. Lo compré de todos modos, además de un Mac Mini para acompañar mi MacBook. Al final, tenía tres máquinas y seis terminales, cada una ejecutando una sesión independiente de Claude Code.
Lo que hace que esto funcione es git worktree. Cada sesión tiene su propia tarea, rama y directorio de trabajo, completamente aislados de los demás. Y como el enfoque de restricciones primero significa que cada rama tiene sus propios criterios de aceptación, el paralelismo es trivialmente seguro: si las pruebas de cada rama pasan de forma independiente, fusionarlas es de bajo riesgo.
Para la compilación multiplataforma, esto significó una sesión resolviendo dependencias de Conan en Linux ARM, otra arreglando la configuración de CMake en macOS y otra ocupándose de la compatibilidad con MSVC en Windows, todas ejecutándose simultáneamente sin interferencias. Lo que antes era un cambio de contexto serial entre plataformas se convirtió en ejecución paralela entre máquinas.
El patrón se generaliza al trabajo diario. En cualquier día dado, una sesión está refactorizando el planificador de compactación, otra está optimizando la ruta de búsqueda de HNSW y una tercera está escribiendo pruebas de integración para un caso límite de inserción en streaming. Salto entre terminales como un gerente revisando a sus subordinados directos, salvo que estos subordinados directos nunca necesitan pausas para café y no tienen opiniones sobre la planificación del sprint.
La verdadera lección es que la infraestructura de vibe coding está limitada por la computación, no por el talento. El factor limitante no es qué tan inteligente es la IA; es cuántas instancias puedes ejecutar en paralelo. Anthropic usó 16 instancias paralelas de Claude para construir un compilador de C completo, lo que hizo que mis seis terminales parecieran modestas.
A lo que sigo volviendo
La IA resuelve exactamente el problema que le pones delante, nada más. Si planteas mal el problema, obtienes una solución perfecta para lo equivocado.
"Compila en macOS 15" — resuelto en una hora. Pero eso es un óptimo local. El objetivo real era "compila en todas partes sin hacks." Esos son problemas distintos. La IA no tenía forma de saberlo. Eso recae completamente en el ingeniero.
Construir para ti mismo con IA es sorprendentemente fácil — conoces tu máquina, tus casos límite, y "funciona en mi equipo" es un objetivo de optimización alcanzable. Construir infraestructura que funcione para todos los usuarios, en todas las plataformas, en todos los entornos es fundamentalmente distinto. Esa brecha es donde la ingeniería sigue viviendo. Para el software de infraestructura, esa brecha es enorme.
Los bugs más difíciles de nuestro sistema de producción — los que requirieron revertir después del merge — no fueron detectados por ningún enfoque de revisión de código con IA que probamos. Los bugs eran sintácticamente correctos. El problema estaba en las suposiciones implícitas del desarrollador, invisibles en el diff y ausentes en el código circundante. El comportamiento del sistema solo tenía sentido si mantenías un modelo mental de cómo se suponía que tres componentes distintos debían coordinarse — un modelo que existía solo en la cabeza de un desarrollador, nunca escrito.
Eso todavía requiere un humano que entienda el sistema lo suficiente como para saber qué preguntas hacer.
Los tres planes de $200 y unas vacaciones perdidas fueron la mejor inversión que he hecho. No porque me enseñaran a usar IA. Porque me enseñaron cómo no usarla.
Las herramientas son genuinamente buenas. La pieza que faltaba siempre fue el flujo de trabajo alrededor de ellas. Pruebas antes que código, restricciones antes que pruebas, y suficiente hardware para ejecutarlo todo en paralelo. Eso es todo.
Los problemas que siguen sin resolverse
Después de todo — el parche fallido, los comandos de reset, las seis terminales en paralelo — el problema más difícil de resolver sigue siendo el humano.
Por ahora, tengo dos dolores de cabeza, y ninguno tiene una solución clara.
El primero: mi esposa. Llegó a las vacaciones con expectativas razonables. Se fue viéndome hacer git reset --hard a mi vida. El presupuesto para el bolso Dior se convirtió en una factura de servidor. Ella, comprensiblemente, no está impresionada por mis logros de compilación multiplataforma. Todavía no he encontrado un flujo de trabajo para "cómo disculparte por pasar tu aniversario haciendo trabajo de sistemas distribuidos." Claude Code no ayuda aquí. Probé preguntarle. Sugirió flores y una nota escrita a mano. Le dije que fuera más específico. Generó doce variaciones de una carta emotiva con la voz de un desarrollador de C++. Ninguna funcionó.
Si alguien ha resuelto el problema de mantener una relación mientras vibe-codea durante unas vacaciones, estoy muy abierto a sugerencias de flujo de trabajo. 😂
El segundo: cómo escalar esto más allá de mí. Todo lo anterior — el enfoque de restricciones primero, el paralelismo con git worktree, la disciplina de revisión con pruebas primero — está actualmente en mi cabeza y en mi configuración local. Llevarlo al flujo de trabajo diario de un equipo es más difícil que cualquier compilación multiplataforma.
Esto es en parte un problema de herramientas. Pero sobre todo es un problema de personas. Este tipo de flujo de trabajo requiere ingenieros que disfruten genuinamente entender cómo funcionan las cosas — personas que realmente escriban la prueba primero, que encuentren satisfacción en una restricción limpia y bien definida, y que no tomen el atajo de "simplemente haz que pase." Esa combinación es más rara de lo que debería ser.
Así que sí — estamos contratando.
Si eres el tipo de ingeniero que lee un artículo sobre vibe coding de infraestructura e inmediatamente empieza a formarse opiniones firmes sobre en qué me equivoqué, eres exactamente la persona con la que quiero hablar.
Milvus es un problema de sistemas distribuidos genuinamente difícil: motores de almacenamiento, pipelines de indexación, compactación, replicación, recuperación ante fallos — todo bajo carga de producción real. No estamos construyendo demos. Estamos construyendo infraestructura de la que la gente depende.
Si resolver problemas a ese nivel suena interesante, ven a construir con nosotros.
Y yo me encargaré del plan de recuperación del aniversario.
Puedes consultar nuestras vacantes abiertas o contactarme directamente en LinkedIn.
Y si no estás de acuerdo con algo de esta publicación, mejor aún: estaré encantado de conversarlo contigo.
Únete a nuestra comunidad de Slack o reserva una sesión de Milvus Office Hours ; siempre estamos encantados de hablar sobre sistemas distribuidos, infraestructura de IA o sobre dónde crees que estamos equivocados.
Sigue leyendo
From Vector Database to Vector Lakebase
Zilliz offers a fully managed Vector Lakebase powered by Milvus, unifying real-time vector search, lake-scale discovery, and Al data operations.
Why I’m Against Claude Code’s Grep-Only Retrieval? It Just Burns Too Many Tokens
Learn how vector-based code retrieval cuts Claude Code token consumption by 40%. Open-source solution with easy MCP integration. Try claude-context today.
AI Integration in Video Surveillance Tools: Transforming the Industry with Vector Databases
Discover how AI and vector databases are revolutionizing video surveillance with real-time analysis, faster threat detection, and intelligent search capabilities for enhanced security.