Torras.ai

He estado trabajando con un cliente en un nuevo proyecto de software. Dedicamos tiempo a hablar sobre el problema, entender el flujo de trabajo y diseñar lo que debía hacer el sistema final.

En algunos momentos me pregunté si avanzábamos demasiado despacio. En tecnología es fácil sentir que cada semana dedicada a pensar es una semana perdida. Alguien puede lanzarse antes. El mercado puede cambiar. La oportunidad puede desaparecer.

Entonces ocurrió algo inesperado.

Cuando estuvimos listos para construir, las herramientas habían cambiado. Podía trabajar con Codex utilizando GPT-5.6 Sol, conectarlo a Chrome, permitirle operar aplicaciones de escritorio mediante Computer Use y darle acceso a una parte mayor del entorno donde se realiza el trabajo real. Tareas que antes habrían requerido integraciones a medida, mucho código de interfaz y numerosos pasos manuales se volvieron mucho más directas.

Habíamos empezado más tarde. Pero, de repente, parecía posible terminar antes.

Suena contradictorio. También es una buena descripción del momento tecnológico que estamos viviendo.

Por qué la segunda nave espacial llega primero

Imaginemos que la humanidad quiere llegar a un planeta lejano.

Podríamos lanzar hoy una nave espacial utilizando el mejor sistema de propulsión disponible. Empezaría el viaje de inmediato y obtendría una valiosa ventaja.

Pero supongamos que esperamos diez años. Durante ese tiempo, la tecnología de propulsión mejora de forma espectacular. Lanzamos una segunda nave que viaja mucho más rápido que la primera. La adelanta en algún punto entre la Tierra y el destino y llega al planeta años antes.

La primera nave salió antes. La segunda llegó antes.

No se trata solo de un experimento mental de ciencia ficción. Se ha estudiado como el cálculo de espera, también descrito como la trampa de incentivos del progreso. La pregunta es si conviene más partir con la tecnología disponible hoy o esperar una tecnología más rápida que pueda reducir el tiempo total hasta el destino.

Un estudio posterior amplió el cálculo a los viajes relativistas y lo aplicó a posibles misiones interestelares. La pregunta central era la misma: ¿podría una nave lanzada más tarde adelantar a una misión anterior y llegar primero?

La lógica básica puede expresarse de forma sencilla:

Un lanzamiento posterior gana cuando el tiempo que ahorra la nueva tecnología es mayor que el tiempo dedicado a esperarla.

Este es el cálculo de espera de la IA.

El software ahora tiene tecnología de propulsión

Durante gran parte de la historia del software, empezar antes solía crear una ventaja duradera. Aunque las herramientas mejoraran durante el proyecto, el equipo que ya entendía el problema, había escrito el código y había llegado al mercado acumulaba algo difícil de superar.

Esa suposición es cada vez menos fiable.

La IA no se limita a acelerar un poco las tareas de programación existentes. Está cambiando qué partes de un proyecto necesitan programarse. Un agente de programación competente puede inspeccionar un repositorio, entender sus convenciones, editar varios archivos, ejecutar pruebas, diagnosticar fallos y verificar el resultado. La conexión con Chrome le permite trabajar con sitios web y con el contexto de sesiones iniciadas en el navegador. Computer Use amplía ese alcance a las aplicaciones gráficas cuando las herramientas de línea de comandos y las integraciones estructuradas no son suficientes.

Cada una de estas capacidades cambia la economía de la implementación.

Una integración que antes requería una API, un flujo de autenticación, un proceso de sincronización, gestión de errores y una interfaz propia puede comenzar ahora con un agente que utiliza la aplicación existente. Una funcionalidad que antes exigía semanas de programación puede convertirse en una tarea bien definida, completada y probada en días. Un prototipo cuyo coste era difícil de justificar puede resultar lo bastante barato como para construirlo simplemente para aprender.

La nueva nave no solo es más rápida. Puede necesitar menos infraestructura para llegar al mismo destino.

Pensar formaba parte del viaje

Existe una diferencia importante entre iniciar el proyecto e iniciar la implementación.

Las conversaciones con mi cliente no fueron una espera pasiva. Estábamos identificando el verdadero destino. Decidíamos qué problemas importaban, qué pasos podían automatizarse, dónde debía mantenerse el criterio humano y cómo sería un resultado útil.

Ese conocimiento no quedó obsoleto cuando cambió la tecnología. Se volvió más valioso porque las nuevas herramientas podían actuar sobre él con mayor rapidez.

Si hubiéramos empezado a programar de inmediato, podríamos haber incorporado supuestos a la arquitectura antes de entender el flujo de trabajo. También podríamos haber creado mecanismos a medida para problemas que las nuevas herramientas de IA ahora pueden resolver directamente. Empezar antes habría producido más código, pero no necesariamente un resultado más temprano.

Esto conduce a un principio que considero cada vez más apropiado para los proyectos de IA:

Empieza a aprender pronto. Comprométete tarde.

