luismori.

AI and Engineering Leadership

System Design Engineering Architecture

Extender y mejorar: el diseño que ya tienes es el trabajo

Crear un borrador de código nuevo es barato. La tarea duradera es más antigua: ampliar un diseño que alguien todavía entiende, o mejorarlo hasta que el próximo cambio sea fácil.

21 min de lectura
Extender y mejorar: el diseño que ya tienes es el trabajo

Imagina una pequeña tienda que te encanta. La caja ya ofrece un beneficio: si compras diez artículos o más, el precio baja un diez por ciento.

Una mañana llega una nueva solicitud: cinco dólares de descuento, siempre que el carrito no esté vacío. Un pequeño regalo de bienvenida.

Un asistente puede preparar ese cambio en un minuto. A veces copia toda la lógica de la caja en un segundo archivo. Otras veces mete otra regla en medio de la anterior. Ambas versiones pueden parecer terminadas. Solo una deja la tienda ordenada para el próximo beneficio.

Ese es, en realidad, todo el artículo. En 2026 una persona puede escribir a mano una parte menor de cada cambio. Aun así, el trabajo alrededor de ese cambio acumula más borradores, más revisiones y más maneras de dañar un diseño que ya funciona. Esta es la idea que quiero dejarte: cuando ya existe un diseño y alguien todavía puede explicarlo, empieza por extenderlo. Si la solicitud responde al mismo propósito y la estructura es incómoda, primero mejora la estructura y después extiéndela. Si responde a un propósito distinto, añade una pequeña pieza nueva junto a la anterior. Y reemplaza una pieza solo cuando puedas explicar por qué.

Ese orden es mi conclusión, y la presento como tal. No encontré un artículo que diga, con esas palabras, que extender y mejorar es ahora el trabajo. Las reglas más antiguas que aparecen abajo provienen de fuentes. Convertirlas en un orden predeterminado es mi criterio.

Hay dos artículos anteriores en este sitio que se relacionan con el tema. El plano por encima de los bytes trata sobre especificar y revisar cuando escribir código deja de ser el centro del trabajo. Cuando el código se abarata, la complejidad se desplaza trata sobre estimaciones y planificación. Este artículo aborda la decisión que esos textos dejan abierta. Ya tienes un sistema vivo. ¿Lo extiendes, lo mejoras, añades una pequeña pieza nueva o lo reemplazas?

El mostrador ordenado de una pequeña tienda, con estantes bien acomodados y una pequeña caja de regalo

Cuatro opciones y la primera que conviene probar

Llega un cambio. No empiezas escribiendo. Empiezas preguntando dónde pertenece.

Primero, unas definiciones para que la tabla sea más fácil de seguir. Un commit es una instantánea guardada del trabajo. Un pull request es una solicitud que dice: «por favor, acepta este cambio». Un agente, o asistente de programación, es un programa que prepara borradores de código cuando se lo pides. Un punto de extensión es un lugar que el diseño ya ofrece para incorporar algo nuevo. Un refactor es una mejora de la estructura interna. Lo que ve el cliente sigue siendo igual.

Opción Elígela cuando Cómo se ve el resultado
Comprar o llamar Un producto en el que el equipo ya confía, y que no necesita mantener como propio, ya cumple esta función Usas ese producto. No construyes un duplicado
Extender Alguien puede explicar cómo encaja el nuevo comportamiento en el diseño actual y ya existe un punto de extensión El nuevo comportamiento queda detrás de la interfaz existente. Quienes usan la parte estable no tienen que cambiar nada
Mejorar El comportamiento pertenece aquí y la estructura actual obligaría a introducir un caso especial, una copia o cambios desordenados en todo el archivo Una mejora que conserva los resultados actuales, seguida de la pequeña extensión. Las comprobaciones anteriores siguen pasando
Componer Integrar el cambio en el programa anterior haría que cumpliera peor su función actual Una pequeña pieza nueva. Su salida alimenta a la anterior, o viceversa
Reemplazar Nadie conserva ya la comprensión de esta parte, o un ajuste local más cuesta más que un nuevo diseño de alcance acotado Un nuevo diseño para esa parte, desarrollado junto a la solución anterior mientras esta todavía tiene usuarios

