En un post anterior decía por ello que 'no era oro todo lo que relucía'. En este post, precisamente, quiero sacar a colación aquello que 'no reluce' en el 'vibe coding'.
Y para ello me baso, como en posts anteriores, en las aportaciones de Addy Osmani en su libro 'Beyond Vibe Coding: From Coder to AI-Era Developer'.
Recordatorio 'express'
Antes, un recordatorio brevísimo, express. El término 'Vibe coding', acuñado por Andrej Karpathy, y de fronteras difusas, designa la generación de código mediante el uso de inteligencia artificial, normalmente grandes modelos de lenguaje generalistas o especializados en generación de código. Es decir, el desarrollador expresa en lenguaje natural lo que quiere que haga una aplicación, función o lo que sea, y el modelo de lenguaje genera el código correspondiente.
Como digo, las fronteras del término no son claras, pero personalmente creo que se aplica más a cuando esa generación de código es completa o casi completa, es decir, que se genera una aplicación completa o gran parte de ella. De forma más general, podemos hablar de ingeniería de software asistida por IA donde el nivel de ambición puede ser menor y lo que el desarrollador puede solicitar al modelo de lenguajes es, a lo mejor, sólo una función, o una pantalla o que le ayude a resolver un error sintáctico o de ejecución.
En cualquier caso, hablamos de generación de código y un código que el desarrollador solicita a la IA mediante lenguaje natural.
Bajando un poco a la realidad
Si bajamos un poco a la realidad, al menos actualmente, no resulta posible generar aplicaciones que sean completas, fiables, seguras y escalables sólo mediante un 'prompt', por largo, sofisticado y bien elaborado que éste sea.
Se pueden conseguir resultados espectaculares generando aplicaciones sencillas en modo demostración o prototipo, pero no aplicaciones pensadas para producción real.
La realidad actual apunta más a un trabajo conjunto entre un desarrollador y la IA, donde la IA genera grandes partes del código e incluso ayuda a corregirlo pero con intervención, supervisión y modificaciones por parte del desarrollador humano.
Aspectos que aún le cuestan al 'vibe coding'
Osmani, en su libro, destaca cinco facetas, como aspectos que le cuestan (que no suele conseguir) el 'vibe coding' actual:
- Sistemas complejos: El 'vibe coding' funciona bien con aplicaciones sencillas y típicas, como ventanas web que recubren operaciones CRUD (Create, Read, Update, Delete) en bases de datos. En general, aplicaciones sencillas y comunes que los LLMs 'han visto' con frecuencia en sus datos de entrenamiento. Pero lo tienen muy difícil ante el caso de algoritmos complejos o planteamientos novedosos que no existen en los datos de entrenamiento o que se encuentren poco representados. En estos casos, la IA tiende a generar un código que se acerca al correcto, pero no lo es en realidad.
- Optimizaciones de bajo nivel y programación a nivel sistema: Los LLMs actuales están fundamentalmente entrenados con código escrito en lenguajes de alto nivel y problemas también de alto nivel, cercanos al negocio o la funcionalidad. Sin embargo, la optimización de ciertos algoritmos implica la programación a muy bajo nivel, muy cerca del sistema, para reducir complejidad algorítmica y tiempos de procesamiento, optimizar el uso de recursos hardware, para adaptar los algoritmos al hardware subyacente, etc. Por tanto, el código que generan suele ser subóptimo. Para muchas aplicaciones no críticas puede ser más que suficiente, pero para otras más especiales no tanto.
- Frameworks únicos o de nicho: De nuevo, estos modelos están entrenados con base en código fuente basado en librerías y frameworks más o menos populares y, por tanto, pueden ser incapaces de generar un código correcto en el caso de frameworks o librerías muy nuevos o muy de nicho (y con pocos ejemplos en los datos de entrenamiento)
- Interfaces de usuario creativas: Una vez más, los modelos generan correctamente código para formas de resolver un problema comunes. En lo relativo a la interfaz de usuario, generan correctamente, por ejemplo, formularios, dashboards y otras formas comunes y probadas de interfaz de usuario. Pero les resulta muy complicado generar una experiencia nueva, especial, diferente, inspiradora.
- Interpretación de intenciones y requisitos: En este caso, el problema puede estar más en el lado del desarrollador, pero lo cierto es que los modelos no siempre resuelven bien unas especificaciones con requisitos implícitos o contradictorios.
Limitaciones y equilibrios
Además de las facetas vistas más arriba, Osmany también nos alerta de algunas limitaciones de los LLMs o de algunas circunstancias que pueden precisar de adoptar algún tipo de equilibrio, de solución de compromiso:
- Calidad variable de la salida: Como sucede en otros ámbitos de su aplicación, los LLMs pueden generar un código que parezca correcto pero que no funcione del todo bien, o que, por ejemplo, no reaccione bien ante errores. También puede producir un código funcional pero ineficiente. Por tanto, parece inevitable una supervisión responsable y real por parte del desarrollador humano de todo lo que genera mediante IA.
- La ambigüedad en los 'prompt's conduce a ambigüedad en el código: Como ocurre en general con la ingeniería de instrucciones ('prompt enmgineering') y como , en el fondo, también ocurre con la especificación de requisitos tradicional, si las instrucciones (que actúan como requisitos) son ambiguos, incompletos o incorrectos, el resultado también presentará carencias.
- Confianza excesiva y atrofia de habilidades: Quizá aún sea pronto para ver con claridad este efecto, pero parece previsible que si un desarrollador confía en exceso en la IA y apenas hace aportaciones propias, poco a poco sus habilidades se irán deteriorando y con ello su capacidad de detectar errores, de optimizar el código, de depurar el resultado y, en general, se empobrecerá como desarrollador. Y también se empobrecerá el código que genere, cada vez más apoyado en la IA
- Aspectos de seguridad y privacidad: Con frecuencia, los entornos de 'vibe coding' se apoyan en el envío de código a terceros en la nube, lo cual puede plantear preocupaciones en cuanto a privacidad. Igualmente, existe el riesgo de que el código que genere la IA sea casi una copia de un código real quizá protegido por propiedad intelectual.
- Sesgos en las salida: Los LLMs usados para generar código, también pueden presentar sesgos como otros modelos de IA o como estos mismos modelos en otros ámbitos de aplicación. En el ámbito de la generación de código suelen ser sesgos 'inocentes' como tener preferencia por dar ciertos nombres a las variables, pero conviene estar vigilantes de que no se introducen sesgos más graves.
- Factores humanos y confianza: Finalmente entra el factor humano que puede hacer que los desarrolladores no acepten esta forma de trabajar, quizá por desconfianza en los resultados, o quizá, incluso, porque cambia la naturaleza de su trabajo que hasta ese momento, antes del 'vibe coding', quizá percibían como más divertido, independiente y creativo.
Conclusiones
Como en el fondo cabía imaginar, el 'vibe coding' no es algo mágico, sino que tiene sus limitaciones y problemáticas, unas limitaciones y problemáticas que tienden a resolverse, en la mayor parte de los casos, siendo conscientes de que el trabajo de desarrollo basado en IA implica una importante supervisión por parte de desarrolladores humanos de cara a la verificación, optimización, depuración, etc. Y unos desarrolladores humanos que, además, deben estar mentalizados y tener altas capacidades por que, si no, seguramente les pasarán inadvertidos los errores o soluciones subóptimas que les proponga la IA.
No hay comentarios:
Publicar un comentario