Del 87% que usa IA al 4% que confía: el método de ingeniería

Por qué ingeniería no es talento individual

Un programador con años de experiencia escucha que las páginas de producto cargan lento, imagina una solución en segundos y la implementa. El resultado puede funcionar. Pero no sabe cuánto mejora, qué tan diferente es de otras alternativas ni si la decisión realmente se justifica.

Esa es la trampa que describe un ensayo reciente publicado por el desarrollador conocido en GitHub como parksb. La pregunta no es si el instinto produce software funcional — muchas veces lo hace — sino si la organización puede repetir resultados fiables sin depender del genio de una persona concreta. Cuando eso deja de ser cierto, se necesita un enfoque de ingeniería.

El término "ingeniería de software" nació precisamente para eso. En la NATO Software Engineering Conference de 1968, celebrada en Garmisch (Alemania), un grupo de investigadores concluyó que el software crecía en complejidad más rápido que los métodos disponibles para construirlo. La frase se eligió deliberadamente como provocación: si el desarrollo de software quería parecerse a la ingeniería civil o mecánica, necesitaba fundamentos teóricos y prácticas disciplinadas. Esa herencia —el rechazo de goto, la programación orientada a objetos, los lenguajes modernos— todavía marca cómo se enseña a programar hoy.

🤖 La IA no es solo para leer sobre ella

En la comunidad la aplicamos: automatización, agentes IA y herramientas reales para emprender, no solo para informarte.

👥 Aplicarla en la comunidad

Qué define un enfoque de ingeniería según IEEE

La definición operativa está en el Software Engineering Body of Knowledge (SWEBOK), publicado por la IEEE Computer Society y actualizado a la versión 4.0 en 2025. Ingeniería de software es la aplicación de un enfoque sistemático, disciplinado y cuantificable al desarrollo, operación y mantenimiento de software.

El autor traduce esa definición en cuatro hábitos que cualquier equipo puede aplicar:

Medir el problema real antes de proponer soluciones. "Lento" puede significar muchas cosas.
Comparar varias alternativas viables según criterios explícitos: latencia, costo, complejidad, riesgo.
Estimar el resultado esperado antes de implementar.
Comparar la estimación con el resultado real y ajustar. El aprendizaje es el subproducto.

Es un proceso iterativo por definición. Lo aprendido en cualquier etapa puede obligar a revisar una decisión anterior, y por eso la calidad de las estimaciones mejora con el tiempo.

El caso de la caché Redis: medir antes de saltar

El ensayo lo ilustra con un caso real. Una página de e-commerce tiene un FCP p75 de 2.700 ms; el umbral recomendado por Google para una buena experiencia es 1.800 ms o menos. Los traces muestran que el servidor SSR pasa buena parte de su tiempo esperando al API de producto, que tiene una latencia p95 de 1.000 ms y dedica 800 ms a queries de lectura a la base de datos.

El instinto diría: "metamos Redis". El enfoque de ingeniería dice: miremos primero. Un análisis de tráfico revela que el 5% más popular de los productos explica el 90% de las lookups. Una simulación con TTL sugiere que una caché en memoria lograría un hit rate superior al 95% y bajaría la latencia a unos 200 ms.

Tras implementar Redis, los números reales fueron más modestos: hit rate del 65%, API p95 de 850 ms, FCP p75 de 2.000 ms. La causa: la información del producto depende de datos personalizados, así que la cardinalidad de la clave de caché era mayor de la prevista. La solución fue rediseñar la estrategia: información estática en caché global, datos personalizados por separado. Resultado final: 97% de hit rate, 200 ms de API p95, FCP p75 de 1.400 ms.

El punto no es Redis. Es que el proceso —medir, comparar, estimar, contrastar— permitió encontrar una solución que el instinto del primer momento no anticipaba.

Por qué la IA no elimina este enfoque

La industria vive una paradoja en 2026. Según una encuesta publicada por SD Times, el 87% de los desarrolladores ya usa o planea usar herramientas de IA para programar, pero solo el 31% confía en la precisión del output y apenas un 4% reporta "alta confianza". Google, por su parte, comunicó en abril que el 75% del código nuevo que se escribe dentro de la empresa proviene de IA, según reportó Business Insider.

El ensayo coincide con esa evidencia. Hay dos razones por las que el enfoque de ingeniería sigue siendo necesario:

El contexto hay que dárselo. Un LLM con requisitos abstractos produce resultados abstractos. Tras horas peleando con la IA para refinar un output que no maneja edge cases, el desarrollador termina concluyendo que el código es la especificación más clara del negocio.
La calidad del output es inconsistente. La limitación es especialmente visible en sistemas brownfield, donde hace falta que un ingeniero humano mida y verifique si el resultado cumple los requisitos.

El autor usa el término inglés harness —un arnés que guía a humanos e IA hacia mejor software de forma consistente—. La predicción de que "la ingeniería de software ha muerto" no es nueva; lo que realmente anuncia, según el texto, es el fin del ingeniero humano que lidera ese arnés.

Qué significa esto para tu startup

El enfoque de ingeniería no es un lujo de grandes empresas. Es la diferencia entre un equipo que escala y uno que se atasca en el caos. Tres acciones concretas que puedes implementar esta semana:

Mide antes de optimizar. Antes de añadir cualquier caché, índice o servicio nuevo, instrumenta el problema con métricas verificables. Si no puedes medir el baseline, no podrás demostrar la mejora.
Compara al menos dos alternativas por decisión técnica importante. No es burocracia: es la única forma de saber si elegiste la mejor opción o simplemente la primera que se te ocurrió.
Establece un feedback loop de estimación. Anota cuánto tiempo toma cada tarea, compáralo con tu estimación y revisa el proceso cada sprint o cada mes.

Hay un dato adicional que merece atención. Según Tricentis, citado por Forbes, el 63% de las empresas despliega código sin todas las pruebas necesarias; en 2025 se reportaron más de 12.100 brechas de datos, y el costo promedio de una brecha alcanza los USD 4,4 millones. McKinsey, también citado por Forbes, estima que entre el 10% y el 20% del presupuesto destinado a nuevo desarrollo se desvía a reparar deuda técnica, lo que representa entre el 20% y el 40% de toda la base tecnológica.

El enfoque de ingeniería no garantiza software perfecto — pero sube el piso de calidad de forma medible. La frase con la que el ensayo cierra merece repetirse: un enfoque de ingeniería se vuelve necesario en el momento en que una organización de software debe producir resultados fiables de forma repetida, sin depender del genio individual.