Participei na primeira Cimeira Pragmática no início deste ano e, enquanto lá fui anfitrião
Gergely Orosz entrevistou Kent Beck e eu no palco. O vídeo dura cerca de meia hora.
Sempre gosto de conversar com Kent assim, e Gergely abordou alguns tópicos interessantes. Dado o momento, a IA dominou a conversa – comparámo-la com mudanças tecnológicas anteriores, a experiência de métodos ágeis, o papel do TDD, o perigo de métricas de desempenho prejudiciais e como prosperar numa indústria nativa da IA.
❄ ❄ ❄ ❄ ❄
Perl é uma linguagem que usei um pouco, mas nunca amei. No entanto, o livro definitivo sobre o assunto, escrito por seu designer Larry Wall, contém uma joia maravilhosa. As três virtudes de um programador: arrogância, impaciência – e acima de tudo – preguiça.
Bryan Cantrill também adora essa virtude:
Dessas virtudes, sempre achei a preguiça a mais profunda: embalado em sua autodepreciação irônica está um comentário não apenas sobre a necessidade de abstração, mas também sobre sua estética. A preguiça nos leva a tornar o sistema o mais simples possível (mas não mais simples!) — a desenvolver abstrações poderosas que nos permitem fazer muito mais, com muito mais facilidade.
Claro, a piscadela implícita aqui é que é preciso muito trabalho para ser preguiçoso
Compreender como pensar sobre um domínio de problema construindo abstrações (modelos) é minha parte favorita da programação. Adoro porque acho que é o que me dá uma compreensão mais profunda do domínio de um problema e porque, quando encontro um bom conjunto de abstrações, fico entusiasmado com a forma como elas fazem com que as dificuldades desapareçam, permitindo-me obter muito mais funcionalidades com menos linhas de código.
Cantrill teme que a IA seja tão boa em escrever código que corremos o risco de perder essa virtude, algo que é reforçado pelos brogrammers que se gabam de como produzem 37 mil linhas de código por dia.
O problema é que os LLMs carecem inerentemente da virtude da preguiça. O trabalho não custa nada para um LLM. Os LLMs não sentem necessidade de otimizar seu próprio tempo futuro (ou de qualquer pessoa) e ficarão felizes em despejar cada vez mais em um bolo de lixo. Se não forem controlados, os LLMs tornarão os sistemas maiores, e não melhores – apelando para métricas perversas de vaidade, talvez, mas ao custo de tudo o que importa. Como tal, os LLMs destacam o quão essencial é a nossa preguiça humana: o nosso tempo finito obriga-nos a desenvolver abstrações nítidas, em parte porque não queremos desperdiçar o nosso tempo (humano!) com as consequências de abstrações desajeitadas. A melhor engenharia sempre nasce de restrições, e as restrições do nosso tempo impõem limites à carga cognitiva do sistema que estamos dispostos a aceitar. É isto que nos leva a tornar o sistema mais simples, apesar da sua complexidade essencial.
Esta reflexão impressionou-me particularmente neste domingo à noite. Passei um pouco de tempo fazendo uma modificação no funcionamento do meu gerador de playlist de músicas. Eu precisava de um novo recurso, passei algum tempo adicionando-o, fiquei frustrado com o tempo que estava demorando e pensei em talvez lançar um agente de codificação nele. Mais reflexão me levou a perceber que eu estava fazendo isso de uma forma mais complicada do que o necessário. Eu estava incluindo uma instalação que não precisava, e aplicando yagnieu poderia tornar tudo muito mais fácil, executando a tarefa em apenas algumas dezenas de linhas de código.
Se eu tivesse usado um LLM para isso, ele poderia ter feito a tarefa muito mais rapidamente, mas teria causado uma complicação excessiva semelhante? Se sim, eu apenas daria de ombros e diria LGTM? Essa complicação causaria problemas a mim (ou ao LLM) no futuro?
❄ ❄ ❄ ❄ ❄
Jessica Kerr (Jessitron) tem um exemplo simples de aplicando o princípio do Desenvolvimento Orientado a Testes para agentes alertadores. Ela deseja que todas as atualizações incluam a atualização da documentação.
Instruções – Podemos alterar AGENTS.md para instruir nosso agente de codificação a procurar arquivos de documentação e atualizá-los.
Verificação – Podemos adicionar um agente revisor para verificar cada PR em busca de atualizações de documentação perdidas.
São duas mudanças, então posso dividir este trabalho em duas partes. Qual destes devemos fazer primeiro?
É claro que meu comentário inicial sobre TDD responde a essa pergunta
❄ ❄ ❄ ❄ ❄
Mark Little estimulou uma antiga memória minha enquanto pensava em trabalhar com IAs que são excessivamente confiantes em seu conhecimento e, portanto, propensas a inventar respostas a perguntas ou a agir quando deveriam estar mais hesitantes. Ele se inspira em um filme de ficção científica antigo, de baixo orçamento, mas clássico: Estrela Negra. Eu vi esse filme uma vez, quando tinha 20 anos (ou seja, há muito tempo), mas ainda me lembro da cena de crise em que um membro da equipe tem que usar argumento filosófico para impedir a detonação de uma bomba senciente.
Doolittle: Você não tem provas absolutas de que o Sargento Pinback ordenou que você detonasse.
Bomba nº 20: Lembro-me claramente da ordem de detonação. Minha memória é boa para assuntos como esses.
Doolittle: Claro que você se lembra disso, mas tudo o que você lembra é apenas uma série de impulsos sensoriais que agora você percebe que não têm nenhuma conexão actual e definida com a realidade externa.
Bomba nº 20: Verdade. Mas como é assim, não tenho nenhuma prova actual de que você está me contando tudo isso.
Doolittle: Isso não vem ao caso. Quero dizer, o conceito é válido não importa onde se origine.
Bomba #20: Hmmmm….
Doolittle: Então, se você detonar…
Bomba nº 20: Em nove segundos….
Doolittle:…você poderia estar fazendo isso com base em dados falsos.
Bomba nº 20: não tenho provas de que sejam dados falsos.
Doolittle: Você não tem provas de que os dados estejam corretos!
Bomba #20: Preciso pensar mais sobre isso.
Doolittle tem que expandir a consciência da bomba, ensinando-a a duvidar dos seus sensores. Como diz Little:
Essa é uma metáfora útil para saber onde estamos hoje com a IA. A maioria dos sistemas de IA são otimizados para serem decisivos. Dada uma entrada, produza uma saída. Dada a ambigüidade, resolva-a probabilisticamente. Dada a incerteza, inferir. Isto funciona bem em domínios limitados, mas falha em sistemas abertos onde o custo de uma decisão errada é assimétrico ou irreversível. Nesses casos, o comportamento correto é muitas vezes o adiamento ou mesmo a inação deliberada. Mas a inação não é um resultado pure da maioria das arquiteturas de IA. Tem que ser projetado.
Nas minhas interações mais humanas, sempre valorizei a dúvida e desconfiei das pessoas que operam sob uma certeza indevida. A dúvida não leva necessariamente à indecisão, mas sugere que incluímos o risco de informações imprecisas ou de raciocínio equivocado em decisões com consequências profundas.
Se quisermos sistemas de IA que possam operar com segurança sem supervisão humana constante, precisamos ensiná-los não apenas como decidir, mas também quando não decidir. Num mundo de crescente autonomia, a restrição não é uma limitação, é uma capacidade. E em muitos casos, pode ser o mais importante que construímos.