---

---

Me preocupa ver mas propuestas para usar tecnologías modernas que para crear flujos de procesos

En los últimos años, el ecosistema tecnológico ha experimentado una explosión de herramientas, librerías, lenguajes y arquitecturas que prometen revolucionar la forma en que construimos software. Cada semana aparece un nuevo framework que promete reducir el tiempo de desarrollo a la mitad, un modelo de lenguaje que resuelve bugs por ti, o una plataforma que automatiza lo que antes requería horas de ingeniería. Y, sin duda, muchas de estas innovaciones son útiles, incluso necesarias.

Pero hay un patrón creciente que me inquieta: vemos entusiasmo desbordado por adoptar tecnologías de punta, pero casi indiferencia cuando se trata de diseñar, documentar o mejorar los flujos de trabajo que esas mismas tecnologías deberían servir.

En reuniones de planificación, es común escuchar propuestas como: “¿Y si migrar a esta nueva librería?”, “¿No deberíamos usar esta arquitectura serverless?”, o “¿Qué les parece si entrenamos un modelo interno?”. Rara vez, en cambio, surge: “¿Entendemos bien el proceso actual que estamos automatizando?”, “¿Tenemos métricas claras sobre los cuellos de botella reales?”, o simplemente: “¿Estamos resolviendo el problema correcto?”.

La fascinación por lo nuevo eclipsa la disciplina de lo esencial. Se invierten semanas en integrar una API de inteligencia artificial que genera código, mientras el flujo básico de onboarding de un usuario sigue fallando una de cada tres veces. Se despliegan microservicios con orquestación compleja, pero nadie se pregunta si el negocio realmente necesita esa granularidad. Se celebran arquitecturas cloud-native, pero los equipos siguen sin saber quién aprueba un cambio, quién valida un resultado, o cuándo un ticket se considera “listo”.

Este desequilibrio no es inocente. Tiene consecuencias.
Cuando priorizamos la herramienta sobre el proceso, terminamos con sistemas frágiles, equipos desorientados y productos que brillan en demos pero colapsan en producción. La tecnología sin contexto es ruido. El código sin propósito es deuda disfrazada de innovación.

Peor aún: esta tendencia refuerza una cultura en la que lo técnico se valora más que lo humano. Un pull request bien formateado recibe más atención que una mala coordinación entre equipos. Un dashboard lleno de gráficos complejos inspira más confianza que una conversación honesta sobre por qué algo falló. Y mientras tanto, los verdaderos problemas —la falta de claridad en los requisitos, la ambigüedad en las responsabilidades, la ausencia de retroalimentación real— se acumulan en silencio, bajo capas de “modernización”.

También hay una dimensión ética. Algunas de estas tecnologías requieren recursos considerables: energía, datos, infraestructura. ¿Es justificable gastarlos si el flujo que supuestamente optimizan ni siquiera está bien definido? ¿O si su único propósito es impresionar en una entrevista técnica o en una presentación ejecutiva?

No se trata de rechazar la innovación. Al contrario: la tecnología bien aplicada puede transformar industrias enteras. Pero su valor real emerge cuando sirve a un propósito claro, respaldado por procesos pensados, comunicados y adaptados constantemente.

Esto exige humildad.
Requiere que dejemos de ver la ingeniería como una carrera de armamento tecnológico y empecemos a tratarla como una disciplina de resolución de problemas humanos. Que valoremos tanto —o más— a quien mapea un flujo de negocio con claridad como a quien implementa el último patrón de diseño en trending en GitHub.

Requiere también liderazgo.
Líderes que no se dejen seducir por lo “cool”, sino que exijan preguntas incómodas: ¿Qué problema resolvemos? ¿Para quién? ¿Cómo sabremos que funcionó? ¿Qué pasa si fallamos?

Y finalmente, requiere tiempo.
Porque diseñar buenos flujos no es sexy. No genera likes ni retweets. No tiene stickers en Dev.To. Pero sí evita semanas de re-trabajo, frustración de usuarios y costos ocultos que nadie contabiliza.

Vivimos en una era donde cualquiera puede desplegar un modelo de lenguaje en minutos. Pero pocos se toman el tiempo de preguntar si realmente necesitan uno.

La próxima vez que propongas adoptar una tecnología moderna, hazte también esta pregunta: ¿He entendido profundamente el proceso que esta tecnología debería mejorar? Si la respuesta no es un “sí” rotundo, quizás lo más revolucionario que puedas hacer hoy no sea instalar una dependencia, sino tomar un café con quien conoce el problema de verdad.

Porque al final del día, los sistemas no fallan por falta de tecnología. Fallan por falta de comprensión.

#IngenieríaConPropósito #FlujosAntesQueFrameworks #TecnologíaResponsable #DesarrolloDeSoftware #LiderazgoTécnico #ProductividadReal #ProcesosClaros #InnovaciónConSentido