O Que Ainda Perguntamos Uns aos Outros

Algo mudou naquilo que os programadores perguntam uns aos outros, e comecei por o notar no meu próprio comportamento. Durante mais de uma década, entre equipas de grandes empresas e startups, as perguntas que circulavam entre pessoas eram dominadas pela mecânica. Porque é que este regex não faz match. O que é que este erro quer mesmo dizer. Como é que ponho estas duas bibliotecas de acordo numa versão. Fazia-as, respondia-lhes, e algures nos últimos dois anos deixei de fazer ambas as coisas, porque agora uma máquina responde-lhes em segundos, a qualquer hora, sem fazer com que ninguém se sinta pequeno por perguntar. As perguntas que ainda passam entre pessoas tornaram-se mais raras, e tornaram-se mais pesadas.

Não tenho saudades do tráfego antigo. Responder à mesma pergunta mecânica pela quadragésima vez nunca foi a parte boa desta profissão, e ter uma máquina incansável a absorvê-la é uma dádiva. Mas observar que perguntas ainda atravessam o espaço entre pessoas, depois de tudo o resto ter deixado de precisar de o atravessar, ensinou-me algo sobre para onde se está a mover o valor de um programador. Três tipos ainda fazem a viagem, e não são igualmente duráveis.

Mais recente do que o treino do modelo

O primeiro tipo nasce mais depressa do que qualquer modelo consegue aprender. Uma release sai na terça-feira e, na quarta, já se está a partir de formas que ninguém documentou, porque ninguém viveu com ela tempo suficiente para as documentar. Escrevo código com dois modelos diferentes, todos os dias, e no momento em que uma ferramenta se atualiza por baixo de mim, ambos passam de sábios a adivinhos confiantes sem mudarem de tom. Reconhecer essa mudança é hoje uma competência.

A objeção óbvia é que os modelos navegam. Conseguem ir buscar release notes e threads de issues a pedido, e isso estreitou consideravelmente esta janela. Mas o retrieval lê texto, e nos primeiros dias depois de algo se partir, o texto ainda não existe. O conhecimento vive na cabeça das cinquenta pessoas que bateram na mesma parede na mesma semana, e nas mensagens que trocam assim que se encontram. Durante esses poucos dias, essas pessoas são o único sítio onde a resposta existe. Tudo o que a máquina virá a saber sobre o problema tem de passar primeiro por elas, porque alguém tem de pôr a coisa por escrito antes de haver algo para recuperar. A janela continua a estreitar-se, mas cada release volta a abri-la do zero, e por isso as perguntas que vivem dentro dela continuam a precisar de uma pessoa. Só que nunca da mesma pessoa por muito tempo.

Mais fundo do que uma resposta plausível

O segundo tipo desce em vez de avançar. O canto escuro de um compilador. O parágrafo de uma especificação que duas implementações leem de maneira diferente. A pergunta em que uma resposta plausível é inútil, porque o que é preciso é uma resposta comprovadamente correta, com proveniência, vinda de alguém que consegue apontar para a cláusula exata que a decide. Quando alguém pergunta porque é que o otimizador pode reordenar aquelas duas escritas, não está a pedir um parágrafo que soe a documentação. Está a pedir o memory model, capítulo e versículo.

Convém dizer onde estou nisto, porque joga contra mim. Passei boa parte dos últimos anos a trabalhar em sistemas de retrieval para os domínios jurídico e da saúde, onde uma resposta que não consegue mostrar a fonte não vale nada, soe ao que soar, e todo o esforço de engenharia vai para prender cada afirmação ao documento em que assenta. Esse trabalho é uma aposta em que esta categoria pode ser automatizada, e a aposta está a correr bem. Uma máquina que responde com a cláusula exata anexada não é uma fantasia; é mais ou menos a descrição do meu trabalho. Por isso, dos três tipos, este é o que espero que continue a encolher. O especialista que sabe a especificação de trás para a frente vai manter a vantagem nos cantos onde os documentos se contradizem, e nas perguntas que os documentos nunca anteciparam. Mas não vou assentar um ensaio num fosso que passo os dias de trabalho a drenar.

A pergunta que é sobre ti

O terceiro tipo é o que soa menos técnico e revela-se o mais durável. Olha para o meu projeto. Qual destas ferramentas para a minha equipa, dado o nosso codebase e o nosso prazo e as duas pessoas que vão mesmo manter isto. O que farias tu.

