O paradigma do tempo computacional

Meu computador já poderia gerar uma imagem do meu rosto muito antes de existir IA generativa.

Bastava escolher uma resolução, definir as cores possíveis e começar a trocar os pixels. Entre todas as combinações, estaria o meu rosto. Também estaria a imagem de uma folha com um trecho de código. E qualquer outra imagem que coubesse naquela resolução.

Penso nisso há muito tempo.

O computador já conseguia representar o resultado. O problema era quanto tempo levaria pra encontrá-lo.

Com os LLMs, essa ideia começou a fazer muito mais sentido pra mim. Principalmente quando penso em como estamos aprendendo a construir software.

Todas as imagens cabem em algum lugar

Vamos simplificar: uma imagem em preto e branco, com cada pixel podendo assumir apenas dois estados. Se ela tiver 100 pixels, existem 2 elevado a 100 combinações possíveis.

É um número finito. E já é enorme.

Se eu percorrer todas as combinações, sem repetir nenhuma, vou encontrar qualquer imagem representável naquele formato. Se eu simplesmente sortear os pixels, posso repetir resultados e passar um tempo absurdamente longo sem chegar ao que quero. A possibilidade existe, mas não vem acompanhada de um prazo útil.

Ainda tem outro detalhe: gerar uma imagem de uma folha com uma informação correta não me diz, por si só, que aquela informação é verdadeira. No mesmo espaço existem todas as versões erradas.

Mesmo com essas ressalvas, a provocação continua interessante: a distância entre conseguir representar uma solução e conseguir encontrá-la pode ser medida em tempo de computação.

Uma máquina comum já consegue produzir uma quantidade gigantesca de combinações. A maior parte delas não vai servir pra nada que a gente queira fazer.

Uma busca com direção

Quando olho pra um LLM escrevendo código, vejo uma conexão com essa ideia.

Software também pode ser representado como informação. Se eu limitar o tamanho, existe um conjunto finito de sequências possíveis. Algumas são programas úteis. Muitas nem sequer fazem sentido como código.

Tentar encontrar um software sorteando bits seria impraticável.

O que um LLM traz é direção. O treinamento permite que ele proponha sequências muito mais plausíveis, levando em conta o pedido e o contexto. Na prática, ele concentra as tentativas em regiões desse espaço onde existe uma chance muito maior de encontrar algo útil.

Essa é uma forma de enxergar o processo, uma analogia. O modelo não fica enumerando todos os programas possíveis por baixo dos panos.

Mas, quando colocamos um agente pra escrever, executar, observar o resultado e tentar de novo, uma parte do desenvolvimento começa a parecer uma busca orientada.

E aí entra o tempo computacional.

Uma empresa pode gastar mais pra fazer mais tentativas, usar modelos melhores ou explorar alternativas em paralelo. Pode deixar um agente trabalhando por mais tempo em um problema que antes exigiria alguém escrevendo cada alteração.

Isso já muda a conta de quais softwares vale a pena construir.

Claro que repetir chamadas não garante que o agente vá acertar. Ele pode insistir na mesma interpretação errada. Também pode produzir algo diferente a cada tentativa. Um resultado verificável e um processo determinístico são coisas distintas: eu posso testar se um programa atende a certos critérios mesmo que o caminho usado pra gerá-lo tenha sido probabilístico.

Esse cuidado ajuda a delimitar a ideia. O ponto que me interessa é o quanto conseguimos transformar computação em tentativas úteis, até chegar a um resultado que antes custaria muito mais trabalho humano.

Minha pequena fábrica de software

Resolvi explorar isso em casa.

Montei um experimento com agentes pequenos, cada um responsável por uma parte da construção de um software. Uma espécie de miniempresa.

Usei o Paperclip pra experimentar essa organização. Peguei um site de receitas culinárias como projeto e criei um agente no papel de CEO, com uma meta: aumentar o tráfego do site. A ideia era que ele coordenasse os outros agentes, distribuindo o trabalho necessário pra chegar ao objetivo.

Estava rodando um modelo Qwen com arquitetura mixture of experts, localmente, em duas RTX 3060 de 12 GB cada.

A hipótese parecia boa: agentes específicos, tarefas menores, trabalho dividido. Cada um cuidaria de um pedaço.

Na prática, foi difícil coordenar tudo.

