Si antes seguir buenas prácticas en desarrollo te daba 2 o 3 veces más velocidad, ahora tranquilamente puedes estar trabajando 10 o 20 veces más rápido. Porque la IA, como un desarrollador nuevo (pero muy rápido), entiende mejor, propone mejor y modifica con más precisión cuando el sistema está bien estructurado. En cambio, si tu código es un lío acoplado, sin tests ni capas, ni los desarrolladores ni las máquinas se aclaran. Te bloqueas tú, y se bloquea la IA.

Una arquitectura desacoplada por capas, donde cada parte del sistema tiene una responsabilidad clara (presentación, dominio, persistencia), permite a la IA entender el propósito de cada módulo, hacer cambios localizados y mantener la coherencia general. Lo mismo con funciones pequeñas y específicas, con nombres que expresan exactamente lo que hacen: cuanto más clara es la intención, más fácil es para la IA generar, refactorizar o extender el comportamiento sin romper otras partes.

Otro punto clave es el uso de vocabulario de negocio en el código, en las variables, en la base de datos. Cuando hablamos en el idioma del producto, la IA también puede entender mejor qué queremos. Si le pedimos “aplica un descuento del 10% a clientes VIP” y el modelo encuentra Client, DiscountPolicy, y isVip, todo encaja. Si en cambio está todo mezclado bajo nombres genéricos, la IA se pierde... como cualquier desarrollador nuevo.

Los tests automáticos y fiables siempre han sido una batalla cultural. Pero ahora tienen aún más razón de ser: permiten experimentar con IA sin miedo. Si tienes una suite sólida, puedes dejar que la IA haga cambios y ver al instante si has roto algo. Más aún, la IA también puede ayudarte a escribir mejores tests... si tienes la arquitectura adecuada y el sistema es testeable desde el diseño.

A esto se suman otras buenas prácticas: documentación mínima pero clara, uso de frameworks estándar y librerías de terceros bien conocidas, separación entre dominio y framework. Todo eso da más contexto a la IA para moverse con confianza por tu base de código. Y cuando usas herramientas como Cursor, lo notas: te proponen cosas más útiles, más rápidas, más precisas.

Así que si eres CTO o tech lead, plantéate esto con honestidad: ¿en qué situación está vuestro código hoy? ¿Tienes una base sólida, limpia, bien estructurada, donde tu equipo puede iterar 10 o 20 veces más rápido con IA? ¿O estás atrapado en una base enredada donde todo cuesta, y ni el mejor modelo te puede ayudar? Lo que antes era una cuestión de elegancia, ahora es directamente una cuestión de ventaja competitiva.

·Ver comentarios en LinkedIn

También puede interesarte

40 clics para pagar dos horas de aparcamiento

Un parquímetro me ha recordado por qué contar los clics y los segundos que le cuesta a tu usuario completar una tarea es clave al diseñar un producto.

5 comportamientos que definen a un Product Engineer

La IA hace que programar sea rápido. El reto que queda es entender el problema, plantear una buena arquitectura y fasear con criterio.

Iterando el prototipo en vivo mientras los usuarios lo prueban

Siempre he hecho tests de usuario para diseñar mejor. Lo que no había vivido antes era poder implementar el feedback en la propia sesión. Lo que antes tardaba semanas, ahora sale en el día.