Hoy es 2026-01-07.
Un gran fracaso usando Vibe Coding. La calidad del código que me escribió la IA era demasiado baja, completamente inutilizable. Me vi obligado a reescribir completamente el proyecto ZEN, cambiando a la programación tradicional de la vieja escuela para implementarlo.
Usé IA para generar código desde cero. Después de múltiples iteraciones, la calidad de la ingeniería comenzó a colapsar: las nuevas funciones no podían integrarse, los errores surgían por todas partes, la estructura del código era un caos, e incluso eliminar funciones se volvió excepcionalmente difícil. Estos son síntomas típicos de una explosión de deuda técnica. Por lo tanto, intervine decisivamente y decidí reescribir todo el proyecto. Un punto clave fue que noté que la calidad del código OOP escrito por la IA era particularmente mala. Cada vez que había una nueva función, me creaba una clase separada y luego perforaba un agujero en otras clases relacionadas para llamarla, resultando en una gran cantidad de clases y métodos inútiles. Esto no es programación orientada a objetos, es claramente programación orientada a la lista de requisitos.
Las razones, en mi opinión, son:
- La capacidad de diseño de la IA para el paradigma de programación orientada a objetos es insuficiente, probablemente debido a la falta de modelado de conceptos del dominio del negocio.
- La IA no sabe si está haciendo código desechable o código para mantenimiento a largo plazo. Carece de orientación arquitectónica y adopta una estrategia perezosa de "hacerlo todo de una vez".
- Falta un andamiaje (scaffolding) amigable para la IA. El proceso de arranque desde cero es bastante difícil para la IA.
- La IA es demasiado conservadora al manejar los requisitos de compatibilidad, lo que lleva a un código hinchado.
El Mito de la Orientación a Objetos
Creo que la IA actualmente no es adecuada para escribir código de programación orientada a objetos (OOP). La OOP requiere una comprensión profunda y capacidad de modelado del dominio del negocio, y la IA aún no puede hacerlo bien. Incluso, de manera bastante ridícula, los humanos tampoco pueden hacerlo fácilmente. Por el contrario, la programación orientada a procedimientos y la programación funcional son más adecuadas para la IA, ya que se centran más en la transformación y el procesamiento de datos, que en el estado y el comportamiento de los objetos.
Si usas orientación a objetos, necesitas que la IA domine simultáneamente los patrones de diseño y la refactorización. Solo así podrá escribir código OOP de alta calidad. Sin embargo, si usas programación orientada a procedimientos y funcional, la IA solo necesita concentrarse en algoritmos y estructuras de datos para producir un código decente.
Entonces, ¿cuál es el beneficio de la orientación a objetos? ¿Encapsulación? ¿Herencia? ¿Polimorfismo? En la era de la IA, estos parecen menos importantes, ya que existen principalmente para escribir menos código y facilitar la división del trabajo en equipo, cosas que a la IA no le importan. Por el contrario, la legibilidad, mantenibilidad y capacidad de prueba del código son clave. Y estas características son más fáciles de lograr mediante la programación funcional y orientada a procedimientos.
Compatibilidad Hacia Atrás Excesiva
La IA es demasiado conservadora con los requisitos de compatibilidad hacia atrás, lo que resulta en un código hinchado e inmanejable. La IA siempre intenta conservar todas las funciones e interfaces antiguas para evitar romper el código existente. Sin embargo, este enfoque a menudo resulta contraproducente, ya que aumenta la complejidad y el costo de mantenimiento del código. A veces, eliminar funciones e interfaces antiguas puede simplificar el código y mejorar el rendimiento. Pero a la IA le cuesta hacer este tipo de compensaciones porque carece de comprensión de los requisitos del negocio y el comportamiento del usuario.
Si la IA cree que todas las exportaciones public deben conservarse, introduce estas interfaces de manera muy casual al crear nuevas funciones, pero en el mantenimiento posterior las trata como tesoros, temiendo eliminarlas por accidente. El resultado es un código cada vez más hinchado, con mayor complejidad y más errores.
Después de intentar guiar a la IA para que use una estrategia de "permitir cambios disruptivos", la mejora fue notable. Esto indica que identificamos el problema correcto. Pero también plantea un nuevo problema: ¿cómo gestionar el riesgo de los cambios disruptivos?
Debemos hacer que la IA comprenda el Principio de la Navaja de Ockham: "Las entidades no deben multiplicarse sin necesidad". Es decir, el código debe ser lo más simple posible, evitando complejidad y redundancia innecesarias. Solo se deben introducir nuevas funciones e interfaces cuando sea realmente necesario. Solo así se puede mantener el código claro y mantenible.
Si la IA no separa las tareas de diseño y codificación, le resultará muy difícil lograr esto.
Conclusión
- Enfatizar el no uso de OOP, cambiando hacia la programación orientada a procedimientos y funcional. Este es un atajo muy crucial que puede mejorar significativamente la calidad y mantenibilidad del código generado por la IA.
- Guiar a la IA para que comprenda el Principio de la Navaja de Ockham, evitando la compatibilidad excesiva hacia atrás y reduciendo la hinchazón del código.
Todavía no tengo claro cómo abordar otros aspectos, como el problema del andamiaje (scaffolding), la orientación arquitectónica, etc.
