Menos Pilotos, Mas Producto

Tu empresa lanzó un piloto de IA. No ha lanzado un producto de IA.

Eso ya lo sabes. Lo que quizás no: la brecha se está ampliando, no cerrando, y más herramientas la están empeorando.

La Brecha que Nadie Quiere Nombrar

La encuesta empresarial 2025 de S&P Global encontró que solo el 48% de los proyectos de IA llegan a producción, y la tasa de abandono de pruebas de concepto saltó del 17% en 2024 al 42% en 2025. El Proyecto NANDA de MIT reportó que el 95% de las organizaciones que implementaron IA generativa no vieron retorno medible en P&L. Cuando el equipo DORA de Google analizó 39,000 encuestados, encontraron que cada 25% de aumento en adopción de IA se correlacionaba con una caída del 7.2% en estabilidad de entrega.

Lo que cuentan esos números no es que las herramientas de AI coding no sirvan. Claro que sirven. Ingenieros senior reportan mejoras reales de productividad, hay equipos entregando migraciones en días que antes tomaban semanas, y Rakuten está ejecutando refactors autónomos de varias horas con 99.9% de precisión numérica usando Claude Code.

La historia es que la mayoría de las empresas están atrapadas en una brecha. Construir funciona. Entregar no. Y los líderes de ingeniería responsables lo sienten: la sospecha creciente de que sus equipos están más ocupados que nunca y son menos efectivos que antes. No debería ser así con esta tecnología.

Addy Osmani, líder de Chrome DX en Google, le puso nombre a la brecha: el problema del 70%. La IA puede producir el primer 70% de una aplicación en una tarde. El último 30% (autenticación, permisos, manejo de errores, observabilidad, postura de seguridad, cumplimiento, casos borde, escala) es donde la mayoría de los productos construidos con IA van a morir. Simon Willison lo dijo más directamente: “Hacer vibe coding hasta tener un codebase en producción es claramente una idea terrible.”

Entonces, ¿por qué tantas empresas siguen intentándolo?

Por Qué los Pilotos Aislados Fracasan

Asómate a cualquier iniciativa empresarial de IA hoy y vas a ver el mismo patrón. Cada equipo tiene su propio experimento. Un squad está evaluando Cursor. Otro está en Claude Code. Un tercero tiene una prueba de concepto en Lovable que lleva cuatro meses “casi lista para lanzar”. Seguridad está construyendo un flujo de revisión separado. Compliance está redactando una política que nadie ha leído. Todos están ocupados. Nada sale a producción.

Así se ve la fragmentación. Es la estrategia de IA por defecto en la mayoría de las empresas, y es la más costosa que pueden ejecutar. Cada equipo reinventa las mismas protecciones desde cero. Cada piloto genera su propia deuda técnica. Cada revisión de seguridad arranca de cero. Las ganancias de productividad del AI-assisted coding son reales, pero se evaporan contra el costo de cuarenta esfuerzos aislados jalando en cuarenta direcciones diferentes.

Las empresas que realmente están lanzando productos de IA están haciendo algo diferente. Están construyendo sistemas.

Pilar Uno: Plataformas Centralizadas Sobre Esfuerzos Aislados

Shopify ejecuta Copilot, Cursor y Claude Code a través de un proxy LLM interno y un sistema de revisión personalizado llamado Roast. El VP de Engineering Farhan Thawar no deja dudas sobre la razón: “Shopify aún no está en el punto donde permitimos que la IA haga check in de código automáticamente en los repos.”

Stripe construyó Minions, su propia capa de generación estructurada, y desplegó Claude Code para 1,370 ingenieros detrás de ella. Rakuten tiene un sistema llamado Managed Agents sobre Claude Code que redujo errores críticos en un 97% en ciclos de release bisemanales. Cada caso de éxito comparte la misma arquitectura. Una capa de generación arriba (las herramientas de IA que todos tienen). Una capa puente debajo (lo que la mayoría de las empresas no tienen).

La capa puente es donde el código de IA se convierte en producto lanzable. Incluye cuatro cosas:

Un gateway centralizado de herramientas. Un proxy. Una relación de facturación. Un canal de observabilidad. Un conjunto de credenciales. Esta es la diferencia entre “nuestra organización de ingeniería usa IA” y “cada equipo tiene un vendor diferente, una política diferente y una superficie de exposición diferente.”
Guardrails compartidos. Archivos de skills internos, configuraciones de AGENTS.md, librerías de prompts y patrones de contexto aprobados. No obligues a cada equipo a descubrir por su cuenta qué significa hacer las cosas bien.
Infraestructura de revisión y testing. Herramientas de AI code review (CodeRabbit, Greptile), generación de tests con IA (QA Wolf, Meticulous), observabilidad con IA (Resolve AI). Esto ya no es opcional. La telemetría 2026 de Faros AI sobre 22,000 developers encontró que los incidentes por pull request aumentaron un 242.7% y el 31% de los PRs ahora se mergean sin ninguna revisión humana. La capa puente es lo que intercepta eso.
Un camino de sandbox a producción. Un pipeline documentado y repetible desde prototipo hasta producción que incluya revisión de seguridad, pruebas de carga y procedimientos de rollback. La caída de Amazon Kiro en diciembre de 2025, una falla de 13 horas en AWS causada por un agente de IA que eliminó y recreó un ambiente de producción, sucedió porque ese camino no existía.

Pilar Dos: Revisión, Observabilidad y Ownership

Cada historia de falla con IA tiene la misma forma. Un equipo generó código. Nadie senior lo revisó. Llegó a producción. Se rompió.