Prueba las opciones en este orden. Compra si ya existe un producto mantenido que encaja. De lo contrario, intenta extender, luego mejorar, después componer y, por último, reemplazar. Detente en la primera opción que encaje y anota por qué descartaste las anteriores.

Dos preguntas ayudan a mantener el criterio.

¿Alguien todavía puede explicar la historia? Alguien del equipo debería poder decir por qué esta parte tiene esta estructura y dónde pertenece un caso nuevo. Peter Naur llamó a esa historia la teoría. Vive en las personas. Un archivo puede dar pistas sobre ella, pero no puede contenerla por sí solo. Si un compañero conoce la historia, apréndela antes de tocar nada. Si nadie la conoce, estás poniendo parches, en el sentido de Naur, y es válido crear un diseño nuevo para esa parte.

¿El próximo cambio es más fácil? Después de extender o mejorar, el diseño debería ser más fácil de modificar otra vez. La segunda ley de Lehman dice que la complejidad aumenta a menos que alguien trabaje para contenerla. Una extensión que necesita una advertencia como «no uses esto con el otro modo» es una mejora que pospusiste. Componer y reemplazar son salidas del ciclo. No las arrastres de vuelta a él.

Una línea más, y es mi criterio, no el resultado de un estudio. Los asistentes trabajan con soltura cuando el punto de extensión es evidente. Son igual de hábiles para inventar una segunda copia cuando ese punto está oculto. Tu trabajo es elegir la opción antes de que el asistente llene la página. Después, la revisión plantea una pregunta más acotada: ¿este cambio corresponde a la opción que elegimos?

flowchart TD
  Start["Se solicita un cambio"] --> Owned{"¿Un producto mantenido ya cumple esta función?"}
  Owned -- "Sí" --> Buy["Comprarlo o llamarlo"]
  Owned -- "No" --> Theory{"¿Alguien todavía conserva la teoría?"}
  Theory -- "Sí, tú" --> Fit{"¿Cómo encaja el cambio?"}
  Theory -- "Un compañero" --> Learn["Aprender la teoría y continuar"]
  Learn --> Fit
  Theory -- "Nadie" --> Replace["Reemplazar esta parte"]
  Fit -- "Existe un punto de extensión" --> Extend["Extender"]
  Fit -- "Misma función, estructura incómoda" --> Improve["Mejorar y después extender"]
  Fit -- "Función distinta" --> Compose["Componer una pequeña pieza nueva"]
  Fit -- "Otro incremento cuesta más" --> Replace
  Extend --> Easier{"¿Es más fácil volver a cambiar este diseño?"}
  Improve --> Easier
  Easier -- "Sí" --> Ship["Publicar"]
  Easier -- "No, misma función" --> Improve
  Compose --> Ship
  Replace --> Ship
  Buy --> Ship

La mayor parte del trabajo siempre fue cambiar

Meir M. Lehman pasó años observando software que permanece en uso. En un artículo de septiembre de 1980 trata el mantenimiento como todo cambio posterior a la primera instalación, una categoría mucho más amplia que la corrección de errores. Menciona una distribución «generalmente aceptada» del gasto en programación de Estados Unidos en 1977: alrededor de un 70 por ciento para mantenimiento y un 30 por ciento para desarrollo nuevo. Es una estimación de la comunidad de ese período, no una encuesta que él haya realizado. Dejémosla en 1977. No es una buena referencia para los costos actuales.

Lo que vale la pena conservar es el argumento que la rodea. Cambiar, eliminar y extender partes de un programa vivo no es una distracción del trabajo. Es el trabajo. Dos de sus leyes siguen siendo importantes cualquier martes: los programas que modelan actividades humanas reales deben seguir adaptándose o quedan obsoletos. Y su complejidad aumenta a menos que alguien trabaje para contenerla.

