Hasta ahora, veo sobre todo a gente intentando utilizar vibe coding para clonar aplicaciones existentes. Ya sea para evitar pagar por aplicaciones externas o para poder disponer de su propia versión personal de esas aplicaciones. Me atrevo a decir que más lo primero que lo segundo 😉. Y claro, también el síndrome del “No inventado aquí“ (Not invented here, NIH ) .

Pero muchos de estos intentos fracasan porque la gente solo reproduce lo que ve. Y lo que se ve es mucho menos de lo que uno cree. Como usuario, solo se tiene una visión parcial del comportamiento de la aplicación. Pero no sabe cómo se ha implementado. Ni por qué (ej. que alternativas ya se estudiaron y luego se descartaron por problemas que nosotros acabaremos “redescubriendo” si nos lanzamos a reimplementar a lo loco).

Y, aun respecto a ese “qué” que sí pueden observar, los usuarios solo tienen una perspectiva limitada, condicionada por la forma en la que utilizan la aplicación. Pueden “probar” la app con algunas entradas, observar las salidas y utilizar esos ejemplos como una especie de tabla de resultados que el agente de vibe coding podría emplear como tests de la nueva app “vibecodeada”. Pero existen muchas otras entradas y usos posibles que ni siquiera pueden imaginar, porque no corresponden a la forma habitual en la que usan la aplicación. Al menos hoy en día. Y esa forma de uso puede cambiar en el futuro. Cuando ese futuro llegue, ya no podrán comprobar qué habría devuelto entonces la aplicación original porqué ya no la tienen y el añadir soporte para sus nuevos requisitos será aún más difícil.

Aun así, como señaló Hanna Siemaszko en nuestra discusión en LinkedIn sobre este tema, este ejercicio podría ser muy útil como actividad docente para estudiantes que empiezan sus estudios de informática. Sería un buen ejercicio pedirles que clonasen una aplicación y, a continuación, señalar todos los casos límite, problemas de seguridad, etc. que su clon no es capaz de gestionar en comparación con la aplicación original. Después, se podrían explicar esos problemas y desarrollar conjuntamente, paso a paso, la evolución del clon inicial hasta convertirlo en una réplica realmente equivalente de la aplicación original.

Que como ya hemos dicho un montón de veces, la IA no tiene que reemplazar nada si no completar los ingenieros software.