La IA cubre el 70% fácil de un proyecto a gran velocidad, pero el 30% final —edge cases, manejo de errores, arquitectura, robustez— sigue exigiendo criterio humano y decide si el software sobrevive en producción. La lección: la IA colapsa el costo de empezar, no el de terminar.
Hay un momento mágico y traicionero en cada proyecto construido con IA: son las once de la noche, le pediste una app, y en veinte minutos tienes algo que funciona, se ve bien y hasta parece terminado. Sientes que ganaste. Al día siguiente intentas que maneje un usuario que hace algo raro, un pago que falla a mitad de camino, un dato vacío, dos personas pulsando el mismo botón, y la magia se convierte en un pantano. Bienvenido al problema del 70%: el fenómeno mejor documentado —y menos confesado— de la era del código asistido por IA. La IA te regala el 70% del camino a una velocidad que parece brujería, y luego te suelta la mano justo en el 30% que decide si tu software es un juguete o un producto.
Quién lo nombró y por qué la cifra importa
El nombre no es nuestro. Addy Osmani, ingeniero de Google, lo bautizó como "el problema del 70%" tras observar patrón tras patrón en gente construyendo con IA. Su tesis es incómodamente precisa: la IA cubre con facilidad la parte patronada y predecible de un proyecto —el scaffolding, el CRUD, la pantalla bonita, lo que ha visto un millón de veces en su entrenamiento— pero el 30% restante sigue exigiendo criterio de ingeniero senior. Ese 30% no es más código: es otra clase de trabajo. Son los edge cases que nadie pidió, el manejo de errores que solo importa cuando algo se rompe, las decisiones arquitectónicas que no se ven pero sostienen todo, la robustez que separa la demo del despliegue. Y la observación más filosa de Osmani es sobre quién sobrevive ahí: los seniors moldean y limitan la salida de la IA como quien poda un árbol; los principiantes quedan atrapados en un bucle infinito de depuración, pidiéndole a la máquina que arregle un bug que ellos no entienden, generando tres bugs nuevos por cada uno que tapan.
El pescado y la caña: por qué el 30% es de otra materia
La mejor forma de entenderlo es una vieja imagen dada la vuelta. La IA no te enseña a pescar; te entrega el pescado ya cocinado, servido, con la mesa puesta. Es un banquete instantáneo. El problema es que producción no es una cena: es una tormenta en alta mar. Y cuando la red se rompe, cuando el motor falla, cuando entra agua por un costado que nadie previó, no necesitas más pescado —necesitas saber pescar. Ese saber es el 30%. No se genera, se ejerce. Por eso el senior y el principiante viven el mismo momento de maneras opuestas: para el senior, el 70% de la IA es un borrador rápido sobre el que aplica su criterio; para el principiante, ese mismo 70% es una caja negra que casi funciona, y "casi funciona" en software es el lugar más peligroso del mundo, porque parece terminado y no lo está.
Por qué la demo brilla y producción tropieza
Aquí conecta con algo que venimos diciendo hace tiempo. El vibe coding —construir a puro instinto conversacional con la IA— es espectacular en la demo precisamente porque la demo vive en el 70%: el camino feliz, el usuario que hace exactamente lo que esperabas, los datos limpios. Producción es lo contrario: es el 30% multiplicado por miles de usuarios reales haciendo cosas que jamás imaginaste. Ya habíamos puesto números a la brecha entre la demo y la realidad en nuestro ensayo sobre la matemática del 27% —cuánto se desploma el rendimiento entre el laboratorio y el mundo—; el problema del 70% es la otra cara de esa misma moneda, vista desde el lado de la construcción en lugar del rendimiento. Uno mide cuánto cae la IA al salir del laboratorio; el otro explica exactamente en qué parte del trabajo cae. Ambos apuntan al mismo abismo: la distancia entre "funciona en mi pantalla" y "aguanta en el mundo".
Lo que Osmani sí propone (y lo que no)
Conviene ser honesto con la fuente, porque en internet a Osmani le atribuyen curas que él no recetó. Su respuesta al problema del 70% no es una metodología rígida de especificaciones por adelantado; es un puñado de hábitos de convivencia con la IA. El primero, tratar la salida de la IA como un "primer borrador", nunca como la versión final. El segundo, la "conversación constante": iterar en diálogo, corregir el rumbo turno a turno en vez de aceptar el primer output. Y el tercero, el que lo resume todo: "confía pero verifica". Confía en la velocidad del 70%, pero verifica cada centímetro del 30%, porque ahí es donde la IA es más convincente y más equivocada a la vez. Si buscas una disciplina más formal de especificar antes de generar, existe —Spec Kit y el spec-driven development van por ahí— pero es otra conversación, no la de Osmani. La lección de él es más simple y más portable: la velocidad de la IA no te exime de la verificación; la hace más urgente.
La lección que te puedes llevar y compartir
Quédate con este marco mental, porque no caduca aunque cambien los modelos: la IA colapsa el costo de empezar y no toca el costo de terminar. Empezar nunca fue el problema difícil del software; terminar sí. El 70% que la IA hace gratis siempre fue la parte barata —la que un buen desarrollador también hacía rápido—. El 30% que te deja solo siempre fue la parte cara, la que costaba tiempo y criterio, y sigue costándolo. Entonces la pregunta correcta ante cualquier herramienta que promete construir apps por ti no es "¿qué tan rápido llega al 70%?" —todas llegan rápido, esa carrera está ganada y es aburrida—. La pregunta es "¿qué hace con el 30%?". Quien te vende el 100% automático te está vendiendo la demo y escondiendo la tormenta.
Cómo lo vemos nosotros
En NeuralOS no fingimos que el 30% no existe; construimos alrededor de él. Por eso la plataforma no termina donde termina la generación: el motor de Automations es resumible, con esperas durables y checkpoints, precisamente porque los procesos reales se caen a la mitad y hay que retomarlos sin corromper nada —ese es territorio del 30%. Por eso las integraciones guardan sus credenciales en un vault cifrado por-tenant en lugar de dejarlas sueltas, y por eso trabajamos con disciplina de verificación y pruebas de humo sobre las rutas que manejan dinero: no porque sea glamoroso, sino porque es exactamente el 30% donde el software vive o muere. Nuestra apuesta es la contraria a la del humo: la IA te lleva volando al prototipo, y nosotros nos tomamos en serio el tramo aburrido y decisivo que viene después. Confía en la velocidad. Pero el criterio —el poner límites, el verificar, el que aguante en producción— eso no se delega. Se sistematiza. Y esa es toda la diferencia entre una demo que aplaude tu círculo y un producto que sobrevive a tus usuarios.