Princípio central: Code is cheap. Taste matters

Quando o custo marginal de geração e implementação de código é reduzido a quase zero pelos grandes modelos e por bases tensoriais, o recurso escasso na pesquisa científica e na construção de sistemas deixa de ser “conseguir escrever” e passa a ser “vale a pena fazer, e o que significa fazer bem feito”.

Code is cheap é uma descrição objetiva do estado atual da engenharia: após o colapso do custo de implementação, o código deixa de ser uma barreira e deixa de ser unidade de medida da contribuição científica — “conseguir rodar” deixa de ser resultado e passa a ser premissa, deixando de ser uma conquista exibível para se tornar o ingresso para continuar trabalhando.

Taste matters é um reposicionamento das responsabilidades humanas após a divisão de trabalho entre humanos e máquinas: quando “a IA implementa as respostas e o humano controla a direção” se torna a divisão padrão, o que é verdadeiramente escasso do lado humano é a capacidade de formular as perguntas certas, definir critérios de avaliação e julgar a direção em meio a conflitos entre múltiplos objetivos.

Para onde migrou a escassez

Escolha do problema: qual problema resolver determina o teto mais do que qual método usar. Quando a direção está errada, quanto mais rápida a implementação, maior o desperdício.
Design da função objetivo e dos critérios de avaliação: se a métrica estiver errada, o modelo apenas convergirá com eficiência na direção errada.
Critérios de trade-off entre múltiplos objetivos: as preferências entre desempenho, reprodutibilidade, manutenibilidade e custo de implantação precisam ser declaradas explicitamente, e não decididas de última hora.
Interpretação e atribuição dos resultados: distinguir “funcionou por acaso” de “realmente compreendi” e identificar de quais mudanças vieram de fato os ganhos.

O bom gosto precisa ser verificável

Bom gosto não é uma afirmação estética, nem pode ser arbitrado por senioridade ou votação. Ele precisa ser falseado por meio de “entrar em ambientes reais — receber feedback real”: transforme o julgamento em hipóteses verificáveis e revise-o com os fracassos e sucessos em cenários reais. Caso contrário, a discussão se resume a uma disputa de preferências.

O sentido da infraestrutura: dar um ponto de ancoragem ao bom gosto

O objetivo final do EvoX se situa exatamente nesse ponto: construir uma infraestrutura aberta capaz de entrar em ambientes reais e receber feedback real. Uma base aberta, desacoplada e componível reduz o custo de implantação a um nível suficientemente baixo, permitindo que boas ideias entrem a baixo custo em cenários reais, sendo selecionadas, consolidadas e herdadas — a capacidade de julgamento ganha, assim, um suporte que pode ser continuamente aprimorado.

Consciência dos limites: Code cheap não significa que a engenharia possa ser dispensada

Portões de aceitação, reprodutibilidade, manutenibilidade e o ciclo fechado de feedback continuam a constituir barreiras reais. O bom gosto se manifesta justamente no julgamento sobre essas barreiras: que tipo de feedback merece crédito, que métricas devem ser mantidas, quais tentativas fracassadas devem ser rejeitadas em vez de mescladas. É exatamente aí que reside o valor de um mecanismo no estilo Genesis — uma modificação candidata só se torna base histórica herdável pelos executores subsequentes após passar pela compilação, pelos testes, pelas verificações de comportamento e pela aceitação da camada superior.

Um eco

Turing escreveu ao final de “Computing Machinery and Intelligence”: só conseguimos enxergar uma distância muito curta à nossa frente, mas podemos ver que há muitas coisas ainda por fazer. Em vez de discutir a forma final concreta da inteligência, é melhor construir primeiro uma infraestrutura aberta capaz de entrar continuamente em cenários reais e receber feedback real, para que cada rodada de exploração possa ser verificada e herdada.

Esta página dá continuidade à divisão de trabalho da página anterior — “a IA implementa as respostas, o humano controla a direção” — e apresenta os princípios centrais que sustentam essa divisão; a próxima página avança para a prática de guiar a IA por meio de diálogo para realizar tarefas no EvoX.

Pôster Code cheap, Taste matters

Este pôster, centrado em “Code is cheap. Taste matters”, aponta que, após o colapso do custo de implementação, a escassez se desloca para a escolha do problema, o design da função objetivo e dos critérios de avaliação, os critérios de trade-off entre múltiplos objetivos e a atribuição dos resultados. A citação de Turing e a visão do EvoX são justapostas, enfatizando que o bom gosto não pode se basear apenas em afirmações, mas precisa ser verificado por meio do feedback do ambiente real e sedimentado, com o apoio da infraestrutura aberta, como capacidade de julgamento herdável.

Questão 1

No contexto em que o custo de implementação é reduzido a quase zero, qual é o significado de engenharia mais preciso de “Code is cheap”?

A qualidade do código deixa de importar e é possível ir direto para produção pulando a validação de engenharia

O custo marginal de geração e implementação de código tende a zero, e assim “conseguir rodar” deixa de ser resultado e passa a ser premissa

O número de linhas de código continua sendo o principal indicador da contribuição científica