Faz estas perguntas a um modelo e recebes algo genuinamente útil, um levantamento do espaço de opções com todos os tradeoffs expostos. Insiste mais e ele até escolhe uma, portanto não vou fingir que a máquina se recusa a decidir. O que ela não consegue é pesar os tradeoffs como a consequência vivida os pesa, e acho que a razão é concreta e não mística. O registo escrito com que a máquina aprendeu está enviesado. As falhas dramáticas têm postmortems; as lentas não. Ninguém escreve um relatório de incidente intitulado "esta biblioteca era ligeiramente errada para a nossa equipa e custou-nos três horas por semana durante dois anos". A pessoa que manteve aquilo que um dia recomendou carrega exatamente esses dados em falta: que tradeoffs do levantamento morderam mesmo, com que força, e quanto tempo durou a nódoa negra. Quando essa pessoa colapsa o espaço de opções numa decisão para a tua situação, são esses dados em falta que fazem o colapso.

Há uma leitura menos lisonjeira de tudo isto, e concedo parte dela. Algumas pessoas que perguntam "o que farias tu" querem mais cobertura do que conselho, um nome para onde apontar se a escolha correr mal. Mas até isso é uma exigência que nenhuma máquina pode satisfazer, porque não se pode apontar para um modelo. E a versão melhor do mesmo instinto é sólida. Querem que a decisão venha de alguém que paga algum preço por estar errado, nem que seja em reputação, porque uma recomendação que não custa nada a quem a faz é fácil de fazer sem cuidado.

A inversão

Portanto a máquina ficou com o meio. O arquivo inteiro de mecânica resolvida jorra agora de um prompt, instantaneamente, e de onde estou, o tráfego dessas perguntas entre pessoas reduziu-se a quase nada. O que ainda circula pende fortemente para o último tipo, os pedidos de gosto e recomendação e discernimento.

É uma inversão que vale a pena deixar assentar, porque a nossa cultura treinou os programadores para tratar exatamente essas perguntas como menores. Perguntavas o que alguém escolheria, e o reflexo era descartar isso como mera opinião, não uma pergunta a sério, já que não tinha resposta verificável. O reflexo fazia um certo sentido. Reservávamos as decisões subjetivas para as pessoas que pagávamos para as tomar, os tech leads e os arquitetos, e entre pares valorizávamos as perguntas que a evidência conseguia resolver.

As perguntas que a evidência consegue resolver são agora resolvidas por uma máquina antes sequer de chegarem a uma pessoa. O que resta é o tipo sem resposta verificável, o tipo que costumava ser descartado. Passou de ruído no canal a ser a maior parte do que o canal transporta. E as pessoas que ainda fazem essas perguntas não estão confusas sobre como isto funciona. Identificaram corretamente aquilo que não conseguem obter de um prompt, e estão a perguntar no único sítio onde existe.

Torna-te alguém a quem vale a pena perguntar

Devo dizer de que lado estou. Construo parte da maquinaria do lado barato desta troca, ferramentas que geram código e respostas o dia todo, e todas elas terminam num humano que tem de tomar uma decisão que a ferramenta não pode tomar por ele. Quando digo que o valor se moveu para a pessoa disposta a tomar a decisão, estou a descrever o ponto exato onde as minhas próprias ferramentas param.

Para um programador, a pergunta prática segue-se diretamente. És alguém a quem vale a pena perguntar? Há um canto desta área onde viveste com as tuas próprias escolhas tempo suficiente para que a tua decisão aí valha alguma coisa?

E quando a pergunta chegar, responde com o raciocínio, não só com o veredicto. Um veredicto fica velho com a release seguinte, e é a única parte da tua resposta que quem pergunta podia ter pedido a um prompt. O que não pode pedir a um prompt é a ponderação: como comparaste as opções, o que te custou quando escolheste mal, ao que estarias atento agora. Entregar isso é o que torna melhor quem pergunta, e um dia torna-o também alguém a quem vale a pena perguntar.

Não vou afirmar que esta janela dura para sempre. Todas as outras janelas desta história se moveram, e esta pode mover-se também. Mas hoje, quando alguém te traz o projeto e pergunta o que farias, repara no que aconteceu. Tinha uma máquina que responde a tudo, e ainda assim trouxe a pergunta a ti. Leva-a a sério, e responde com as tuas razões à vista.