Vibe Coding con Rust: Cómo Enviar WASM sin ser Experto

TL;DR: docfind, el motor de búsqueda de la documentación de VS Code, responde en 0,4ms, pesa 2,7MB comprimido y corre entero en el navegador. Lo construyó un engineering manager que no programa Rust a diario, apoyándose en GitHub Copilot. Es la prueba de que el vibe coding con lenguajes estrictos funciona en producción, si sabes dónde aplicarlo.

Rust sin excusas: el vibe coding cambia la ecuación

Rust tiene fama de ser el lenguaje más difícil de aprender que merece la pena. El borrow checker, los lifetimes, los traits... para un desarrollador que viene de Python o TypeScript, el salto es intimidante. Pero en 2026 se repite un patrón: desarrolladores que no dominan Rust envían código Rust a producción.

¿Cómo? Con asistentes de IA que actúan como puente entre la intención y la sintaxis. Esto no es teoría. docfind, el motor de búsqueda client-side del sitio de VS Code, es la prueba.

El equipo necesitaba búsqueda rápida en su documentación (3.700 documentos, ~3MB de markdown) sin depender de un servidor externo. Evaluaron Algolia, TypeSense, Lunr.js, y descartaron todas: o requerían servidor, o generaban índices de 10MB, o estaban sin mantenimiento. La solución fue un módulo WebAssembly compilado desde Rust que corre entero en el navegador del usuario. Sin servidor, sin API keys, sin costes recurrentes.

¿Qué es docfind y por qué importa?

docfind es un motor de búsqueda client-side escrito en Rust y compilado a WebAssembly. Indexa documentos en tiempo de build y genera un único archivo .wasm que el navegador descarga bajo demanda. Es open source y cualquiera puede usarlo en su sitio estático.

Cuatro algoritmos trabajan juntos bajo el capó:

• FST (Finite State Transducers): indexa keywords en una máquina de estados compacta con búsqueda fuzzy
• RAKE: extrae keywords relevantes de cada documento de forma automática
• FSST: comprime metadatos (títulos, URLs, cuerpo) para reducir el tamaño del índice
• Levenshtein Automaton: tolerancia a errores tipográficos en tiempo de consulta

Los números hablan solos:

Métrica	Valor
Velocidad de búsqueda	~0,4ms por consulta
Tamaño del índice	2,7MB (Brotli)
Documentos indexados	3.700
Peticiones HTTP	1 (lazy-load)
Coste de infraestructura	0€

Vibe coding con Rust: cómo Copilot aceleró cada fase

João Moreno, engineering manager del equipo de VS Code, no programa Rust a diario. Describe a Copilot como "a knowledgeable colleague available at any hour". Lo interesante no es que Copilot "sepa Rust", sino cómo redujo la fricción en cada fase del proyecto.

Fase 1: Investigación de algoritmos

Antes de escribir código, Moreno necesitaba entender FST, RAKE y FSST. En lugar de leer papers académicos completos, usó Copilot para hacer preguntas concretas sobre cada librería, entender trade-offs y evaluar si encajaban con su caso de uso. Algo parecido a lo que implica elegir las herramientas justas en lugar de acumular: investigar antes de implementar.

Fase 2: Scaffolding del target WASM

Al pedir un target WebAssembly, Copilot no solo añadió la configuración: infirió que se necesitaba una función de búsqueda y generó el lib.rs completo con las anotaciones wasm-bindgen correctas y el comando de build.

La estructura de datos central del índice es compacta:

// Estructura del índice: FST para búsqueda, FSST para compresión
pub struct Index {
    fst: Vec<u8>,                               // Transductor de estados finitos
    document_strings: FsstStrVec,                // Metadatos comprimidos
    keyword_to_documents: Vec<Vec<(usize, u8)>>, // keyword -> [(doc_id, relevancia)]
}

Fase 3: Manipulación del binario WASM

El crux técnico fue la decisión de empaquetar el índice dentro del propio módulo WASM en lugar de servirlo por separado. Esto requería parchear el binario con marcadores (0xdead_beef) que el CLI sustituye por la posición real del índice. Copilot ayudó a entender el formato binario WASM, sugirió las APIs correctas de wasmparser y wasm-encoder, y depuró binarios que no eran válidos tras el parcheado.

Fase 4: Productividad con el borrow checker

Next Edit Suggestions manejaba las mecánicas del borrow checker y lifetimes, liberando foco para la lógica de negocio. Según datos de GitHub de 2026, los desarrolladores de Rust con Copilot completan tareas un 35% más rápido manteniendo la calidad del código.

La conclusión de Moreno: "When you're time-constrained and working outside your expertise, having an AI assistant is the difference between shipping and abandoning."

Esto conecta con algo que ya exploramos al hablar del muro del mes 3 en vibe coding: los asistentes de IA funcionan bien como aceleradores, pero no eliminan la necesidad de entender lo que estás construyendo.

Rust + WASM vs JavaScript: cuándo merece la pena

WASM no sustituye a JavaScript para todo. Aquí una comparativa honesta para decidir:

Criterio	JavaScript	Rust + WASM
Rendimiento CPU-intensivo	Variable (JIT)	Constante, hasta 6x más rápido
Acceso al DOM	Directo	Requiere puente JS
Tamaño del bundle	Menor para lógica simple	Menor para lógica compleja
Curva de aprendizaje	Baja	Alta (con IA: media)
GC pauses	Sí	No
Caso ideal	UI, DOM, eventos	Cálculo, parsing, búsqueda