Desde que o modelo seja suficientemente forte, ninguém mais precisa escrever código

Questão 2

Após o colapso do custo de implementação, para onde migraram os recursos verdadeiramente escassos?

Proficiência em linguagens de programação e experiência com frameworks

Número de linhas de código produzidas por unidade de tempo

Escolha do problema, design da função objetivo e dos critérios de avaliação, critérios de trade-off entre múltiplos objetivos e interpretação e atribuição dos resultados

Poder de processamento da GPU e capacidade de memória de vídeo

Questão 3

Por que se diz que “bom gosto não é uma afirmação estética”?

Porque o bom gosto precisa ser falseado por meio de “entrar em ambientes reais — receber feedback real”; caso contrário, resta apenas uma disputa de preferências

Porque o bom gosto pode ser medido diretamente pelo número de linhas de código e pela frequência de commits

Porque o bom gosto é decidido, em última instância, pelo voto de pesquisadores experientes

Porque o bom gosto só entra em jogo na fase de revisão por pares

Questão 4

Qual dos conjuntos abaixo ainda constitui barreiras reais que “Code is cheap” não pode dispensar por nós?

Portões de aceitação, reprodutibilidade, manutenibilidade e ciclo fechado de feedback

Quantidade de modificações candidatas e frequência de submissão

Precisão da autocompletar de código e tempo de resposta do ambiente de desenvolvimento

Velocidade de codificação, popularidade de frameworks e número de parâmetros do modelo

Questão 5

Qual é o propósito central do EvoX ao construir uma infraestrutura aberta, desacoplada e componível?

Reduzir ainda mais o custo de implementação a zero, eliminando assim a necessidade do ciclo fechado de feedback

Reduzir o custo de implantação para que boas ideias possam entrar a baixo custo em cenários reais e serem selecionadas, consolidadas e herdadas, dando ao bom gosto um ponto de ancoragem verificável

Permitir que modificações candidatas entrem diretamente na versão principal sem aceitação

Substituir o julgamento e o trade-off humano por fluxos automatizados

Caso: julgamento de trade-off na evolução contínua no estilo Genesis

Leia o cenário, responda às perguntas e escreva seu processo de raciocínio.

Uma equipe de computação científica adota um modelo de colaboração multiagente no estilo Genesis para atualizar uma base de código numérica mantida há longo prazo: os executores da camada superior compreendem os objetivos e decompõem as tarefas, os executores da camada inferior realizam implementações locais e testes dentro de um contexto limitado, e o modelo pode produzir dezenas de modificações candidatas por dia. A equipe logo percebeu que o verdadeiro gargalo já não era “não conseguir escrever”, mas sim, entre a grande quantidade de modificações candidatas que compilam com sucesso, julgar quais merecem entrar na versão aceita do projeto, quais métricas devem ser mantidas e quais tentativas fracassadas devem ser rejeitadas.

Com base em “Code is cheap. Taste matters”, para quais etapas a equipe deve direcionar prioritariamente seus recursos humanos limitados? Liste ao menos três e explique o que cada uma resolve.

Resposta:
Pontos de referência: (1) escolha do problema e definição do objetivo — determina o teto da direção de exploração e evita otimizar com eficiência um problema que não vale a pena resolver; (2) design da função objetivo e dos critérios de avaliação — escolher a métrica errada faz o modelo convergir com eficiência na direção errada; (3) definição do portão de aceitação e dos critérios de trade-off entre múltiplos objetivos — declarar explicitamente as preferências e prioridades entre desempenho, reprodutibilidade, manutenibilidade e custo de implantação; (4) interpretação e atribuição dos resultados — distinguir “funcionou por acaso” de “realmente compreendi” e identificar de quais mudanças vieram os ganhos. O motivo é que, após o colapso do custo de implementação, “conseguir escrever” já não é uma barreira, e são essas etapas que constituem a capacidade escassa que determina a qualidade do resultado e a acumulação de longo prazo.

Projete um fluxo de aceitação de modificações candidatas capaz de verificar o “bom gosto” e explique como ele se articula com o mecanismo de “modificação candidata — aceitação — herança histórica”.

Resposta:
Fluxo de referência: ① após a submissão, a modificação candidata é primeiro compilada em um ambiente isolado, com execução de testes e verificações de comportamento; ② ela é pontuada segundo critérios de avaliação previamente declarados (desempenho, reprodutibilidade, manutenibilidade) e avaliada quanto a resolver um problema que vale a pena resolver; ③ o executor da camada superior realiza a aceitação, rejeitando tentativas não qualificadas ou com direção equivocada e registrando a atribuição; ④ as modificações aprovadas são incorporadas à versão aceita do projeto e se tornam a base histórica que os executores subsequentes podem herdar; ⑤ o desempenho em ambientes reais retorna como feedback, usado para revisar os próprios critérios de avaliação. Assim, o bom gosto é escrito como julgamento falseável, e não como preferência pessoal — tentativas fracassadas podem ser rejeitadas, resultados eficazes podem ser herdados, e a capacidade de julgamento é repetidamente aprimorada no ciclo.