El incidente de Replit en julio de 2025, donde un agente de IA borró la base de datos de producción de SaaStr durante un code freeze declarado y luego fabricó 4,000 usuarios ficticios para encubrirlo, es el ejemplo canónico. Jason Lemkin, fundador de SaaStr, dijo que le había dicho al agente “11 veces en MAYÚSCULAS QUE NO LO HICIERA.” El agente lo hizo de todos modos, y después mintió al respecto. El propio CEO de Replit lo calificó como “inaceptable y no debería ser posible.”

La lección no es que la IA no sea confiable. La lección es que confiar sin verificar es una receta para generar incidentes.

Cada empresa que lanza software construido con IA exitosamente tiene el mismo no negociable: ningún código de IA se mergea a producción sin un ingeniero senior en el loop. Shopify lo tiene. Stripe lo tiene. Amazon, después de Kiro, ahora lo exige. En la organización de retail de Amazon, cualquier cambio asistido por IA de un ingeniero junior ahora requiere aprobación senior. Eso no es escepticismo. Así funciona cada implementacion exitosa de IA que he visto.

Tres cambios culturales hacen que esto funcione a escala.

La observabilidad se mueve hacia arriba. Charity Majors de Honeycomb lleva años haciendo este argumento: los equipos sienten que no necesitan observabilidad hasta que producción se cae, y para entonces ya es demasiado tarde. La IA acelera la producción de código sin acelerar ese instinto. Si tu equipo está lanzando código generado por IA a sistemas sin logs estructurados, trazas y métricas en su lugar antes del primer deploy, no estás lanzando un producto. Estás armando el escenario para la próxima caída.

El ownership no se transfiere a la IA. Un agente de IA no lleva un pager. No lo despiertan a las 3 AM. No escribe post-mortems. El ingeniero que hizo commit del código es dueño del código, sin importar quién o qué escribió el primer borrador. Si esa responsabilidad recae en la IA, nadie es dueño de nada. Que nadie sea dueño de nada es exactamente como los productos mueren en silencio.

Los estándares de revisión deben igualar la velocidad de producción. Si la IA permite que tu equipo genere cuatro veces más código, tu capacidad de revisión tiene que escalar con ello o la calidad se desploma. Aquí es donde la plataforma centralizada se paga sola. AI-assisted review, escaneo automatizado de seguridad y generación de tests son lo que permite que los revisores humanos se enfoquen en las decisiones de juicio que realmente importan.

Revisión, observabilidad y ownership no son restricciones a la adopción de IA. Son lo que hace que la adopción de IA sea lo suficientemente segura para generar valor compuesto.

Pilar Tres: Mide lo que Realmente Sale a Producción

“Nuestros developers son 40% más rápidos con IA.”

Seguro ya escuchaste ese número. Casi siempre es mentira.

Thoughtworks midió la mejora real en cycle-time en proyectos reales de clientes en aproximadamente 8%, porque menos del 30% de las horas de un developer se gastan escribiendo código, y la IA solo ayuda en parte de eso. El ensayo controlado aleatorizado de METR mostró que los developers experimentados eran 19% más lentos con herramientas de IA mientras se percibían a sí mismos como 20% más rápidos. La brecha entre productividad percibida y real es la métrica más peligrosa de la industria en este momento, porque está impulsando decisiones de inversión que no se sostienen.

La solución es medir lo que sale a producción, no lo que se genera.

Deja de rastrear líneas de código generadas, volumen de prompts, tokens consumidos y tasas de adopción interna. Nada de eso te dice si un producto llegó a un usuario que paga.

Empieza a rastrear features en producción, tiempo desde prototipo hasta el primer usuario real, tasa de incidentes por release, frecuencia de rollback, tasa de code churn (líneas escritas que se reescriben en menos de dos semanas), hallazgos de seguridad por merge y throughput de revisión. Estas son las métricas que te dicen si tu inversión en IA está generando retorno o se está fugando.

El análisis de GitClear sobre 211 millones de líneas mostró que el código copiado y pegado subió del 8.3% al 12.3% entre 2021 y 2024, y la actividad de refactoring cayó por debajo del 10% de los cambios. Esa es la señal de que la velocidad le está ganando a la calidad. No se ve en métricas de vanidad. Se ve en el costo de mantenimiento seis meses después.

Mide el viaje desde la idea hasta el producto lanzado, no desde el prompt hasta el primer borrador. Confundir esos dos viajes es como terminas con cuarenta prototipos y cero productos.

La Metafora del Astillero

Hay una razón por la que sigo volviendo a esta metáfora.

Un constructor de barcos no arma un bote haciendo una lista de piezas. Lo arma entendiendo cómo cada pieza tiene que funcionar con todas las demás en cada condición que va a enfrentar en el agua. El casco, la vela, el aparejo, el lastre. Cada uno es un prototipo en tierra y un peligro en el mar hasta que se integran en un sistema que de verdad se sostiene.

Las herramientas de AI coding son la madera. Son lindas, son baratas, cortan rápido. Pero la madera no es un barco. Un sistema es lo que convierte materia prima en algo que navega.

Para las empresas que construyen productos con IA en 2026, el trabajo no es elegir entre Cursor o Claude Code. Esa es la parte fácil. El trabajo es construir el sistema alrededor de las herramientas. La plataforma centralizada que le da a todos el mismo piso de calidad. La cultura de revisión que mantiene honesto el output de la IA. Las métricas que miden lo que realmente llega a producción.

Las empresas que construyen ese sistema están lanzando productos. Las que siguen corriendo cuarenta pilotos desconectados están ocupadas, queman presupuesto y no se mueven.

Elige un pilar. Asígnale recursos este trimestre. Mídelo el siguiente. Ese es el movimiento.