Ingeniería de producto para la era de la IA

El cambio de paradigma en la ingeniería

El informe DORA 2025↗ (se abre en una pestaña nueva) encontró que el 80% de los desarrolladores reporta mejoras de productividad con herramientas de IA y que el 59% reporta una mejor calidad del código. Eso es real. La adopción también es casi universal: DX encontró que el 92.6% de los desarrolladores usa herramientas de IA al menos una vez al mes. Pero el informe State of AI 2025 de McKinsey↗ (se abre en una pestaña nueva) encontró que solo el 21% de las organizaciones que usan IA generativa ha rediseñado realmente sus flujos de trabajo en torno a ella.

La brecha existe porque la velocidad sin claridad es peligrosa.

El estudio de METR de 2025 encontró que los desarrolladores con experiencia fueron un 19% más lentos con herramientas de IA en bases de código maduras que conocían bien; las mejoras dependen de una intención clara y de una revisión disciplinada. En nuestra opinión, eso se debe a que la IA amplifica el criterio. Cuando le da herramientas de IA a un ingeniero con una intención poco clara, avanza más rápido en la dirección equivocada. Cuando le da una intención totalmente clara, avanza más rápido en la dirección correcta.

Esto significa que el paradigma de la ingeniería cambió de fondo:

El cuello de botella pasó de la ejecución a la intención. Hoy los ingenieros pueden entregar en horas código funcional que antes tomaba semanas. Pero ese código solo sirve al negocio si la intención detrás de él es precisa y se comparte antes de empezar el trabajo.

Los ingenieros necesitan instinto de producto. En la era de la IA, la ingeniería no consiste en implementar especificaciones. Consiste en entender los problemas de los usuarios, los resultados de negocio y las decisiones sobre concesiones. Los ingenieros que pueden razonar sobre estas preguntas son invaluables. Los ingenieros que solo saben ejecutar tickets son intercambiables.

Los líderes de producto necesitan dominio de la ingeniería. No se puede liderar producto en la era de la IA sin entender qué es factible, qué es reversible, qué genera deuda técnica y qué concesiones importan. Adivinar no funciona cuando la ejecución es así de rápida.

Las firmas que competirán con eficacia no son las que tienen los ingenieros más rápidos. Son las que tienen equipos unificados en los que el pensamiento de producto y la ejecución de ingeniería son un solo proceso, no dos procesos secuenciales.

Por qué la división tradicional entre producto e ingeniería ya no funciona

El modelo clásico suponía que producto e ingeniería eran asuntos separados. Producto define qué construir. Ingeniería define cómo construirlo. Luego se pasan el trabajo de un lado a otro.

Este modelo necesitaba plazos largos para justificar el costo adicional. Se dedicaban seis semanas a escribir especificaciones para que los ingenieros tuvieran una dirección lo bastante clara como para ejecutar durante tres meses. Esa proporción funcionaba cuando el problema era lo costoso de la ejecución.

Pero cuando la ejecución se abarató, la proporción se invirtió. Ahora el costo no es la construcción. Es la demora entre aprender algo y actuar en consecuencia. Una demora de dos semanas en la especificación antes de una construcción de dos días significa que está operando con información de hace dos semanas.

Peor aún, las especificaciones quedan obsoletas al instante. Una vez que empieza la ejecución, se aprenden cosas sobre el problema que invalidan la especificación original. El ingeniero tiene que detenerse y esperar una nueva especificación, o tomar decisiones de producto por su cuenta. Ninguna de las dos opciones es buena.

La división también crea incentivos desalineados. Los ingenieros optimizan para entregar las especificaciones a tiempo. Producto optimiza para cumplir una hoja de ruta. Ninguno optimiza para los resultados de negocio. Ambos lados terminan defendiendo su territorio en lugar de colaborar en el problema real.

En la era de la IA, esta división es un pasivo. Necesita saber si está construyendo lo correcto mientras lo construye, no meses después, cuando se lanza.

Cómo es la ingeniería de producto unificada

La ingeniería de producto es la práctica de disolver la frontera entre la estrategia de producto y la ejecución técnica. No significa que los ingenieros escriban especificaciones ni que los gerentes de producto escriban código. Significa que comparten una sola definición de cómo se ve el éxito y colaboran de forma continua para alcanzarlo.

En un modelo unificado:

Los ingenieros son responsables de los resultados, no solo de los tickets. Un ingeniero no cierra un ticket y pasa al siguiente. Entiende la hipótesis que se está poniendo a prueba, las métricas que importan y si el trabajo realmente marcó una diferencia. Tiene un interés real en el resultado.

Los líderes de producto impulsan la intención, no solo los plazos. El trabajo de un líder de producto es asegurarse de que la intención sea totalmente clara antes de empezar y luego no estorbar. Documente el razonamiento. Explique las concesiones. Responda las preguntas. Pero no pretenda conocer los detalles de implementación mejor que el ingeniero.

Las decisiones se documentan con su razonamiento. No solo qué se decidió, sino por qué. Esto es crítico en el desarrollo de la era de la IA, porque el contexto se convierte en su multiplicador de velocidad. Cuando un ingeniero entiende no solo el requisito sino el razonamiento de negocio que lo sustenta, puede usar herramientas de IA para explorar más del espacio de diseño con mayor rapidez.

