Un autor de Habr hace «vibe coding» en Rust con tres utilidades: DirMerge, ProcessTree y Notepad

El autor de una serie en Habr ha publicado una nueva tanda de utilidades escritas en Rust con ayuda de un LLM: DirMerge, ProcessTree y Notepad. Son tres programas y una sola pregunta: ¿se pueden construir con una red neuronal herramientas que una persona use de verdad cada día, sin volver al software de siempre al cabo de una semana? El propio autor describe lo que hace como «esquizofasia con vibe coding», de modo que el tono autoirónico queda claro desde el principio.

Una salvedad importante: el anuncio no menciona ni el nombre del modelo, ni el volumen de código, ni el tiempo de desarrollo, ni resultados de pruebas. Todo lo que sigue se apoya en el planteamiento declarado del experimento y en los nombres de las utilidades. Las conclusiones completas del autor están en el artículo de Habr.

Qué se pone a prueba

La mayoría de las demostraciones de vibe coding se quedan en el «funciona en mi máquina». Aquí el listón está más alto: la utilidad debe desplazar a una herramienta que el autor ya utiliza. Es un criterio exigente. El usuario nota los retrasos, el manejo torpe del teclado, los ajustes perdidos y el comportamiento extraño con grandes volúmenes de datos. Una aplicación sencilla no perdona los fallos pequeños, porque se usa durante horas.

Por los nombres, cabe suponer que DirMerge se encarga de fusionar directorios, que ProcessTree muestra los procesos en forma de árbol y que Notepad sustituye a un editor de texto. Son tareas clásicas, para las que existen desde hace tiempo soluciones maduras. Por eso las novedades tendrán que compararse con competidores muy sólidos.

Por qué Rust y por qué herramientas sencillas

Rust no se ha elegido al azar para este experimento. El compilador comprueba con rigor la propiedad de la memoria y los tipos, de modo que parte de los errores que los LLM suelen cometer en lenguajes dinámicos se descartan ya al compilar. El resultado es un único ejecutable sin un runtime pesado. La contrapartida: los modelos manejan peor el borrow checker y los lifetimes, y el ciclo de «genera, no compila, corrige» puede requerir muchas iteraciones.

Las utilidades sencillas sirven como prueba por otra razón. Tienen un ámbito de tareas acotado, un comportamiento claro y una referencia fácil de comparar. Si la IA no puede con un editor de texto o con la vista de árbol de procesos, es pronto para contar con ella en sistemas complejos.

Qué se sabe del experimento:

• lenguaje: Rust;
• método: vibe coding con participación de un LLM;
• número de utilidades en esta entrega: tres (DirMerge, ProcessTree, Notepad);
• criterio: sustituir las herramientas que el autor usa en la práctica;
• principal riesgo señalado por el autor: problemas sin solución que obliguen a volver al software de siempre;
• el modelo, el volumen de código y las métricas de rendimiento no se revelan en el anuncio.

Cómo aprovechar esta experiencia

Si quiere repetir el experimento, empiece por una herramienta que le resulte fácil de comprobar. Elija una tarea con una referencia clara, por ejemplo una utilidad para comparar carpetas, y formule los criterios de aceptación de antemano: cuántos archivos debe procesar, qué atajos de teclado necesita, qué se considera una regresión. Mantenga a mano la herramienta antigua durante un par de semanas como mínimo.

Observe dónde falla exactamente el modelo. Los puntos habituales son el tratamiento de rutas y codificaciones en distintos sistemas operativos, la corrección con directorios grandes y el manejo del portapapeles y del foco de la ventana. Son precisamente estos detalles los que distinguen un prototipo de un programa que se puede usar. Vale la pena leer la serie por esas conclusiones, no por las utilidades en sí.