Publicar la primera versión inicia el trabajo. Cada cambio posterior encaja en el diseño, lo mejora o dificulta el siguiente cambio. Los asistentes no inventaron esa disyuntiva. Solo hicieron más fácil saltarse el camino intermedio y colocar un segundo diseño junto al primero.

Más borradores, menos entregas terminadas

Un borrador rápido del regalo de bienvenida te dice qué tan rápido aparecieron las palabras. No dice nada sobre el estante al que pertenece el regalo. Los estudios muestran precisamente esa separación. Producir parte del texto se abarató. El cuidado a su alrededor sigue siendo necesario. Encontrarás análisis más extensos en Cuando el código se abarata y ¿Está generando la IA un mundo de código basura?.

En un ejercicio nuevo, el borrador sí se produjo más rápido. Con GitHub Copilot, los participantes construyeron un servidor web de ejemplo 55.8 por ciento más rápido (Microsoft Research, febrero de 2023; arXiv:2302.06590). El artículo mide esa velocidad. Si esos servidores eran más fáciles de extender después queda fuera de su alcance.

En código conocido, en una primera medición puntual, ocurrió lo contrario. El ensayo de METR (arXiv:2507.09089, publicado el 10 de julio de 2025) pidió a 16 desarrolladores experimentados que resolvieran 246 issues reales en repositorios que conocían bien. Cuando se permitió el uso de IA, las tareas tomaron 19 por ciento más de tiempo. Los autores lo describen como una medición puntual de las herramientas disponibles a principios de 2025. Otros equipos, otros editores y modelos posteriores quedan fuera de esa conclusión.

Luego está el embudo a gran escala. La revisión de septiembre de 2026 del NBER Working Paper 35275, Writing Code vs. Shipping Code, estudia a más de 500,000 desarrolladores de GitHub. Es un documento de trabajo compartido para discusión, no revisado por pares. Con agentes autónomos, los cambios guardados adicionales alcanzan alrededor de 240 por ciento, pero esa cifra se reduce a aproximadamente 80 por ciento más de proyectos y solo alrededor de 30 por ciento más de releases publicadas. Aparecieron más aplicaciones nuevas, sin un aumento en el uso total. Los autores hablan de una conexión débil. La programación se acelera. El trabajo humano posterior sigue marcando el ritmo. (El 26 de septiembre de 2026, la página pública todavía mostraba un resumen anterior. Estas cifras provienen del PDF de septiembre de 2026).

El embudo se estrecha: cambios guardados frente a lo publicado

Cambios guardados (commits)+240%
Proyectos nuevos+80%
Releases publicadas+30%

NBER Working Paper 35275, revisión de septiembre de 2026. La lectura sencilla: escribir más barato llena la parte superior del embudo. La revisión, la integración y la publicación deciden qué sale de él.

La confianza quedó rezagada frente a la actividad. La encuesta anual de DORA de 2025, realizada entre casi 5,000 profesionales (13 de junio–21 de julio de 2025), indica que 90 por ciento usa IA en el trabajo y más de 80 por ciento se siente más productivo, pero 30 por ciento tiene poca o ninguna confianza en el código generado. La adopción se relaciona con un mayor volumen de entregas y una menor estabilidad. Son patrones observados en la encuesta. (Una nota anterior de DORA de 2025 reportó un empeoramiento en las entregas, incluida una probable caída en su volumen. El artículo sobre estimaciones cita esa nota. Este artículo usa el informe anual). La encuesta de Stack Overflow de 2025 (49,009 respuestas, 29 de mayo–23 de junio de 2025) muestra algo parecido: 84 por ciento usa o planea usar herramientas de IA, 51 por ciento de los profesionales las usa a diario y hay más personas que desconfían de su precisión (46 por ciento) que personas que confían en ella (33 por ciento).

