La fábula de la tortuga y la liebre tiene una versión nueva en el desarrollo de software, y esta vez se mide en tokens. Cada vez que un sistema con mala arquitectura crece, cada funcionalidad nueva cuesta más caro generarla con IA. La liebre que corrió sin construir bases termina pagando más caro, ya sea por una feature o por el mantenimiento de la deuda técnica. La tortuga que invirtió en arquitectura desde el inicio, no.
En la fábula, atribuida a Esopo (siglo VI a. C.), se relata cómo una tortuga y una liebre deciden hacer una carrera entre ellas. Por supuesto, la liebre salió corriendo, confiada de ganar. La tortuga avanzó sin pausa pero sin prisa. En cierto punto, la liebre ya no veía a la tortuga, por lo que decidió tomar un descanso; total, la tortuga no le ganaría. El final de la historia es que la liebre se quedó dormida y la tortuga terminó ganando la carrera.
El factor común en la mayoría de los equipos de desarrollo es producir: crear las funcionalidades que requieren los diferentes departamentos de las empresas. Cada desarrollador se dice a sí mismo: “luego lo soluciono y lo emprolijo, lo importante es que la funcionalidad quedó pronta y la pueden utilizar”.
Así es como se va acumulando la deuda técnica… TO-DO: aplicar tal o cual patrón… Utilizar una arquitectura distribuida aquí o allá… Encapsular la lógica para seguir el principio DRY (don’t repeat yourself), etc… ¿Quieren saber una realidad incómoda? Ese momento nunca llega. Los departamentos de las empresas no van a dejar de requerir nuevas funcionalidades, y es muy difícil detener al equipo de desarrollo para eliminar deuda técnica mediante refactoring, eliminar dependencias legacy o hacer cambios profundos de arquitectura, entre otros.
Lo que se observa en la práctica es que los sistemas en los cuales no se hace foco en la arquitectura, ni se dan los tiempos para ajustarla, terminan disminuyendo la productividad. Esto lleva a no cumplir con las fechas de entrega de mejoras o nuevas funcionalidades, y a un costo más elevado que al inicio del proyecto. Incluso con el aumento de los ingenieros y desarrolladores, se va estancando la cantidad de líneas de código generadas.
En el libro Clean Architecture, Robert C. Martin lo explica de la siguiente forma: a medida que avanzan las releases, el esfuerzo por funcionalidad sube y la productividad efectiva tiende a cero, aun sumando más ingenieros. El equipo crece, las líneas útiles entregadas se estancan.
Ahora, con el desarrollo asistido o generado directamente con IA, no solo se torna importante saber lo que se debe hacer, sino —más importante aún— cómo hacerlo. Esto tiene al menos dos aristas. La primera ya la mencionamos: sobre una base con arquitectura deficiente, cada funcionalidad consume más tokens que sobre una arquitectura sólida, y eso se paga en cada entrega. La segunda, y menos obvia: hacer un cambio de arquitectura una vez que el sistema ya es un caos tendrá un costo muy superior.
Desde siempre es importante que analistas funcionales, líderes técnicos y gerentes de sistemas expliquen continuamente el proceso de desarrollo a quienes toman las decisiones. Los departamentos no conocen los procesos internos de sistemas, ni cómo una buena decisión de arquitectura temprana puede bajar costos y tiempos de implementar nuevas features a futuro. Si lo entienden, también comprenderán que cuando una implementación toma algo más de tiempo, no se está perdiendo: se está invirtiendo.
El paradigma cambió, y con él, qué significa ir rápido. La liebre cree que velocidad es entregar features ya; la tortuga entiende que velocidad sostenida es invertir en arquitectura para que cada entrega futura sea barata. En la era de la IA, la tortuga no solo gana la carrera: gana en tokens.