Software reativo foi um desvio de 40 anos
O software aprendeu a esperar, por um clique, uma consulta, um prompt. A próxima plataforma não espera, porque o trabalho não espera.
Apollo Space Research
Apollo Space
Um mainframe em 1959 não esperava por você. Você entregava um maço de cartões perfurados, ia embora, e voltava horas depois pra pegar o resultado. A máquina rodava no relógio dela, mastigando a fila enquanto você dormia. Aí a gente tornou os computadores interativos, e eles ficaram mais rápidos, e mais amigáveis, e ensinamos a eles um hábito que nunca tinham tido antes: ficar perfeitamente parados até um humano cutucar. Sessenta anos depois, esse hábito tem um preço. O software mais caro da sua empresa passa quase toda a vida dele sem fazer nada, esperando alguém lembrar que ele existe.
Isso deveria ser progresso. Achamos que foi uma curva errada.
O software aprendeu a esperar, por um clique, uma consulta, um prompt. A próxima plataforma não espera, porque o trabalho não espera.
O arco que ninguém nomeia
A gente conta a história da computação como uma marcha rumo à velocidade, e essa parte é verdade. Mas tem um segundo arco por baixo, sobre quem começa a conversa, e nesse eixo a linha não é reta. Ela dobra pra trás.
O batch veio primeiro. Nos anos 1950 e início dos 1960, um computador rodava tarefas de uma fila sem nenhum humano no meio do caminho, você submetia o trabalho e a máquina decidia quando fazer (Wikipedia: Batch processing). Era desajeitado e lento, mas repare no formato: a máquina tinha iniciativa. Ela trabalhava sem você ali em cima.
Aí veio a computação interativa. O time-sharing surgiu no início dos anos 1960 e virou o modelo dominante nos anos 1970, deixando muita gente usar uma mesma máquina por um terminal e ter uma resposta enquanto digitava (Computer History Museum: Timesharing). Foi um salto genuíno, os computadores pararam de te fazer esperar horas. Mas, em silêncio, isso reconectou a relação. Agora o humano dirigia cada interação. A máquina respondia; ela não iniciava mais.
A gente continuou otimizando aquele único movimento, a resposta, por cinquenta anos. Terminais mais rápidos, depois desktops, depois a web, depois o celular, depois a caixa de chat. Cada geração deixou o perguntar → responder mais polido. Nenhuma delas questionou se perguntar → responder era o loop certo pra começar.
O desvio, nomeado
Eis o loop que a gente acabou idolatrando. Você percebe que algo precisa ser feito. Você abre o app. Você pergunta. Ele responde. Aí ele apaga de novo até a próxima vez que você perceber.
O fardo inteiro de perceber fica em cima do humano. Sempre.
Esse é o clássico modelo requisição-resposta, e a descrição de livro-texto dele é, sem querer, condenatória: o cliente envia uma requisição e então trava, ele não faz mais nada até o servidor responder (GeeksforGeeks: Request-driven vs Event-driven). Construímos uma indústria inteira sobre um software que, por projeto, espera. A gente chamou a espera de “responsividade” e entregou isso por quarenta anos.
A visão ingênua diz que é só assim que o software funciona: uma ferramenta fica inerte até uma pessoa usar, do jeito que um martelo fica. Isso parece obviamente verdade. Um martelo que se balançasse sozinho seria assustador.
Mas software não é martelo, e tratar como martelo é exatamente a falha. Um martelo não faz ideia de que existe um prego. O seu software faz, ele já consegue ver a agenda, a caixa de entrada, a fatura não paga, o contrato que venceu na terça. Ele está sentado em cima da informação que deveria disparar o trabalho, e não faz nada com ela, porque a gente treinou ele pra esperar ser perguntado. O custo não aparece em nenhum momento específico. É o imposto acumulado de cada tarefa que precisava ser feita enquanto o único sistema que conseguia enxergá-la estava ocioso, esperando educadamente um humano digitar a pergunta.
O software aprendeu a esperar, por um clique, uma consulta, um prompt. A próxima plataforma não espera, porque o trabalho não espera.
O que “não espera” realmente significa
Então imagine a correção. Não uma caixa de resposta mais esperta. Um loop completamente diferente.
O loop reativo tem um buraco, e o buraco é a parte mais importante: entre “o trabalho precisa ser feito” e “você abre o app”, existe uma lacuna onde nada acontece e só um humano consegue fechar. Cada bola perdida na sua empresa mora nessa lacuna.
O loop proativo apaga a lacuna. O sistema está sempre rodando, é a velha iniciativa da máquina batch, de volta. Ele observa o seu mundo num lugar só. Quando algo muda, ele percebe, sem ser pedido. Pras coisinhas em que ele conquistou confiança, ele simplesmente age e te avisa depois; pro resto, ele rascunha o movimento e espera um instante o seu aval. Aí ele volta a observar. Não existe um estado de “apagar”, porque o trabalho nunca apaga.
A objeção ingênua aqui é óbvia e vale levar a sério: software que age por conta própria não é só um robô esperando pra fazer a coisa errada em escala? Esse é o medo real, e a resposta não é deixar ele mais esperto. É fazer ele conquistar o direito de agir, do jeito que um funcionário novo faz, só leitura primeiro, depois rascunha-e-confirma, depois envia-e-avisa, e só no fim, pros movimentos que ele acertou cem vezes, age-e-reporta. Iniciativa sem coleira é imprudente. Iniciativa numa coleira que se alonga com prova é só um bom colega.
Mesma informação dos dois lados. O app reativo tem a agenda e a mensagem e fica calado. O sistema proativo tem a mesma agenda e a mesma mensagem, percebe que elas discordam, e fala antes de alguém dirigir pro prédio errado. A diferença nunca foi inteligência. Foi quem estava acordado.
Por que o desvio durou quarenta anos
É justo perguntar: se esperar era o loop errado, por que os melhores engenheiros da Terra o construíram por duas gerações?
Porque, na maior parte desses quarenta anos, ele era o loop certo, o software genuinamente não dava pra confiar na hora de decidir o que fazer. Ele não tinha julgamento. Um programa que agisse sozinho agiria de forma burra, então sabiamente a gente o confinou a responder exatamente a pergunta que recebia. Reativo não era preguiça. Era uma resposta correta a máquinas que não conseguiam raciocinar.
Essa restrição é justamente a coisa que acabou de mudar. O motivo de “esperar ser perguntado” ser seguro é que o software não conseguia distinguir sinal de ruído. Agora ele consegue, bem o bastante pra ler uma caixa de entrada e saber quais três de quarenta mensagens importam, bem o bastante pra ver uma reunião remarcada e um convite desatualizado e perceber que eles se contradizem. No momento em que o software consegue julgar, o motivo original do desvio evapora. Manter o loop-de-espera depois disso não é mais cautela. É hábito.
O software aprendeu a esperar, por um clique, uma consulta, um prompt. A próxima plataforma não espera, porque o trabalho não espera.
A virada: pare de ser o gatilho
Eis o que o desvio custou de verdade, e não se mede em software.
Por quarenta anos, você foi a peça que faltava em cada loop reativo. Você é quem tem que perceber o trabalho, lembrar da ferramenta, abrir e perguntar. Reduza isso ao essencial e vira uma descrição de cargo estranha: uma pessoa brilhante, passando a maior parte do dia sendo o gatilho de um software que poderia ter se disparado sozinho. Perceber é a coisa de menor alavancagem que uma mente humana pode fazer, e a gente construiu cada sistema da empresa pra depender disso.
A correção devolve esse trabalho pra máquina, a única parte em que ela sempre foi melhor. Vigilância é exatamente aquilo em que uma pessoa é pior e um sistema sempre-ligado é melhor. Quando o perceber sai de cima de você, o que sobra é a parte que sempre foi sua: decidir o que vale a pena fazer, o que “bom” significa, quais problemas merecem a atenção da empresa afinal. Isso não é algo que nenhum escalonador faz por você. E é, convenientemente, a única parte que algum dia mereceu a sua atenção inteira.
A máquina batch em 1959 rodava sem você e não precisava ser pedida. A gente passou quarenta anos ensinando o software a esperar, porque por quarenta anos ele tinha que esperar. Não tem mais.
A gente está construindo essa correção na Apollo Space, um sistema operacional para a sua empresa que observa, percebe e fala primeiro, pra que o trabalho pare de esperar você lembrar dele. Se você passou a carreira sendo o gatilho, talvez seja hora de voltar a ser o fundador.
A Apollo cuida da operação repetitiva da sua empresa pro seu time não precisar.
Entre na lista de espera: acesso antecipado, preço de usuário fundador e um lugar na primeira fila enquanto a gente constrói.
Entrar na lista de esperaPromoções estão mortas. Trust budgets as substituem.
Você não vai promover um agent; você vai ampliar seu trust budget uma tarefa verificada por vez, e o mesmo livro-razão deveria governar suas pessoas.
Tese de AutomaçãoA descrição de cargo está virando um arquivo de spec
Para um agent, um cargo vira uma spec versionada e testável, e isso muda como você desenha cada trabalho, inclusive os humanos.
Tese de AutomaçãoPare de medir output. Comece a medir outcomes que a empresa não pode esquecer.
Um OS que lembra de toda decisão e seu resultado deixa você avaliar o outcome, não a atividade.