Um agente fazia uma coisa, outro fazia outra, e as coisas colidiam. Eles se confundiam no meio do caminho. Eu tinha dividido a execução, mas continuava precisando manter uma visão coerente do que estava sendo construído.

Depois, criei um único agente no Hermes. O resultado foi melhor.

Foi o resultado daquele experimento, com aquele modelo e aquela configuração. Ainda tenho bastante coisa pra explorar com múltiplos agentes. Mas a experiência me mostrou um custo que é fácil subestimar: quanto mais eu divido o trabalho, mais preciso cuidar de como o contexto circula entre as partes.

Mais agentes também podem significar mais computação gasta tentando se entender.

O que significa bonito?

Tem outra parte dessa história que me chama ainda mais atenção.

Quando peço pra uma pessoa fazer um software bonito, a palavra “bonito” carrega um monte de coisa que eu não expliquei.

Referências visuais. Cultura. Experiências anteriores. O tipo de produto que eu uso. Talvez a pessoa trabalhe comigo e já saiba o que eu costumo aprovar. A conversa acontece em cima de um contexto compartilhado.

Mesmo entre pessoas, isso dá margem pra interpretações diferentes. Com um LLM, preciso prestar ainda mais atenção no que ficou implícito.

O modelo também tem referências culturais, aprendidas nos dados de treinamento. Só que elas não são necessariamente as minhas, nem as da empresa ou das pessoas que vão usar aquele software.

Se eu quero uma interface bonita, o que estou tentando dizer? Que ela precisa ser discreta? Ter pouco texto? Seguir uma identidade visual? Dar destaque a uma informação específica? Funcionar bem pra alguém com pouca familiaridade com tecnologia?

Cada resposta reduz um pouco a ambiguidade do pedido e orienta a busca.

É aí que entra uma ideia de ontologia: organizar os conceitos, seus significados e as relações entre eles. Dar ao agente uma base mais clara pra interpretar o mundo daquele projeto.

Na prática, isso pode começar de um jeito bem simples. Explicar quem usa o produto, o que cada termo significa, mostrar referências e registrar por que algumas decisões foram tomadas.

Conforme os modelos avançam, eles conseguem interpretar melhor muita coisa que hoje precisamos explicar. Mesmo assim, o contexto particular de uma empresa continua precisando chegar até eles de alguma forma.

O conhecimento da empresa entra na conta

Isso me faz pensar em dois diferenciais que vão andar juntos.

Um é a capacidade de investir em computação: quanto a empresa consegue gastar com modelos, infraestrutura e tempo de execução.

O outro é a forma como ela organiza o próprio conhecimento.

Uma empresa pode ter acesso a modelos excelentes e ainda gastar uma quantidade enorme de tentativas porque suas regras estão espalhadas, seus termos são ambíguos e as decisões importantes só existem na cabeça de algumas pessoas.

Outra pode fornecer um contexto muito melhor: o significado dos conceitos, as restrições do negócio, o histórico das escolhas, exemplos do que funciona e do que precisa ser evitado.

Isso muda a qualidade do ponto de partida. E, potencialmente, o tempo necessário pra chegar a um software que faça sentido.

Documentação, nesse cenário, participa diretamente da construção. Ela ajuda a orientar o trabalho da máquina, além de explicar o trabalho pra quem vem depois.

É por isso que acho pequena a discussão que fica só em quantas linhas de código uma IA consegue escrever. Estou mais interessado em quanto tempo precisamos gastar pra transformar uma intenção em algo útil, e no que faz esse tempo diminuir.

O começo do fim do software proprietário?

Essa ideia fica ainda mais provocativa quando penso no software que já existe.

O REA, Reverse Engineer Anything, conecta agentes a ferramentas de análise de binários, aplicações e comportamento em execução. A proposta inclui investigar como uma funcionalidade funciona e usar as evidências pra construir uma implementação para outro projeto. O próprio projeto mostra casos delimitados, como reconstruir um cálculo de som do DX-Ball e investigar a integração de clipboard do Notion.

Isso me interessa pelo custo de reconstruir funcionalidades.

Se compreender e implementar uma função ficar progressivamente mais barato, quanto da vantagem de um software pago continuará vindo da dificuldade técnica de reproduzi-la?

