El costo real de una elección exótica

Es tentador elegir un lenguaje porque es elegante, o rápido, o porque alguien a quien respetas jura por él. Para el vibe coding específicamente, ese instinto puede hundir silenciosamente un proyecto. Aquí está el porqué: cada hora que pasas peleando con las herramientas de un lenguaje de nicho, o desenredando una salida de IA que está sutilmente equivocada porque el modelo ha visto muy pocos ejemplos, es una hora que no pasaste enviando tu producto. La elección exótica rara vez falla de forma escandalosa. Falla como un goteo lento de ciclos de corrección extra, librerías faltantes y respuestas de Stack Overflow que no existen.

Concretamente, la penalización aparece en tres lugares. Primero, la IA es menos fluida, así que comete más errores y es peor corrigiéndolos — y tú, al no conocer el lenguaje, no puedes distinguir el código bueno del malo. Segundo, el ecosistema es más delgado, así que la librería que necesitas puede no existir, puede estar abandonada, o puede no tener ejemplos que copiar. Tercero, cuando te atascas, la web está más silenciosa: menos tutoriales, menos preguntas respondidas, menos personas que hayan chocado con exactamente tu muro. Con Python o TypeScript, esos tres son no-problemas.

Nada de esto significa que los lenguajes exóticos sean malos. Significa que la carga de la prueba recae en la elección exótica. Si tienes una razón concreta y específica — genuinamente necesitas la velocidad de Rust, la App Store te obliga a usar Swift, estás extendiendo un servicio Go existente — entonces paga el costo con los ojos abiertos. Si la razón es "me pareció cool", elige la opción popular y lanza algo. Siempre puedes reescribir después, y casi nunca lo harás, porque la elección popular habrá hecho el trabajo.