¿Qué es YAGNI?
Cultura de ingeniería y práctica de software
YAGNI son las siglas de "You aren't gonna need it" (no vas a necesitarlo). Es un principio de diseño de software que establece que no se debe construir una funcionalidad, abstracción o punto de extensión hasta que exista una necesidad real y presente. La idea surgió del Extreme Programming y aleja a los equipos del diseño especulativo. No se trata de ser descuidado ni de tener poca visión de futuro. Se trata de mantener el software simple ahora para que pueda cambiar con mayor facilidad cuando el futuro finalmente llegue.
Revisado por Jackie, Head of Learning & Development, Levellers - Última revisión: 8 de junio de 2026
Qué significa esto
YAGNI es el permiso cultural que muchos ingenieros necesitan cuando sienten la tentación de construir para futuros imaginarios. En lugar de preguntarse "¿qué podría necesitar este sistema algún día?", la pregunta es "¿qué sabemos que necesitamos ahora?". Suena casi demasiado simple, y eso es parte de la razón por la que la frase ha perdurado.
El principio es directo porque la sobreconstrucción es habitual. Los equipos suelen añadir opciones, ganchos, roles, modelos de datos genéricos o arquitectura "para más adelante". Ese momento puede llegar, pero con igual frecuencia no llega. Mientras tanto, todos pagan el coste de mantener código que hoy no hace nada útil.
YAGNI no significa fingir que el futuro no existe. Significa negarse a complicar el presente más de lo necesario basándose en suposiciones.
Por qué importa
YAGNI importa porque el software está lleno de tentadores "quizás". Quizás necesitemos cinco proveedores de pago. Quizás dividamos esto en muchos servicios pequeños. Quizás los clientes quieran flujos de trabajo personalizados, permisos avanzados, complementos, plantillas e importación masiva. Una cabeza llena de "quizás" puede convertir un producto modesto en un almacén de funcionalidades sin demostrar.
Eso tiene consecuencias prácticas. El código adicional hay que revisarlo, probarlo, explicarlo, protegerlo, monitorizarlo y modificarlo. Aunque nadie use la funcionalidad, el equipo sigue necesitando entender la maquinaria que la rodea. El software se vuelve más pesado antes de volverse más inteligente.
Para líderes y responsables de producto, YAGNI es valioso porque protege la velocidad de aprendizaje. Desplaza el esfuerzo desde futuros imaginados hacia lo siguiente que el equipo puede realmente entregar, observar y mejorar. En un producto joven o en un mercado cambiante, esa suele ser la diferencia entre el impulso y el estancamiento.
Cómo funciona
El origen de la frase
YAGNI surgió del Extreme Programming, conocido habitualmente como XP, a finales de los años noventa. Martin Fowler sitúa la frase en una conversación temprana entre Kent Beck y Chet Hendrickson en el proyecto Chrysler C3. El eslogan se afianzó porque era memorable, un poco irreverente y exasperantemente eficaz.
Se sitúa junto a otra máxima de XP: "Haz la cosa más simple que pueda funcionar". Juntas, estas ideas animan a los equipos a resolver el problema que realmente está sobre la mesa, no el problema más grande y atractivo que podría aparecer más adelante.
Por qué esperar suele ser más barato
El principio parece conservador, pero en realidad trata de economía. Construir algo antes de tiempo genera al menos tres costes.
Primero, está el coste directo de construcción. Alguien tiene que diseñarlo, codificarlo, probarlo y explicarlo.
Segundo, está el coste de la demora. El tiempo dedicado a construir una funcionalidad futura es tiempo que no se dedica a entregar lo que los usuarios necesitan ahora. Un equipo puede estar muy ocupado y aun así llegar tarde a la parte valiosa.
Tercero, está el coste de mantenimiento. Cada rama, clase, configuración e interfaz adicional hace que la base de código sea más difícil de entender. Aunque esa funcionalidad futura nunca se active, sigue ocupando espacio en la cabeza de las personas. Fowler lo enmarca como el coste de cargar con complejidad extra, y es una de las razones por las que YAGNI va más allá de simplemente entregar más rápido.
Cómo YAGNI sobrevive al contacto con la realidad
La objeción habitual es obvia: ¿y si el futuro realmente llega? ¿Y si lo que se omitió resulta ser necesario después de todo?
Puede ocurrir. YAGNI no es una promesa de que esperar siempre es gratuito. Es un juicio de que el diseño especulativo suele costar más de lo que ahorra, siempre que el equipo mantenga el código fácil de cambiar. Por eso YAGNI depende del refactoring, es decir, de mejorar la estructura interna del código sin cambiar lo que los usuarios ven. También depende de las pruebas, de la integración continua y de una cultura que trate el diseño como algo que evoluciona, no como algo que debe adivinarse perfectamente desde el primer día.
En otras palabras, YAGNI no es simplemente un principio de contención. Es un pacto. No construiremos la funcionalidad de mañana hoy, y a cambio mantendremos el código de hoy lo suficientemente maleable para cambiarlo mañana.
Cómo se ve en la práctica
Un equipo que construye una tienda en línea empieza con un único régimen fiscal en lugar de un motor de reglas universal para todos los países del mundo. Una empresa con una sola aplicación la mantiene como una unidad desplegable en lugar de dividirla en muchos servicios pequeños antes de que el modelo de negocio esté probado. Una herramienta de informes tiene un único formato de exportación porque eso es lo que los clientes pidieron, no seis porque "probablemente alguien los querrá". Un modelo de permisos comienza con administrador y usuario estándar, no con una catedral de roles anidados.
YAGNI también se aplica a la reutilización de código y a la abstracción. Los ingenieros suelen ver patrones repetidos una o dos veces y sienten la tentación de saltar directamente a un framework maestro. Los buenos equipos esperan a la tercera o cuarta repetición real antes de generalizar. De ese modo, la forma compartida se descubre a partir de la experiencia en lugar de inventarse con esperanza.
Aquí es donde YAGNI se diferencia de la mera austeridad. No es "haz menos porque menos es barato". Es "haz menos porque la realidad te enseñará qué merece existir".
Lo que YAGNI no es
YAGNI no es una instrucción para construir basura endeble. No justifica nombres pobres, pruebas débiles, seguridad descuidada ni ignorar requisitos difíciles. Si el producto debe cumplir una norma legal, un estándar de accesibilidad, un nivel de tráfico conocido o un objetivo de latencia, ese trabajo no es especulativo. Es parte del requisito presente.
Tampoco es YAGNI anti diseño. Los equipos siguen diseñando. Simplemente lo hacen en movimientos más pequeños y más reversibles. En lugar de trazar un gran mapa para cada distrito futuro de la ciudad, hacen que una calle sea fácil de extender cuando el siguiente distrito se vuelve real.
Por eso la Boy Scout Rule pertenece a este mismo entorno. Si todos dejan el código un poco más claro cada vez que lo tocan, esperar resulta menos intimidante. Sin ese orden constante, YAGNI puede sonar valiente sobre el papel y sentirse imprudente en la realidad.
Ejemplos
Un equipo de producto está construyendo una aplicación de reservas para clases locales. Saben que algún día podrían gestionar suscripciones, tarjetas regalo, accesos de agencias y pagos de marketplace. En lugar de modelar todos esos casos desde el principio, construyen reservas de eventos individuales y un único flujo de pago. La aplicación se lanza. Clientes reales la usan. Seis semanas después, el equipo descubre que las listas de espera importan mucho más que las tarjetas regalo. YAGNI ha protegido la atención.
Un equipo de ingeniería asume que un producto exitoso acabará necesitando muchos servicios pequeños. En lugar de dividir el sistema de inmediato, construyen una aplicación bien organizada con límites de módulo claros. Un año después, tienen patrones de uso reales y pueden ver qué límites son lo suficientemente estables para separar y cuáles eran solo pensamiento ilusorio.
Un desarrollador está añadiendo carga de archivos. Mientras trabaja, imagina que los clientes futuros podrían querer cargas desde archivos locales, almacenamiento en la nube, correo electrónico, cámara móvil y una interfaz de programación pública. YAGNI dice: admite la ruta que los usuarios necesitan ahora, mantén el código ordenado y espera hasta que la segunda ruta sea un hecho y no una fantasía.
Malentendidos frecuentes
Un malentendido habitual es que YAGNI significa "haz lo más torpe posible". No es así. El principio pide la cosa más simple que satisfaga bien la necesidad actual, no la más endeble con la que el equipo pueda salirse con la suya.
Otro malentendido es que YAGNI prohíbe toda previsión. No es así. Los buenos ingenieros siguen identificando dónde es probable que haya cambios. Simplemente se resisten a convertir esa intuición en estructura permanente antes de que se haya ganado su lugar.
Algunas personas creen que YAGNI significa que el código nunca debe ser reutilizable. El principio es más matizado que eso. La reutilización es bienvenida cuando necesidades reales repetidas revelan la forma de algo compartido. Es la reutilización especulativa la que causa problemas.
También existe el mito de que YAGNI entra en conflicto con el diseño. En equipos sanos, habitualmente lo afina. Al eliminar requisitos imaginarios, obliga al equipo a entender el problema real con mayor claridad.
Riesgos y límites
YAGNI puede aplicarse en exceso. Un equipo puede escudarse en él para evitar requisitos difíciles pero genuinos. Si la seguridad, el cumplimiento normativo, la accesibilidad, la retención de datos o las demandas de rendimiento conocidas ya forman parte del encargo, no son "para más adelante". Son para ahora.
También puede fallar cuando el código es difícil de cambiar. Si un equipo omite el diseño orientado al futuro pero también descuida las pruebas, el refactoring y la estructura básica, no se sentirá inteligente más adelante. Se sentirá acorralado. YAGNI solo es seguro cuando el equipo invierte en la capacidad de cambio.
También hay casos en los que una decisión temprana es genuinamente costosa de revertir, especialmente en interfaces públicas de uso generalizado o en infraestructura con contratos de larga duración. En esos casos, un poco más de previsión puede ser prudente. El límite no es "nunca pienses en el futuro". El límite es: no hagas que el código de hoy sirva a las suposiciones de mañana a menos que el coste de esperar sea realmente mayor.
Qué hacer a continuación
Si el equipo sigue construyendo para futuros imaginarios, empieza por hacer visibles los no objetivos. Deja por escrito lo que la versión actual no pretende hacer. Suena básico, pero tiene un efecto tranquilizador en una sala llena de ingenieros entusiastas.
Cuando aparezca una propuesta de flexibilidad adicional, plantea tres preguntas. ¿Qué necesidad presente satisface esto? ¿Qué complejidad añade ahora mismo? ¿Qué costaría realmente añadirlo más adelante si la necesidad se vuelve real? Esas preguntas convierten YAGNI de un eslogan en un hábito de decisión.
Protege las prácticas que hacen YAGNI seguro. Mantén las pruebas en buen estado. Normaliza el refactoring. Fomenta movimientos de diseño pequeños y reversibles. Reconoce a los equipos por entregar cambios útiles y por eliminar código que solo existe para futuros imaginados.
Sobre todo, deja de equiparar la complejidad visible con la seriedad. Los equipos maduros no son los que preconstruyen cada futuro. Son los que pueden adaptarse rápidamente cuando el futuro finalmente elige uno.
¿Tienes una pregunta o sugerencia, o quieres entender cómo investigamos y revisamos estas guías? Lee sobre nuestros estándares editoriales y cómo contactarnos.
Preguntas frecuentes
¿Qué significa exactamente YAGNI?
Son las siglas de "You aren't gonna need it" (no vas a necesitarlo). La frase indica que una capacidad no debe construirse hasta que exista una necesidad real.
¿Es YAGNI lo mismo que construir un MVP?
Están relacionados, pero no son idénticos. El MVP trata de aprender a partir del producto útil más pequeño. YAGNI es un hábito de diseño que resiste las funcionalidades y abstracciones especulativas.
¿Significa YAGNI que nunca debemos planificar con antelación?
No. Significa que los planes no deben convertirse automáticamente en código. Es posible reconocer necesidades futuras probables sin construirlas todas hoy.
¿Qué hace que YAGNI sea seguro?
Una base de código fácil de cambiar. Las pruebas, el refactoring, una estructura clara y la revisión de código constante son lo que hace que las decisiones diferidas sean viables.
¿Es YAGNI contrario a la arquitectura?
No. Es contrario a la arquitectura especulativa. Los equipos siguen diseñando, pero en pasos más pequeños y con mayor disposición a revisar.
¿Cuándo conviene ignorar YAGNI?
Cuando el requisito ya es real y costoso de aplazar, como normas de cumplimiento, objetivos de escala conocidos, necesidades estrictas de rendimiento o contratos públicos de larga duración.