Un sitio web global lleva siete años en producción. Ha pasado por tres versiones mayores del framework, dos migraciones de Node y un rediseño completo de sus plantillas principales. El presupuesto anual reserva alrededor de un 18% para mantenimiento, que es una cifra defendible y que nadie discute en un comité.
Lo que vive el equipo de interfaz es otra cosa. Más de la mitad de cada iteración se va en lidiar con lo que ya existe: averiguar cuál de las cinco tarjetas hay que tocar, comprobar qué se rompe al mover un espaciado, repetir en cuatro sitios la corrección de contraste que solo se hizo en uno. Eso no figura como mantenimiento en ningún tablero, porque el desarrollador que tarda once días en un carrusel que debería costar tres imputa a la campaña que lo pidió.
Hay dos costes mezclados ahí, y conviene separarlos porque solo uno de los dos se puede pagar.
Deuda es la que se contrae a sabiendas
La metáfora del endeudamiento se usa mal casi siempre y conviene devolverle su sentido estrecho. Endeudarse es una decisión que alguien toma: se pide prestado tiempo, se entrega antes de lo que se podría entregar bien, y se devuelve después con intereses. Los intereses son lo que cuesta de más cada cambio posterior mientras ese código siga como está. En ningún momento fue permiso para escribir mal y prometer arreglarlo luego.
Yo uso una definición operativa que descarta casi todo lo que se llama deuda en las reuniones. Hay deuda cuando existen tres cosas: un acreedor, es decir, quién va a sufrir el interés y en qué trabajo concreto; un importe, cuánto cuesta ese interés por iteración; y un vencimiento, en qué versión se devuelve. Si falta alguna de las tres, lo que hay no es deuda.
Un caso de deuda de verdad, de las que se firman sin remordimiento: hace falta un componente de formulario que el sistema no tiene, quedan cinco semanas para abrir un mercado nuevo y se decide implementarlo dentro del módulo que lo necesita, acoplado y sin pruebas, con la promoción al sistema de diseño puesta en el trimestre siguiente. Está anotado, tiene dueño y tiene fecha. Se puede adelantar, aplazar o dejar vencer, pero se sabe que está.
Una deuda así es cara y aun así es el problema fácil. Está enumerada en algún sitio, se puede estimar y se puede negociar cuándo se devuelve. Un equipo cuyo problema sea ese tiene un problema de calendario.
El resto no se contrajo, se acumuló
El otro coste no cumple ninguna de las tres condiciones. Nadie lo decidió, nadie lo anotó y no hay nada que devolver porque nunca se pidió prestado. Lo llamo degradación para no llamarlo deuda, y la diferencia no es de vocabulario: la deuda aparece cuando el equipo va con prisa y hace algo mal a propósito, y la degradación aparece cuando el equipo entrega bien y a tiempo, una y otra vez, sobre una arquitectura que no estaba preparada para lo que se le iba a pedir.
Merece la pena detenerse en eso porque va contra la intuición. El desarrollador que duplica la tarjeta para la campaña de rebajas está haciendo lo correcto en su contexto: tiene nueve días, la tarjeta compartida la consumen catorce vistas, es la semana previa al pico de tráfico del año y tocar código común significa una revisión cruzada con dos equipos que no van a llegar. Copiar es lo prudente. El fallo no está en su decisión, está en que el sistema no le ofrecía ninguna opción que fuera barata y correcta a la vez. Multiplica eso por seis campañas al año durante siete años y salen cuarenta y dos duplicaciones, cada una impecable en su momento, que suman un producto donde ya nadie sabe cuántas tarjetas hay.
Esto es lo que hace que la palabra mantenimiento engañe a quien aprueba el presupuesto. Suena a reparar lo que se ha roto, y la mayor parte del trabajo que entra bajo esa etiqueta es funcionalidad nueva construida dentro de algo que ya estaba construido. La calidad de lo que ya estaba construido es lo que decide el precio de todo lo que venga detrás.
Dónde se acumula, en la capa de interfaz
La capa de presentación se degrada más deprisa que el resto del sistema y tiene una razón mecánica. TypeScript tiene un compilador que avisa del código muerto; una hoja de estilos no. En un catálogo de miles de plantillas nadie puede borrar un selector con garantías, así que la única operación segura sobre el CSS es añadir. El volumen crece de forma monótona durante años y cada oleada de arquitectura deja su capa: la de BEM, la de los mixins de SCSS, la de las utilidades, la de los estilos encapsulados del framework. Conviven las cuatro y ninguna se retira del todo.
Sobre esa base, los dos focos que más veo pesan de forma desigual y no se tratan igual.
No tener una capa de tokens propia es lo más caro de sufrir y lo más barato de arreglar. Cuando el valor de marca está escrito literalmente en trescientos sitios, cualquier cambio transversal se convierte en una búsqueda y reemplazo con revisión visual manual. Un ajuste de contraste para cumplir accesibilidad, un modo oscuro, una variante de marca por mercado: todos cuestan un trabajo lineal en el tamaño del código, y no se automatiza del todo porque hay que decidir caso por caso si ese gris era el gris de borde o el de texto secundario.
Los componentes acoplados al dominio son lo contrario: más caros de arreglar y más lentos en degradarse. Una tarjeta que sabe qué es un producto, llama al servicio de precios y decide por su cuenta el formato de moneda no vale para el checkout, ni para la lista de deseados, ni para los resultados de búsqueda. Se copia. A los tres años hay cinco que se parecen y divergen, y cada corrección de accesibilidad hay que hacerla cinco veces, mal, y en la quinta ya nadie se acuerda de que existía.
Mi estimación, que doy como estimación de campo y no como dato publicado, es que en un producto de este tamaño sin librería propia y sin capa de tokens, entre el 40% y el 60% del tiempo del equipo de front se va en absorber degradación. La mitad alta de la horquilla corresponde a productos con ciclos de campaña cortos y recurrentes, que son los que menos margen dejan para hacer las cosas de otra manera.
La generación asistida no inventa degradación, acelera la que ya hay
Aquí es donde el cálculo ha cambiado en los dos últimos años, y no en la dirección que se suele contar. El término vibe coding, que acuñó Andrej Karpathy en 2025, describe una forma de trabajar en la que uno acepta el código generado sin leerlo entero y se guía por si el resultado funciona. Para un prototipo desechable es razonable. En la capa de interfaz de un producto de siete años tiene tres efectos que se suman.
El primero es que el modelo escribe a partir del contexto que ve. Si en el repositorio hay cinco tarjetas divergentes, produce la sexta, y la produce parecida a lo que más se repite, no a la arquitectura que alguien tenía en la cabeza. Un generador busca encajar con el código existente, y en un producto degradado el código existente es justo el problema. Cada iteración amplía el material del que aprende la siguiente.
El segundo es económico, y es el que más se pasa por alto cuando se habla de productividad. Escribir un componente desde cero costaba dos días, y esa fricción hacía que alguien, en algún momento, preguntase si aquello ya existía. La pregunta no la sostenía el gobierno del sistema de diseño ni la disciplina del equipo: la sostenía el coste. Cuando generar un componente pasa a costar cuarenta segundos, desaparece el único freno a la duplicación que estaba funcionando de verdad, y lo que queda es una disciplina que en la mayoría de los equipos no estaba escrita en ninguna parte porque nunca hizo falta escribirla.
El tercero está en la revisión. Un componente generado se revisa contra el criterio de si funciona: pasa las pruebas, la captura se ve bien, se integra. La pregunta que no se hace es la de pertenencia. Si ese componente debía existir, de qué capa consume, qué contrato cumple, quién lo mantiene cuando cambie la marca. Eso no lo contesta un test ni un ojo entrenado, porque la respuesta no está en el código que se revisa sino en el sistema entero.
Los tres juntos dan lo que uno esperaría: el volumen crece, el contexto empeora, la generación siguiente parte de un contexto peor y produce más volumen. La velocidad de la primera iteración es real y es la que se ve en la demostración. El coste sale repartido en las cuarenta siguientes, en trozos demasiado pequeños para que nadie los sume.
Lo que sí funciona es dejar de tratar la arquitectura como conocimiento tácito y convertirla en algo que se pueda leer. Un modelo trabaja bien cuando la dirección está en el contexto que recibe: los tokens como archivo de datos y no como convención oral, reglas de lint que rompen la compilación ante un hexadecimal literal dentro de un componente, un archivo de reglas de composición en la raíz del repositorio, pruebas de regresión visual que detectan que la tarjeta nueva se parece demasiado a una que ya estaba. Un documento de arquitectura en Confluence no sirve para esto, porque no lo lee el modelo y tampoco lo lee el desarrollador que tiene nueve días de plazo.
Conviene decir dónde la generación asistida es muy buena, porque es justo el otro coste. Pagar deuda anotada es trabajo con especificación: renombrar trescientos usos de un token, escribir el codemod de una migración mayor, extraer un componente acoplado a una capa agnóstica siguiendo un patrón que ya existe. Ahí rinde por encima de lo que rendía un equipo hace tres años. Frenar la degradación es lo contrario: consiste en decir que no a código que funciona, y eso no se delega, ni en una máquina ni en nadie que no tenga autoridad sobre la arquitectura.
Tres números antes de decidir nada
Cualquier plan que no empiece por medir es una opinión. Hay tres cifras que se sacan en una tarde y valen más que cualquier estimación de consultoría.
Cuántos valores de color literales distintos hay en el repositorio, frente a cuántos define la identidad de marca. La distancia entre los dos números es el tamaño del problema de tokens, y suele haber uno o dos órdenes de magnitud.
Cuántos componentes distintos pintan la misma pieza visual. Se cuenta a mano sobre las cinco piezas que más aparecen: tarjeta, botón, campo de formulario, modal y listado. Esa es la medida del acoplamiento al dominio.
Cuánto tarda en producción un cambio de un solo valor de marca, desde que se aprueba hasta que está desplegado en todos los mercados. Este es el número que entiende un director, porque no habla de código sino de plazo, y es el que convierte una conversación de arquitectura en una conversación de negocio.
Lo que haría: dos velocidades sobre el mismo equipo
La forma de intervenir que defiendo separa el trabajo en dos vías con ritmos distintos. Una vía corta, que atiende el día a día, las campañas y lo que hay comprometido con negocio. Y una vía larga, que construye la arquitectura nueva y va sustituyendo la vieja por debajo, sin proyecto de migración y sin fecha de corte.
Esto tiene nombres, ninguno del todo asentado. La idea de que las capas de un sistema cambian a velocidades distintas y no hay que tocarlas al mismo ritmo se llama pace layering. La mecánica de ir sustituyendo lo viejo desde dentro, sin fecha de corte, es la higuera estranguladora, que crece alrededor del árbol viejo hasta que se sostiene sola. También se habla de desarrollo a dos velocidades, aunque esa versión suele entenderse como dos equipos separados, que es justo lo que no funciona. El nombre importa menos que las reglas de operación.
Aplicado a la capa de interfaz, el orden que sigo es tokens primero, con la implementación heredada consumiéndolos por debajo, de modo que el CSS antiguo siga funcionando pero ya lea del sitio nuevo. Después los primitivos agnósticos, y el acoplamiento al dominio se resuelve por composición en la capa de arriba, nunca dentro del componente.
Lo que hace que las dos vías funcionen, más que el plan de sustitución, son cuatro reglas de operación:
La capacidad de la vía larga se reserva, no se pide. Un porcentaje fijo del sprint, entre el 20% y el 25%, comprometido igual que cualquier otra entrega. En cuanto hay que justificarla cada quince días, desaparece en el primer trimestre con presión.
Las dos vías las hace la misma gente, rotando. Si la vía larga es un equipo aparte, produce una librería técnicamente correcta que no adopta nadie, porque nadie de los que la construyeron ha sufrido el plazo de nueve días.
La vía corta no arregla lo viejo, pero tampoco lo amplía. Todo lo que toque sale consumiendo lo nuevo. Esta es la regla que hace avanzar la sustitución sola: la vía larga construye la pieza, y la primera campaña que pase por esa zona es la que la pone en producción.
La vía larga entrega en cada iteración, nunca en una rama larga. Si algo tarda tres meses en llegar a producción, no es vía larga, es un proyecto paralelo con otro nombre.
La alternativa que descarto es precisamente esa, la librería nueva construida limpia en paralelo mientras el producto sigue con la antigua. La descarto por una razón que se repite en todos los casos que conozco: el producto no se detiene. Mientras se construye la librería limpia, las campañas siguen saliendo sobre la antigua, y a los dieciocho meses hay dos sistemas vivos en lugar de uno viejo. La migración que iba a ser el último paso acaba siendo un proyecto del tamaño del original, y llega cuando ya nadie recuerda por qué se aprobó.
El precio de las dos velocidades hay que decirlo en la reunión donde se aprueba, no después. La vía corta entrega entre un 20% y un 25% menos de lo que entregaría si se le diera todo el equipo, y eso se nota desde el primer mes mientras que el retorno tarda tres o cuatro trimestres en verse. Durante ese tiempo conviven dos formas de escribir interfaz y el equipo tiene que saber en cuál está escribiendo cada vez, que es exactamente la clase de ambigüedad que produce la degradación. Eso se compensa con reglas ejecutables y no con formación: si una capa está congelada, la compilación tiene que fallar cuando alguien escriba en ella.
El límite de validez es la continuidad del criterio. Esto se sostiene si alguien con autoridad sobre la arquitectura sigue ahí todo el recorrido y puede rechazar el atajo cuando llegue la campaña de diciembre, que va a llegar. Si esa figura se disuelve a mitad de camino, lo que queda es una quinta capa encima de las cuatro anteriores y habría salido más barato no empezar. En un producto que no vaya a pasar de tres años de vida, o en un equipo pequeño que cabe en la misma conversación, tampoco compensa: ahí la coherencia la sostiene la memoria de la gente y basta con prohibir los hexadecimales dentro de los componentes.
La pregunta con la que distingo un coste del otro la hago siempre en la primera sesión: de esto que llamáis deuda, ¿alguien puede decirme cuándo se contrajo y qué se acordó devolver? Si hay respuesta, hay un plan de pagos y la conversación es de planificación. Si nadie sabe contestar, no hay deuda que devolver: hay una arquitectura que nunca se decidió, y eso no se paga en una iteración, se sustituye a lo largo de varias.