Los controles de calidad existen antes del lanzamiento, no después. En un modelo unificado, QA e ingeniería colaboran durante la construcción, no como un punto de control posterior. Los problemas se detectan cuando son fáciles de corregir, no cuando son costosos.

Las métricas se definen antes de construir y se miden después del lanzamiento. No termina para luego preguntarse qué medir. Sabe cómo se ve el éxito antes de que el código llegue a un repositorio.

Esto es fundamentalmente distinto del modelo anterior. Es más rápido no por la IA, sino porque se elimina el costo adicional de la división entre producto e ingeniería. La IA es el acelerador, no el cambio en sí.

El papel de la IA en la ingeniería moderna

Hay mucho ruido sobre la idea de que la IA reemplazará a los ingenieros. Esa idea no entiende lo esencial.

Las herramientas de IA amplifican el criterio. Son excepcionalmente buenas para generar código, explorar patrones de diseño, recordar bibliotecas y sintaxis, escribir pruebas y detectar ciertas categorías de errores. Son pésimas para decidir qué construir, por qué importa o si se trata de la concesión correcta.

Los ingenieros que prosperarán en la era de la IA no son los que mejor memorizan la sintaxis. Son los que tienen el criterio más claro sobre lo que importa. Son los que pueden tomar un problema difuso de un usuario y traducirlo en requisitos técnicos precisos. Son los que entienden las restricciones del negocio y saben manejar las concesiones.

La IA no reemplaza ese criterio. Acelera la ejecución una vez que el criterio está claro. Cuanto más rápido puede ejecutar, más crítico se vuelve tener un criterio claro.

Cómo encarna InTech este modelo

InTech Ideas se construyó desde cero sobre el principio de que la ingeniería de producto es el futuro. Creamos dos marcos para llevarlo a la práctica.

Pro-Neering es nuestra filosofía: los ingenieros son responsables de los resultados, y se espera que cada ingeniero de su equipo piense como una persona de producto. Eso no significa que escriban especificaciones. Significa que preguntan "¿por qué?" antes de programar. Entienden el problema de negocio. Proponen mejores soluciones si las ven. Miden los resultados.

CRAFT (Context, Rationale, Automate, Fortify, Telemetry) es el sistema operativo de InTech, la gobernanza que sostiene la estrategia, la ingeniería de producto y las operaciones gestionadas. Pro-Neering es la filosofía que lo respalda. En la ingeniería de producto, CRAFT es la forma en que ejecutamos con velocidad mientras mantenemos la deuda técnica visible y gestionada:

• Context: Una verdad compartida antes de construir. No una especificación de 50 páginas. Un documento enfocado que explica el problema, el usuario, el resultado de negocio y las restricciones.
• Rationale: Decisiones documentadas con su razonamiento. Este es su multiplicador de velocidad, porque permite que las herramientas de IA y su equipo exploren el espacio de diseño más rápido.
• Automate: Ejecución asistida por IA con supervisión humana proporcional. Usamos la IA para avanzar rápido, pero no ponemos el piloto automático. Cada ruta crítica se revisa.
• Fortify: Controles de calidad antes del lanzamiento. Pruebas, seguridad, rendimiento: todo incorporado desde el diseño, no añadido después.
• Telemetry: Medición de resultados después del lanzamiento. Sabemos si funcionó.

Lo entregamos a través de pods. Un Express Pod lleva una mejora medible a producción en cuestión de semanas, con el plazo acordado en el Intent Contract antes de empezar a construir. El Build Pod es capacidad de entrega continua con un Product Delivery Lead, dimensionada según la forma del trabajo y gestionada en función de resultados. Las condiciones comerciales se acuerdan en cada proyecto. El Build Pod puede configurarse para varios frentes de trabajo cuando equipos más grandes trabajan en paralelo. Cada pod incluye un Product Delivery Lead, ingenieros responsables de la ejecución y apoyo de DevOps, QA y diseño. Un Product Delivery Lead es responsable del resultado: gestiona la intención, los hitos y el ritmo de entrega durante todo el proyecto. Una vez que el producto está en producción, InTech Operate puede operarlo y mejorarlo como servicio gestionado.

El resultado son equipos que avanzan rápido sin agotarse. Equipos que lanzan sin descuidar la mantenibilidad del código. Equipos que saben si su trabajo realmente movió el negocio.

Los resultados de negocio que esto genera

Cuando producto e ingeniería están unificados:

El tiempo hasta obtener valor se reduce drásticamente. No espera especificaciones. No debate entre hojas de ruta separadas de producto y de ingeniería. El trabajo empieza con una intención clara y avanza de forma continua hasta el lanzamiento.

La deuda técnica se mantiene manejable. Cuando a los ingenieros les importan los resultados, no solo la velocidad, toman decisiones distintas. Se oponen a los atajos que les traerían problemas después. Se hacen responsables del código que lanzan.

Los equipos se mantienen estables. El cambio constante de contexto y la falta de alineación desgastan a las personas. Los equipos unificados con resultados claros tienen menor rotación y mayor productividad.

Los ciclos de aprendizaje son rápidos. Lanza, mide, aprende y se adapta, todo en semanas y no en trimestres. Esa agilidad es una ventaja competitiva.