Idea principal

Pilotar Codex desde un teléfono conectándose al Mac que lo ejecuta resuelve el problema aparente — se trabaja sin estar delante de la máquina — y deja otros tres intactos: hace falta que el Mac esté encendido, que siga conectado y que el acceso remoto funcione. La movilidad obtenida es una movilidad condicional, y sus condiciones se quedan a varios centenares de kilómetros, sin nadie que las restablezca.

En casa, la diferencia no se ve: las tres condiciones se cumplen casi siempre, y el acceso remoto pasa por ser una solución. Solo se revela en un desplazamiento largo, ahí donde la avería no se puede recuperar y donde se pierde la jornada de trabajo.

La única manera de levantar la dependencia no era, por tanto, acceder mejor a la máquina, sino sacarla de la ecuación.

Por qué es importante

Esto da una forma de leer las soluciones de acceso remoto en general: convierten una restricción de presencia en una restricción de disponibilidad. Es un buen intercambio cuando la disponibilidad la administra alguien — un servidor, un servicio — y un mal intercambio cuando descansa sobre un aparato personal que nadie vigila.

Y evita un diagnóstico frecuente: creer que se ha resuelto un problema de autonomía porque se ha resuelto un problema de acceso.

Matices y límites

Sacar la máquina se paga: el sistema que la sustituye es más lento y no sabe ejecutar scripts. Levantar una dependencia rara vez se cambia por nada.

Y la demostración solo vale para una máquina personal. Una misma arquitectura alojada en un servicio administrado sostiene las tres condiciones por contrato, y el acceso remoto vuelve a ser una respuesta legítima.

Preguntas abiertas

• ¿Cómo estimar, antes de salir, la probabilidad de que una de las tres condiciones caiga durante la ausencia, si ninguna de ellas está instrumentada?