Simon Willison resume la perspectiva de quien ejerce la profesión en una línea: el código nuevo es casi gratis; el buen código no lo es (Escribir código es barato ahora, consultado el 26 de septiembre de 2026). La nota de Addy Osmani del 4 de diciembre de 2024 sobre el «problema del 70 por ciento» es una observación práctica de la misma diferencia. Ambos son juicios. Andrej Karpathy, el 2 de febrero de 2025, describió el extremo de ese hábito: aceptar los cambios, saltarse los diffs y dejar que el código crezca más allá de lo que entiendes. Dijo que eso no estaba tan mal para proyectos desechables de fin de semana, aunque no era realmente programar. La salvedad es suya.

Un insumo más barato puede aumentar el uso total. Esa imagen es una analogía tomada de William Stanley Jevons, The Coal Question (1865). La evidencia sobre software es el artículo de NBER mencionado arriba. El trabajo escaso es revisar, integrar las piezas y elegir dónde pertenece el nuevo comportamiento. Ese cuidado es la parte de «hacer más» de la idea.

Puedes saltarte una línea. Aun así, deberías poder leerla.

Se habla de dos futuros como si fueran uno solo. Terminan en tiendas diferentes.

En el primero, las personas dejan de leer las notas. El texto es un residuo, como las instrucciones de máquina que la mayoría nunca abre. La nota de Karpathy de febrero de 2025 presenta ese futuro, ya puesto en práctica: «olvidar que el código siquiera existe». Aceptar el diff. Dejar que el programa crezca más allá de lo que se puede comprender. Simon Willison, el 19 de marzo de 2025, conserva el nombre. Vibe coding significa construir con un modelo y saltarse la revisión de lo que escribe. Para el software que él incluiría en un commit, aplica el criterio contrario: no incluirá en un commit algo que no pueda explicarle con exactitud a otra persona.

En el segundo futuro, todavía puedes leer las notas y, a menudo, no necesitas revisarlas por completo. La estructura te dice qué puedes ignorar. El prefacio de 1985 de Structure and Interpretation of Computer Programs ya aspiraba a ese tipo de lector. Los programas, dice, deben escribirse para que las personas los lean y solo incidentalmente para que las máquinas los ejecuten. Un buen lector sabe qué no necesita leer y cómo cambiar el programa conservando su espíritu y estilo.

Ambos futuros están disponibles ahora. Los cambios guardados aumentan. La confianza es limitada. El artículo de NBER cuenta commits, proyectos, releases y uso. No dice nada sobre qué tan cuidadosamente leyó alguien un diff. Saltarse la lectura es una inferencia, y coincide con la forma en que Karpathy describió su propia práctica de fin de semana. Deuda de comprensión es el nombre que este sitio da a los cambios integrados que nadie puede explicar. Así se ve el primer futuro cuando gana.

El futuro que yo construiría es el segundo. Te saltas líneas porque la estructura es clara, y todavía puedes leer cuando ese atajo no basta. Un único lugar identificado para los descuentos significa una sola regla que cambiar. Una mejora antes de implementar la funcionalidad mantiene válida esa lista de partes que puedes omitir. Una segunda copia de las reglas de la caja no pasa la prueba. Ahora tienes que leer ambas y ninguna indica cuál es el diseño real.

Las predicciones sobre perder la capacidad de leer, o sobre que la lectura llegue a cero, quedan fuera de estos estudios. Lo que muestran es que se producen más notas. La legibilidad sigue siendo una elección, y sigue estando en tus manos.

En pocas palabras, sobre los hombros de quienes vinieron antes

Cada una de estas personas defiende una opción. Y ninguna llega al extremo de la caricatura.

Extiende mientras alguien todavía conozca la historia. En 1985 Peter Naur escribió que el verdadero activo es la teoría que tienen los programadores sobre cómo el programa se relaciona con el mundo. El texto es solo un rastro. En su historia sobre un compilador, un segundo equipo tenía el código fuente y las notas, y aun así propuso cambios que ignoraban la estructura existente. Cuando la teoría ha muerto, dice, hay que resolver el problema de nuevo. Esa es la salida de reemplazar.

