La deuda técnica no tiene techo: el código siempre puede empeorar
El ingeniero Zach Kehs publicó el 6 de septiembre de 2026 una reflexión que circula entre desarrolladores: a diferencia de un edificio físico, el software no colapsa por acumulación de capas defectuosas, simplemente se degrada sin límite visible.
👁 115 lecturas
El ingeniero Zach Kehs publicó el 6 de septiembre de 2026 un artículo titulado There’s No Limit to How Bad Code Can Get, cuya tesis central recogió el mismo día el desarrollador Simon Willison en su blog personal: el software, a diferencia de la construcción física, no tiene un punto de colapso natural que obligue a corregir el rumbo.
- Zach Kehs argumenta que el software, a diferencia de la arquitectura física, puede acumular capas de indirección y pérdida de rendimiento indefinidamente sin colapsar.
- Simon Willison recopiló y publicó la cita el 6 de septiembre de 2026 en su blog personal, clasificándola bajo la etiqueta 'technical-debt'.
- La ausencia de un límite físico en el software significa que no existe un mecanismo natural que fuerce la corrección de la deuda técnica acumulada.
«If you continue to add floors and rooms to a building forever, it will collapse. Software faces no such constraint. The code can always get worse. There can always be a new layer of indirection or a reduction in performance.»
- Zach Kehs, There’s No Limit to How Bad Code Can Get
La analogía es directa: un edificio al que se le agregan plantas indefinidamente termina derrumbándose por leyes físicas. El código no obedece ninguna ley equivalente. Puede acumular capas de abstracción innecesarias, parches sobre parches y pérdidas de rendimiento progresivas durante años sin que el sistema «caiga» de forma espectacular. Se deteriora de manera silenciosa y continua.
Willison clasificó la cita bajo la etiqueta technical-debt en su archivo, donde lleva años documentando ideas relevantes para la práctica del desarrollo de software. El post no añade comentario propio más allá de la selección y la fecha.
Qué significa esto para quien construye con IA hoy: los sistemas que integran modelos de lenguaje tienden a crecer rápido: capas de prompts, agentes encadenados, lógica de reintento, cachés intermedias. Ninguna de esas capas provoca un fallo inmediato y visible cuando se diseña mal. La advertencia de Kehs es concreta: la ausencia de un límite físico no es una ventaja, es un riesgo de gestión. Revisar y simplificar la arquitectura de un pipeline de IA con la misma disciplina que se aplica a cualquier base de código es la única forma de evitar que «siempre pueda empeorar un poco más».
Google · Tus fuentesBrilla más alto en tu Google - con un solo clicAñadir a fuentes preferidas →
More on this from FULGOR
noticias·El científico jefe de OpenAI defiende entrenar modelos más potentes como mecanismo de defensa ante la IA peligrosa