Talvez muita gente nem precise reconstruir um produto inteiro. Precise apenas das funções que usa, adaptadas ao próprio contexto. E, dependendo do custo, pode passar a fazer sentido gerar essa ferramenta em vez de pagar continuamente por um pacote muito maior.

É nesse sentido que penso no “começo do fim do software proprietário”. Como hipótese sobre a perda de uma barreira econômica, ainda em construção. Quanto mais barato for reproduzir uma capacidade útil, maior a pressão sobre quem cobra principalmente pelo acesso a ela.

Um produto completo continua envolvendo integração, compatibilidade, suporte e confiança. Um caso de engenharia reversa de uma função não demonstra que já conseguimos reconstruir qualquer aplicação comercial inteira. Mas basta que uma parcela importante das necessidades fique barata de atender pra essa conta começar a mudar.

Aqui cabe um cuidado: código novo não significa automaticamente ausência de direitos autorais, domínio público ou liberdade de distribuição. A lei brasileira de software protege programas e distingue certas semelhanças decorrentes de características funcionais. Reimplementar uma função, derivar código existente e reutilizar imagens, músicas ou outros materiais são situações diferentes. A origem do material, as licenças e a legislação aplicável importam. A distinção entre funcionalidade e expressão também aparece na orientação do Copyright Office dos EUA.

A hipótese econômica continua de pé: reduzir o esforço de implementação pode mudar o que vale a pena comprar, construir e manter.

E a morte dos consoles?

Nos jogos, penso numa consequência parecida: e se a ligação entre um jogo e o hardware para o qual ele foi criado ficar cada vez mais fácil de desfazer?

Já existem caminhos técnicos diferentes pra isso. Decompilar tenta recuperar uma representação de mais alto nível a partir de um programa compilado. Reimplementar é construir outra implementação do comportamento desejado. Recompilação estática pode traduzir instruções pra uma forma que será compilada para outro ambiente. Emulação reproduz o ambiente necessário à execução e também pode usar técnicas de recompilação.

Esses caminhos podem se combinar. Cada um exige trabalho e tem seus limites.

Um exemplo concreto, separado do REA, é o N64Recomp: ele transforma binários de Nintendo 64 em código C, que pode ser compilado para outras plataformas. O processo depende de informações sobre o binário e de um runtime que forneça as funcionalidades necessárias. Isso mostra uma possibilidade real em um escopo específico, sem estabelecer uma tradução universal de qualquer jogo ou console.

Minha provocação sobre a “morte dos consoles” olha pra onde essa redução de custo pode levar. Se analisar, adaptar e executar jogos em outros ambientes ficar muito mais acessível, a dependência técnica de uma máquina específica pode perder força.

Conveniência, catálogo, serviços e experiência integrada continuam dando razões pra alguém escolher um console. E traduzir a execução de um jogo não apaga os direitos sobre seu código e seus materiais. Ainda assim, me parece uma hipótese importante: quanto do valor de uma plataforma depende de uma barreira técnica que estamos aprendendo a atravessar com menos trabalho?

Nos dois casos, volto ao mesmo ponto. O tempo computacional pode tornar viável algo que antes custava trabalho demais. E uma mudança de custo dessa ordem pode acabar mudando também o modelo de negócio.

O paradigma do tempo computacional

Ainda estamos aprendendo a desenvolver software desse jeito.

Minha impressão é que uma parte crescente do trabalho pode ser convertida em computação: gerar alternativas, experimentar caminhos, executar, corrigir e continuar. Coisas que eram caras demais pra fazer começam a caber no orçamento de um projeto. Ou num servidor em casa.

Ao mesmo tempo, o meu experimento com agentes deixou claro como é fácil gastar essa capacidade sem avançar tanto quanto eu esperava.

As hipóteses sobre software proprietário e consoles nascem dessa mesma mudança: o que acontece quando encontrar, reconstruir ou adaptar uma solução passa a custar muito menos?

Por isso volto à imagem dos pixels.

A solução pode caber no espaço de possibilidades. O desafio é chegar até ela dentro do tempo e do custo que temos disponíveis.

Os modelos ajudam a encontrar caminhos. O contexto ajuda a escolher quais caminhos fazem sentido.

Talvez uma das habilidades mais valiosas nos próximos anos seja justamente essa: conseguir explicar o nosso mundo bem o suficiente pra que o computador gaste menos tempo procurando o que queremos construir.

Couto.