Mejora y deja intacto lo que ven las personas. El 6 de abril de 2000, Joel Spolsky calificó la reescritura desde cero de un producto que funciona como el peor error estratégico que puede cometer una empresa de software. Repara el desorden interno mientras conservas el comportamiento del que dependen las personas. Una frase de Kent Beck, citada por Martin Fowler en 2015, resume el paso en una oración: haz que el cambio sea fácil y luego haz el cambio fácil. Un refactor modifica la estructura interna para que el software sea más barato de cambiar, mientras lo que ven los usuarios permanece igual.

Añade en un punto de extensión. El principio de Bertrand Meyer de 1988 dice que un módulo puede estar abierto a la extensión y cerrado al mismo tiempo. Cerrado significa que otros pueden apoyarse en una descripción estable. La columna de Robert C. Martin de 1996 traza la pauta práctica: satisface un nuevo requisito añadiendo, en lugar de editar lo que ya funciona. Jeremy Miller puso un límite en 2008: trátalo como una dirección, no como una meta, o inventarás puntos de extensión para cambios que nunca llegarán.

Compón cuando la función sea realmente nueva. La regla de extensibilidad de Eric Raymond pide dejar espacio para funciones futuras sin descartar la arquitectura, y rechaza las funcionalidades que nadie necesita todavía. Doug McIlroy ofrece la salida: «Para realizar una función nueva, construye desde cero en lugar de complicar programas anteriores añadiéndoles funcionalidades nuevas». Si es la misma función, extiende. Si es distinta, crea un pequeño programa nuevo.

Compra, haz crecer y reemplaza solo lo que deba irse. Fred Brooks pone la compra en primer lugar. La forma más radical de construir software es evitar construirlo. Hazlo crecer a partir de un esqueleto que funcione, de modo que cada función nueva surja de lo que ya está en ejecución. Dan McKinley (2015) dice lo mismo sobre las herramientas: añade una cuando cambie tus probabilidades de resolver el problema. Cuando una parte realmente debe irse, el patrón strangler fig de Martin Fowler hace crecer el nuevo comportamiento en el borde hasta que la ruta anterior pueda retirarse. Y Jeff Atwood (2007) aporta la cautela que hay detrás de cada opción: cada línea que conservas debe leerse y mantenerse. Una segunda copia de las reglas de la tienda no es un regalo.

Conserva la tienda que tienes

Este orden deja espacio para añadir. El regalo de bienvenida sigue siendo algo nuevo. La disciplina está en decidir dónde va. También deja espacio para empezar algo nuevo. Un problema que todavía no tiene una historia debe hacer crecer un diseño, un esqueleto funcional a la vez.

Deja sin construir los futuros puntos de extensión hasta que un cambio real resulte incómodo. Y te deja en condiciones de leer las reglas. El hábito de fin de semana de Karpathy es una decisión deliberada de leer menos para trabajos desechables. Convertir esa omisión en la opción predeterminada, sin una estructura que la haga segura, es la versión costosa.

Así que extiende los diseños que ya existen. Mejóralos cuando una extensión no sea más que un parche. Compón una pieza nueva cuando el programa anterior tendría que cambiar de función. Reemplaza una parte cuando su historia se haya perdido. Y mantén todo lo bastante legible como para que, a menudo, no sea necesario leerlo por completo.

Los estudios dicen algo más acotado que los eslóganes. Una tarea delimitada se hizo más rápido. Una medición puntual sobre código conocido fue más lenta. Los cambios guardados aumentaron más que las releases publicadas. Las reglas de diseño indican qué hacer con esa diferencia.

Fuentes

Consultadas el 26 de septiembre de 2026, salvo indicación contraria. Las cifras de documentos de trabajo y encuestas llevan fecha porque pueden cambiar.