Ingeniería de software no es tener más recursos: es saber poner límites
Hay una confusión moderna bastante seria: pensar que ingeniería de software significa sonar técnico, usar palabras grandes o construir sistemas enormes. No.
Ingeniería de software, en el fondo, significa algo bastante menos glamuroso y muchísimo más importante: usar principios básicos para construir software razonable, mantenible, eficiente y sostenible.
Y justo ahí es donde estamos empezando a fallar.
Tenemos máquinas más rápidas. Navegadores más potentes. Frameworks más capaces. Infraestructura infinita en la nube. Modelos de IA que generan código en segundos.
Y en vez de volvernos más rigurosos, muchas veces nos estamos volviendo más descuidados.
Cuando todo parece infinito, dejamos de cuidar
Durante años, optimizar era una necesidad. No por romanticismo, sino porque no había alternativa.
Las imágenes pesaban poco porque tenían que pesar poco. El JavaScript era más pequeño porque si no, la web se rompía. La lógica se pensaba mejor porque el servidor no daba para todo. El CSS se vigilaba porque cada kilobyte contaba. La base de datos se consultaba con cuidado porque una mala query dolía de verdad.
Hoy muchas de esas restricciones han desaparecido o, al menos, parece que han desaparecido.
Ese es el problema.
Que algo se pueda hacer no significa que deba hacerse.
Ahora puedes abrir una web y ver páginas con imágenes que pesan cientos de megabytes. Hace unos años eso era directamente impensable. Hoy, como el navegador aguanta, la red es mejor y el portátil del desarrollador tiene potencia de sobra, se tolera.
Pero tolerar no es diseñar bien.
Tener una autopista no convierte en buena idea ir con un camión lleno de ladrillos al supermercado
Puedes hacerlo, claro. El motor puede moverlo. La carretera existe. El volante responde. Pero sigue siendo una decisión absurda para comprar pan, leche y fruta.
Eso es exactamente lo que pasa cuando una página simple carga:
- imágenes gigantescas para un thumbnail
- bundles enormes para interacciones mínimas
- cinco librerías para resolver algo que cabía en veinte líneas
- componentes hiperdinámicos donde solo hacía falta HTML bien hecho
El sistema lo soporta, sí.
Pero eso no convierte la solución en buena.
La potencia disponible ha hecho que mucha gente confunda capacidad con criterio.
Y son cosas completamente distintas.
La IA acelera tanto lo bueno como lo mediocre
Aquí entra el segundo gran problema: la IA.
La IA no tiene criterio técnico propio. Tiene velocidad. Tiene probabilidad. Tiene capacidad de recombinar patrones. Eso es útil. Muchísimo.
Pero si el contexto está mal, el resultado también.
Si el desarrollador no tiene principios básicos, la IA no corrige eso. Lo multiplica.
¿Qué pasa cuando la base es floja?
- Si no entiendes performance, la IA te genera una solución pesada más deprisa.
- Si no entiendes arquitectura, la IA te ayuda a escalar una mala decisión.
- Si no entiendes semántica, accesibilidad o coste, la IA te devuelve código que “funciona” pero degrada el sistema.
La IA aprende de patrones existentes, y una parte importante de esos patrones también está llena de malas prácticas, deuda técnica y decisiones tomadas por conveniencia.
Una excavadora es una herramienta increíble. Te ahorra horas de trabajo manual. Te da fuerza, velocidad y alcance.
Pero si quien la maneja no entiende el terreno, puede abrir el agujero equivocado mucho más rápido que antes.
La IA hace eso: amplifica.
Por eso no reemplaza principios de ingeniería. Los vuelve más necesarios.
Más capas no significa más calidad
Hay una especie de superstición técnica muy extendida: pensar que cuantas más piezas tenga un sistema, más “profesional” es.
Más servicios. Más librerías. Más abstracciones. Más wrappers. Más pipelines. Más automatización. Más inteligencia artificial. Más agentes. Más capas sobre capas.
Y a veces sí: la complejidad está justificada.
Pero muchas veces no.
No estás mejor protegido. Estás peor adaptado al entorno.
En software ocurre lo mismo:
- si tu solución necesita diez capas para resolver un problema de dos capas
- si una landing carga como una SPA corporativa de 2019
- si un formulario depende de tres SDKs, analytics, un CMS, un wrapper visual y dos chatbots
entonces no estás diseñando mejor. Estás acumulando peso.
Y el peso siempre acaba cobrándose en algún sitio:
- tiempo de carga
- mantenimiento
- debugging
- onboarding
- coste de infraestructura
- fatiga mental del equipo
La ingeniería empieza donde termina la improvisación
Decir “ingeniería de software” suena importante, pero en realidad baja a cosas muy básicas:
- Elegir la solución más simple que resuelva bien el problema.
- Pensar en coste, no solo en posibilidad.
- Evitar complejidad que no aporta valor real.
- Diseñar para mantenimiento, no solo para demo.
- Respetar los recursos: CPU, red, memoria, tiempo humano y atención del usuario.
Eso es ingeniería.
No es construir un castillo porque ahora AWS, el navegador y el portátil permiten levantarlo.
Es saber cuándo un puente pequeño resuelve mejor el problema que una ciudad entera de hormigón.
El problema de vivir en abundancia técnica
Cuando todo sobra, dejamos de pensar en límites.
Y los límites son precisamente lo que históricamente ha hecho mejor al software.
Si tienes cien ingredientes, veinte salsas, diez quesos y quince técnicas posibles, no necesariamente cocinas mejor. Muchas veces cocinas peor, porque pierdes foco.
El gran cocinero no es el que mete todo en el plato. Es el que sabe qué quitar.
En software también:
- no toda feature merece existir
- no toda librería merece entrar
- no todo efecto visual merece cargarse
- no todo problema necesita IA
- no toda página necesita JavaScript
La madurez técnica no está en cuánto añades.
Está en cuánto eres capaz de no añadir.
Hemos normalizado cosas que deberían parecernos un disparate
Hace años, una página con imágenes gigantescas, dependencias absurdas y una interfaz que tardaba una eternidad en reaccionar se veía como un fallo evidente.
Hoy, muchas veces se normaliza porque:
- “el usuario tiene buen móvil”
- “ya estamos en 2026”
- “la CDN lo aguanta”
- “luego lo optimizamos”
- “la IA me lo montó así”
Ese razonamiento es peligrosísimo.
Porque convierte la mala práctica en paisaje.
Y cuando algo malo se vuelve frecuente, empieza a parecer correcto.
Al principio molesta. Luego te acostumbras. Después ya ni la ves. Hasta que un día el techo cae.
La deuda técnica y el desperdicio de recursos funcionan igual.
No suelen explotar el primer día.
Se acumulan.
Optimizar no es obsesionarse, es respetar
Aquí conviene hacer una distinción importante.
Optimizar no significa convertir cada proyecto en una paranoia microtécnica. No significa pasarse tres días ahorrando 4 KB ridículos mientras el producto no está ni validado.
Optimizar de verdad significa otra cosa:
- respetar la red del usuario
- respetar la memoria del dispositivo
- respetar el tiempo de carga
- respetar la claridad del código
- respetar el coste de mantenimiento del equipo
Es una forma de respeto técnico.
No porque el sistema no pueda soportar más, sino porque no hay motivo para hacerlo peor a propósito.
La IA no nos debería volver perezosos. Debería elevar nuestro estándar
Si una IA te permite hacer en 20 minutos lo que antes hacías en 2 horas, eso no significa que puedas dejar de pensar. Significa justo lo contrario:
ahora tienes más tiempo para pensar en lo importante.
Ese tiempo extra debería ir a:
- revisar mejor decisiones
- simplificar arquitectura
- mejorar accesibilidad
- reducir peso y complejidad
- cuidar naming, semántica y mantenibilidad
- probar de verdad
La IA no debería ser una excusa para producir más volumen.
Debería ser una oportunidad para producir más criterio.
Un software mejor no es el que demuestra poder. Es el que demuestra contención
Puedes llenarla con todo “por si acaso”: tres linternas, cinco baterías, dos hornillos, cuatro chaquetas, una sartén, libros, cables, herramientas, comida para una semana.
Sí, cabe.
Sí, técnicamente puedes cargarla.
Sí, parece que vas muy preparado.
Hasta que llevas una hora caminando y descubres que la mochila, en realidad, te está impidiendo avanzar.
Muchos proyectos son esa mochila.
No están rotos porque les falte algo.
Están pesados porque nadie se atrevió a quitar.
Conclusión: la abundancia no elimina los principios
Que las máquinas sean mejores no vuelve irrelevantes las buenas prácticas.
Que la IA acelere el desarrollo no vuelve opcional el criterio.
Que la infraestructura aguante más no convierte el desperdicio en diseño.
La ingeniería de software no va de construir más.
Va de construir mejor.
Y construir mejor suele implicar:
- menos peso
- menos ruido
- menos acoplamiento
- menos gasto innecesario
- más intención
Antes optimizábamos porque no quedaba otra.
Hoy deberíamos optimizar porque entendemos por qué importa.
Ese es el cambio de nivel real.
No hacer más porque podemos.
Hacer solo lo necesario, pero hacerlo bien.