Empieza cuanto antes con el descubrimiento de las necesidades del cliente, el mapeo de procesos, la preparación de datos, el análisis de riesgos y la definición de métricas de éxito. Estas actividades aclaran el destino y suelen conservar su valor.

Hay que ser más prudente con los compromisos grandes, rígidos y dependientes de una tecnología concreta. Cuando las capacidades subyacentes avanzan rápidamente, una arquitectura diseñada demasiado pronto puede convertirse en la nave lenta que más adelante adelanta un sistema más sencillo.

La primera nave no siempre es inútil

Existe una interpretación tentadora, pero peligrosa, del cálculo de espera: no construir nunca nada porque siempre aparecerá una herramienta mejor.

Esa es la trampa de los incentivos.

Si seguimos esa lógica para siempre, ninguna nave abandona la Tierra. Siempre habrá otro modelo, otro framework y otra capacidad en el horizonte.

Los primeros sistemas también pueden generar valor aunque finalmente sean superados. Un prototipo puede revelar un requisito oculto. Un flujo manual puede generar ejemplos de entrenamiento. Un lanzamiento limitado puede crear confianza entre los usuarios. Una integración imperfecta puede descubrir el verdadero cuello de botella operativo.

En ese sentido, la primera nave puede enviar información valiosa de vuelta a la Tierra.

El error no consiste en lanzar pronto. Consiste en tratar cada lanzamiento inicial como si fuera el vehículo definitivo.

Durante periodos de cambio rápido, las primeras versiones deben diseñarse como sondas: pequeñas, reversibles y construidas para producir conocimiento. Deben ayudarnos a decidir qué merece un compromiso mayor. La nave generacional viene después.

Un cálculo de espera práctico para proyectos de IA

No podemos predecir el ritmo exacto del desarrollo de la IA, pero sí podemos formular mejores preguntas antes de comprometernos con una implementación:

• ¿Está claro el destino? Si el problema del cliente sigue siendo impreciso, una tecnología mejor no salvará el proyecto.
• ¿A qué velocidad mejora la tecnología que lo hace posible? Esperar importa más cuando una capacidad que falta se está volviendo claramente más barata, fiable o fácil de integrar.
• ¿Qué podemos aprender ahora? Las entrevistas, los prototipos, los experimentos y la recopilación de datos pueden generar progreso sin atarnos a una arquitectura.
• ¿Hasta qué punto es reversible la decisión? Un pequeño prototipo es fácil de sustituir. Una gran plataforma a medida, una migración o un contrato plurianual no lo son.
• ¿Medimos el esfuerzo o la llegada? Empezar antes el desarrollo puede aumentar la cantidad de trabajo realizado y, al mismo tiempo, retrasar el momento en que el cliente obtiene el resultado deseado.

La última pregunta es la más importante. Los equipos de software miden de forma natural la actividad: requisitos escritos, tareas cerradas, integraciones completadas y líneas de código publicadas. A los clientes les importa la llegada.

¿El flujo de trabajo se hizo más rápido? ¿Disminuyeron los errores? ¿Aumentaron los ingresos? ¿Las personas dejaron de realizar tareas que un sistema podía asumir? ¿La empresa obtuvo una capacidad que antes no tenía?

Un proyecto posterior que alcanza antes esos resultados es el proyecto más rápido.

Competir con una nave que todavía no ha despegado

La incómoda realidad es que todo producto de IA compite ahora, en parte, con la tecnología futura.

Un equipo puede pasar un año construyendo una funcionalidad especializada y descubrir después que un modelo general adquiere la misma capacidad. Una interfaz diseñada con cuidado puede dejar de ser necesaria cuando un agente puede operar la aplicación original. Una capa de integración compleja puede perder valor cuando las herramientas pueden moverse de forma segura entre sistemas en nombre del usuario.

Esto no significa que las empresas de software deban dejar de construir. Significa que deben construir allí donde el valor sea más duradero: contexto propio, relaciones con los clientes, flujos de trabajo de confianza, distribución, conocimiento del sector, sistemas de evaluación y una comprensión precisa del resultado.

La implementación debe ser lo bastante modular como para sustituir su motor cuando aparezca uno más rápido.

En mi proyecto con el cliente, empezar más tarde no significó no hacer nada. Significó que, cuando finalmente despegamos, teníamos un destino más claro y una nave mucho más rápida.

Esa es la oportunidad que crea el cálculo de espera de la IA. El objetivo no es esperar el máximo tiempo posible, ni tampoco construir lo antes posible.

Es reconocer el momento en que esperar deja de acortar el viaje y empieza a retrasarlo.

Empieza a aprender pronto. Mantén pequeños los primeros experimentos. Conserva lo que es duradero. Retrasa las decisiones irreversibles. Y cuando la tecnología sea lo bastante capaz y el destino esté claro, lánzate.

En un mundo de tecnología acelerada, quien se mueve primero no siempre es quien llega primero.