Ideia principal

Pilotar o Codex a partir de um celular conectado ao Mac que o executa resolve o problema aparente — trabalhamos sem estar na frente da máquina — e deixa três intactos: é preciso que o Mac esteja ligado, que ele continue conectado e que o acesso remoto funcione. A mobilidade obtida é uma mobilidade condicional, e as condições dela ficam a várias centenas de quilômetros, sem ninguém por perto para restabelecê-las.

Em casa, a diferença não aparece: as três condições estão quase sempre reunidas, e o acesso remoto passa por solução. Ela só se revela numa viagem longa, onde a pane não dá para recuperar e onde o dia de trabalho está perdido.

A única forma de suspender a dependência, portanto, não era acessar melhor a máquina, era tirá-la da equação.

Por que isso importa

Isso dá uma forma de ler as soluções de acesso remoto em geral: elas convertem uma restrição de presença em restrição de disponibilidade. É uma boa troca quando a disponibilidade é administrada por alguém — um servidor, um serviço — e uma troca ruim quando ela repousa sobre um aparelho pessoal que ninguém vigia.

E isso evita um diagnóstico frequente: acreditar que resolvemos um problema de autonomia porque resolvemos um problema de acesso.

Nuances e limites

Tirar a máquina se paga: o sistema que a substitui é mais lento e não sabe executar scripts. Suspender uma dependência raramente é uma troca por nada.

E a demonstração só vale para uma máquina pessoal. A mesma arquitetura hospedada num serviço administrado sustenta as três condições por contrato, e o acesso remoto volta a ser uma resposta legítima.

Questões em aberto

• Como estimar, antes de viajar, a probabilidade de que uma das três condições caia durante a ausência, já que nenhuma delas é instrumentada?