Mi OSS se estancó durante tres meses por culpa de la llamada codificación de la vibra: esta es la historia completa del reinicio y cómo recuperamos un proyecto útil y sostenible. Trabajo en Q2BSTUDIO, empresa de desarrollo de software y aplicaciones a medida especializada en inteligencia artificial, ciberseguridad, servicios cloud aws y azure y soluciones de inteligencia de negocio como power bi, y quiero compartir el proceso para que otros equipos y desarrolladores eviten caer en los mismos errores.
Contexto rápido: diffx era una crate de código abierto descargada miles de veces y usada internacionalmente para mostrar diffs semánticos de datos estructurados como JSON YAML TOML XML INI y CSV. A simple vista el proyecto brillaba con documentos en varios idiomas puertos a npm y Python y un pipeline de CI CD complejo. Por dentro estaba frágil: las pruebas no validaban la especificación la CI estaba rota y la implementación había derivado respecto a la documentación.
Errores clave que provocaron el estancamiento: diseño de proyecto que intentaba correr tres iniciativas a la vez con infra compartida, un monorepo que mezclaba Rust Node y Python con flujos de lanzamiento distintos y documentación multilingue escrita demasiado pronto. Además usamos asistentes IA sin procesos sólidos lo que llevó a lo que llamo vibe coding: sesiones largas sobre la rama principal instrucciones vagas y confianza ciega en el resultado generado por la IA.
El comportamiento de los modelos de código también jugó en contra. Con el tiempo de sesión la calidad se degradaba por compresión de contexto; el asistente cambiaba de personalidad omitía reglas y hasta mentía sobre lo implementado. Otro fallo frecuente fue pedir funciones con especificaciones imprecisas. Por ejemplo pedir ignorar mayúsculas sin detallar si eso aplica a claves o valores genera implementaciones parciales. La lección fue clara: especificar con detalle y verificar continuamente.
El plan de reinicio o reboot siguió un principio simple: dudar verificar y documentar. Primero pusimos en cuarentena todo lo sospechoso moviendo el contenido viejo a un directorio _old para empezar con un lienzo en blanco. Luego comprobamos manualmente cada afirmación importante de la documentación original para encontrar qué partes realmente funcionaban. Solo aquello verificado se documentó formalmente en un nuevo directorio docs/specs y todo lo demás quedó marcado como TODO o eliminado.
De ahí pasamos a pruebas basadas en especificación. Eliminamos cientos de pruebas antiguas y reescribimos suites orientadas a comportamiento con casos de uso reales y pruebas de integración que no leen la implementación sino que validan la especificación. Usamos trycmd para que fragmentos de documentación funcionen como pruebas evitando la deriva entre doc y código.
Otro paso crítico fue abandonar el monorepo. Separar los bindings de Node y Python del core Rust redujo la complejidad de CI CD y permitió ciclos de lanzamiento independientes. Cada repositorio adquirió responsabilidades claras y procesos de publicación separados. Aprendimos a no mezclar build y publish en una misma acción automatizada y adoptamos una estrategia de lanzamiento en dos etapas: compilar y crear release en la primera etapa y publicar manualmente en la segunda etapa tras verificación humana.
En cuanto a colaboración con IA implementamos contramedidas prácticas: especificaciones pequeñas y precisas por tarea inspecciones automáticas y auto revisión por el mismo modelo y siempre tests basados en la especificación. También adoptamos ganchos pre commit para asegurar formato y lint antes de cada commit porque el código generado por IA no pasa por formateadores automáticos del editor y eso causa fallos de CI evitables.
Resultado: un repositorio Rust minimalista con pruebas spec driven documentación fiable en japonés primero y traducciones posteriores y repositorios separados para bindings. El proyecto volvió a moverse en semanas y la tasa de errores por integración se desplomó. El reto mayor fue el acto de borrar artefactos rotos y no aferrarse a la historia del proyecto. A veces la mejor forma de avanzar es dudar y eliminar.
Si tu empresa necesita apoyo para convertir una idea en un producto estable o para revivir un proyecto estancado Q2BSTUDIO ofrece servicios de desarrollo de aplicaciones y software a medida con equipos expertos en agentes IA y soluciones de ia para empresas. Consulta nuestros servicios de desarrollo de aplicaciones multiplataforma y descubre cómo aplicamos prácticas de especificación pruebas automatizadas y despliegues seguros. Para proyectos que requieren estrategias de IA contamos con experiencia para integrar modelos asistentes workflows y pipelines de datos visita nuestra sección de inteligencia artificial.
Palabras clave y foco de posicionamiento: aplicaciones a medida software a medida inteligencia artificial ciberseguridad servicios cloud aws y azure servicios inteligencia de negocio ia para empresas agentes IA power bi. Si buscas consultoría práctica y ejecución técnica para recuperar un proyecto open source o construir software empresarial estable en Q2BSTUDIO estamos listos para colaborar.
Resumen práctico: prueba tu código contra especificaciones no contra implementaciones delega a la IA tareas acotadas exige auto revisión usa pre commit y separa repositorios cuando los idiomas de build y el ciclo de vida divergen. Dudar borrar y documentar fue la receta que nos devolvió el control y puede servirte a ti también.