Regla práctica: si tu lógica no toca el DOM y es CPU-intensiva (búsqueda, compresión, procesamiento de datos), Rust + WASM tiene sentido. Si es interacción con la UI, quédate con JavaScript.

Cómo usar docfind en tu sitio estático

Si tienes un sitio estático y quieres búsqueda sin servidor, docfind se integra en tres pasos:

# Instalar el CLI (sin dependencias externas)
curl -fsSL https://microsoft.github.io/docfind/install.sh | sh

# Generar el índice a partir de un JSON con tus documentos
docfind documents.json output/

# Resultado: docfind.js + docfind_bg.wasm listos para servir

El JSON de entrada es simple: cada documento tiene título, URL y contenido. docfind extrae keywords con RAKE, construye el FST y empaqueta todo en un único .wasm. Tú solo necesitas construir la UI de resultados en tu frontend.

Para quienes buscan reducir costes en sus herramientas de desarrollo, esto es relevante: cero coste recurrente frente a servicios de búsqueda que cobran por consulta o requieren un servidor dedicado.

En Producción

El tutorial y la producción no son lo mismo. Estos son los puntos que cambian cuando docfind o cualquier módulo WASM pasa de demo a sistema real.

Rendimiento: los 0,4ms por consulta son consistentes porque WASM no tiene pausa de garbage collector. Pero el tiempo de descarga inicial (2,7MB con Brotli) importa. La estrategia de VS Code es lazy-load: el módulo solo se descarga cuando el usuario muestra intención de buscar, no en la carga inicial de la página.

Tamaño del índice y escalabilidad: 3.700 documentos generan un índice de 2,7MB comprimido. La relación no es lineal gracias a la compresión FST, pero para sitios con más de 10.000 documentos conviene medir si el tamaño sigue siendo aceptable para descarga client-side. A partir de cierto punto, un servicio server-side puede ser más práctico.

Rebuild en CI/CD: cada vez que el contenido cambia, hay que regenerar el índice. En un pipeline de CI esto tarda segundos, pero tienes que integrarlo. Si tu contenido cambia varias veces al día, necesitas un pipeline que regenere y despliegue el .wasm con esa frecuencia.

Costes: 0€ en infraestructura de búsqueda. El módulo se sirve como archivo estático desde tu CDN. Comparado con Algolia (plan gratuito limitado a 10.000 búsquedas/mes) o un servidor TypeSense dedicado (~5-15€/mes), la diferencia es clara para sitios pequeños y medianos.

Limitación del vibe coding con Rust: los asistentes de IA funcionan bien para Rust estándar (structs, traits comunes, wasm-bindgen), pero las anotaciones complejas de lifetimes y el código unsafe requieren revisión manual. La IA sugiere, pero tú validas. Si estás eligiendo herramienta para este tipo de proyectos, la comparativa entre modelos para coding puede ayudarte a decidir qué asistente usar.

Errores comunes con Rust y WebAssembly

Error: el módulo WASM tarda en cargar y bloquea la UI.
Causa: se carga el .wasm en el critical path del rendering.
Solución: lazy-load con import() dinámico, solo cuando el usuario interactúa con el buscador.

Error: el índice pesa más de lo esperado.
Causa: no se aplica compresión Brotli en el servidor o CDN.
Solución: configurar Content-Encoding: br. La diferencia es significativa: 5,9MB sin comprimir vs 2,7MB con Brotli.

Error: rendimiento peor que JavaScript para operaciones simples.
Causa: serialización excesiva entre JS y WASM. Cada transferencia de datos entre contextos tiene coste de copia.
Solución: mantener los datos dentro del límite WASM. Ejecuta la mayor cantidad de trabajo posible dentro del módulo antes de devolver resultados a JavaScript.

Preguntas frecuentes

¿Necesito saber Rust para usar docfind en mi sitio?

No. docfind se distribuye como CLI precompilado. Preparas un JSON con tus documentos, ejecutas el comando y obtienes los archivos listos para servir. Solo necesitas HTML y JavaScript básico para construir la UI de resultados.

¿Copilot entiende Rust tan bien como Python o TypeScript?

Para patrones comunes (structs, traits, wasm-bindgen, iteradores), sí. Para lifetimes complejos y código unsafe, la calidad baja. Según datos de GitHub de 2026, el 78% de los desarrolladores Rust usan asistentes de IA, pero la mayoría reporta que necesitan más revisión manual que en otros lenguajes.

¿WebAssembly sustituye a JavaScript en el frontend?

No. WASM complementa a JavaScript en tareas CPU-intensivas como búsqueda, compresión y procesamiento de datos. El acceso al DOM sigue siendo territorio de JavaScript. La combinación de ambos es lo que produce resultados como los de docfind: 0,4ms de latencia sin renunciar a la interactividad web.

docfind demuestra que el vibe coding con lenguajes compilados no es un truco de demo. Es código en producción sirviendo búsquedas en la documentación de VS Code, uno de los editores más usados del mundo. La clave no está en que Copilot "sepa Rust", sino en que reduce la fricción lo suficiente para que un desarrollador competente opere fuera de su zona de confort sin abandonar el proyecto a mitad de camino.

Si te planteas Rust + WASM para algún componente de rendimiento crítico en tu proyecto, docfind es un buen punto de partida: open source, bien documentado y con un caso de uso probado. Y el patrón que representa, usar asistentes de IA como puente hacia lenguajes que no dominas, es aplicable más allá de Rust: a Go, C++ o cualquier lenguaje con compilador estricto.

¿Has probado Rust con un asistente de IA? Cuéntamelo en Twitter @sergiomarquezp_.