🤖 AI

No Accidental Software Agent First Canonical Code for Human Code Entropy Reduction and 30 to 500 times Lower Frontier Model Requirements

Este artigo propõe o "código canônico prioridade-agente", um substrato portador de prova projetado para remover a entropia acidental de repositórios de software humanos ao colapsar codificações equivalentes em representantes governados, visando assim reduzir os requisitos de treinamento de modelos de fronteira e os custos de mudanças verificadas em 30 a 500 vezes, estabelecendo um caminho falseável em direção a um "Horizonte de Não-Acidente".

Autores originais: Jepson Taylor

Publicado 2026-06-15

📖 5 min de leitura🧠 Leitura aprofundada

CC0 1.0

Autores originais: Jepson Taylor

Artigo original dedicado ao domínio público sob CC0 1.0 (http://creativecommons.org/publicdomain/zero/1.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

O Grande Problema: A "Garagem Bagunçada" vs. O "Projeto"

Imagine que você está tentando ensinar um robô a construir uma casa. Atualmente, você está alimentando o robô com milhões de fotos de casas que os humanos construíram.

O problema é que as casas humanas são bagunçadas. Um construtor usa tijolos vermelhos, outro usa azuis. Um coloca a cozinha à esquerda, outro à direita. Algumas casas têm uma porta secreta no porão que não estava no plano original, mas funciona de qualquer maneira. Algumas têm uma instalação elétrica estranha que só funciona se você estiver de pé em uma cadeira específica.

O robô tem que gastar todo o seu tempo e energia tentando entender todos esses detalhes aleatórios e acidentais apenas para aprender o conceito básico de "como construir uma cozinha". Ele está desperdiçando sua capacidade cerebral com os "acidentes" dos hábitos de construção humana, em vez de focar na ciência real da construção.

A Alegação do Artigo:
Podemos parar de ensinar o robô com as fotos bagunçadas. Em vez disso, podemos traduzir todas essas casas humanas para um projeto perfeito e padronizado primeiro. Neste projeto:

A cozinha está sempre no mesmo lugar.
A fiação é sempre feita da mesma forma.
As "portas secretas" são ou removidas ou claramente rotuladas como "opcionais".

Se fizermos isso, o robô não precisará perder tempo adivinhando. Ele pode aprender as regras centrais da construção muito mais rápido, cometer menos erros e custar muito menos para operar.

A Ideia Central: "Código Canônico"

Os autores chamam essa versão padronizada de "Código Canônico Agente-Primeiro" (Agent-First Canonical Code).

Pense nisso como um serviço de tradução.

Código Humano Bruto: É como uma conversa em uma sala lotada onde todos falam dialetos diferentes, usam gírias e interrompem uns aos outros. É cheio de informações valiosas, mas é barulhento.
Código Canônico: É a mesma conversa, mas traduzida para uma única linguagem perfeita, onde cada palavra tem uma definição estrita e a gramática é impecável.

O artigo argumenta que não devemos apenas filtrar o código "ruim". Devemos reconstruir o código neste formato perfeito antes de ensinar a IA.

As Quatro Vezes que Pagamos pela Bagunça

O artigo diz que, quando usamos código humano bagunçado, pagamos pela confusão quatro vezes:

Treinamento: Temos que mostrar à IA milhões de exemplos apenas para ensinar o básico.
Busca: Quando a IA tenta corrigir um erro (bug), ela tem que vasculhar pastas bagunçadas para encontrar onde o código reside.
Raciocínio: A IA tem que adivinhar quais são as regras porque elas não estão escritas claramente.
Revisão: Humanos precisam passar horas verificando o trabalho da IA porque a IA pode ter entendido mal o contexto bagunçado.

Ao usar o "Projeto Canônico", cortamos quase totalmente os três primeiros custos. A IA sabe exatamente onde procurar e quais são as regras.

As "Células de Comportamento" (A Analogia do Lego)

Imagine que você está construindo uma cidade.

O Jeito Atual: Toda vez que você precisa de um "corpo de bombeiros", um arquiteto humano desenha um novo do zero. Às vezes é feito de madeira, às vezes de tijolo. Às vezes a porta abre para a esquerda, às vezes para a direita.
O Jeito do Artigo: Criamos uma "Célula de Corpo de Bombeiros". É um bloco de Lego pré-fabricado e certificado. Tem uma porta, um telhado e uma conexão para mangueira. É garantido que funcionará.

Quando a IA precisa construir uma cidade, ela não desenha um corpo de bombeiros. Ela apenas encaixa a "Célula de Corpo de Bombeiros" no lugar.

A Alegação: O artigo sugere que 70% a 90% do software (como fazer login, pagar contas ou salvar dados) é apenas a "repetição" desses blocos padrão. Se pudermos identificar esses blocos, a IA só precisará inventar as coisas novas (a "novidade"), não as partes chatas e repetitivas.

O "Horizonte Sem Acidentes"

O artigo tem um objetivo ambicioso chamado "Horizonte Sem Acidentes" (No-Accident Horizon).

Imagine um mundo onde o software tem zero acidentes.

Sem nomes de arquivos acidentais.
Sem brechas de segurança acidentais.
Sem confusão acidental sobre o que cada botão faz.

Neste mundo, a única coisa que resta para humanos (e para a IA) fazer é o conteúdo criativo e novo. Todo o resto é apenas um bloco pré-aprovado, seguro e certificado sendo encaixado.

O artigo admite que não podemos alcançar a perfeção de 100% para todos os possíveis programas futuros (porque algumas coisas são novas demais ou estranhas demais). Mas para o software rotineiro que usamos todos os dias (como aplicativos de banco, sites de e-commerce e ferramentas internas), eles acreditam que podemos reduzir o custo e o esforço em 30 a 500 vezes.

O Que o Artigo Realmente Prova (e o Que Não Prova)

É importante manter o foco no que o artigo realmente diz:

O que eles FIZERAM: Eles pegaram um pequeno conjunto de exemplos de codificação, traduziram-nos para este formato de "projeto perfeito" e ensinaram um pequeno modelo de IA a entendê-los. O modelo aprendeu rapidamente e não cometeu erros sobre as "regras" do projeto.
O que eles AINDA NÃO provaram: Eles ainda não provaram que isso funciona para todo o software do mundo. Eles não provaram que isso economizará bilhões de dólares (embora tenham um plano para medir isso). Eles estão propondo um programa de pesquisa para testar essas ideias.

Conclusão

O artigo está dizendo: "Pare de ensinar a IA a ler caligrafia humana bagunçada. Ensine-a a ler projetos padronizados e perfeitos primeiro."

Se fizermos isso, a IA parará de perder tempo tentando adivinhar como os humanos costumam fazer as coisas e começará a gastar seu tempo realmente resolvendo os problemas difíceis e novos. O resultado seria um software mais barato de construir, mais seguro de usar e muito mais rápido de criar.

Resumo Técnico: Sem Software Acidental – Código Canônico Priorizando Agentes para Redução de Entropia de Código Humano

1. Declaração do Problema

O artigo identifica uma ineficiência fundamental nos atuais modelos de codificação de fronteira: eles são treinados em repositórios humanos brutos que confluem comportamento de produto durável com representação acidental. Os arquivos de código humano contêm sinais valiosos (comportamento, casos de borda, cicatrizes operacionais, julgamento de produto), mas estão emaranhados com ruído "acidental": moda de linguagem, volatilidade de frameworks, deriva de nomenclatura, folclore de pastas, confusão de contratos duplicados, confusão de código gerado e dialetos de CI.

Esta "entropia de código humano" força os agentes de codificação a pagar um "imposto de quatro vezes":

Treinamento: Aprender órbitas de implementação redundantes em vez de comportamento.
Coleta de Contexto: Redescobrir arquitetura local e folclore.
Raciocínio/Retentativas: Explorar caminhos de edição inválidos e loops de prova falhos.
Revisão Humana: Reconstruir a intenção a partir de diffs não estruturados.

O artigo argumenta que os modelos de fronteira estão aprendendo o objeto errado. Em vez de imitar o "arquivo de sobrevivência" da história do software humano, eles devem aprender um substrato canônico portador de provas que porta o software rotineiro para perfis governados antes do treinamento e da operação.

2. Metodologia e Estrutura Teórica

A Tese Central: Quocientando por Comportamento

A espinha dorsal teórica do artigo é o quociente do software por equivalência de comportamento sob um oráculo declarado.

A Órbita vs. O Quociente: Modelos de código bruto aprendem toda a órbita sintática $[p]_O$ (todas as implementações válidas de um comportamento). A abordagem proposta aprende o quociente $P/\sim_O$ , mapeando muitas codificações humanas para um único representante governado mais evidência explícita.
Comprimento de Descrição Funcional Mínima (MFDL): O objetivo não é o arquivo de texto mais curto, mas a especificação canônica, o pacote de evidências e o renderizador mais curtos que produzem um sistema funcional sob restrições de comportamento, segurança e migração.

O Substrato Canônico

O artigo propõe um padrão governado e focado em agentes, composto por:

Perfis Canônicos: Configurações de stack limitada e versionada (ex: lane de backend/core, lane de superfície de produto tipada, lane de dados duráveis) com papéis, nomenclatura e propriedade de dependência fixos.
Células de Comportamento: Primitivos reutilizáveis e certificados (ex: autenticação, faturamento, migrações) com interfaces, esquemas e obrigações de prova estáveis.
Células de Patch Semântico: Arquétipos de mudança tipados (ex: "adicionar campo", "rotacionar segredo") em vez de diffs brutos.
Lanes de Prova: Rotas de validação padronizadas (comandos, artefatos, regras de aceitação).
Objetos de Mudança Portadores de Prova: Unidades de trabalho estruturadas contendo intenção, diffs tipados, deltas de segurança e planos de rollback.
Memória Negativa: Um repositório de planos proibidos, fantasmas de compatibilidade e trajetórias falhas para evitar erros repetidos.

O Processo de "Fundição" (Foundry)

Uma Fundição Governada processa artefatos brutos em Objetos de Treinamento Canônicos. Cada artefato recebe uma disposição:

Transformação permitida: Portado para a forma canônica.
Perfil secundário: Atribuído a perfis de não-aplicativos de produto (sistemas, embarcados).
Apenas negativa: Usado como casos de recusa ou memórias de reparo.
Quarentena/Licença excluída: Excluído de treinamento positivo.

Crucialmente, a fundição preserva a evidência de comportamento (testes, traces, contratos) e a proveniência (licenças, linhagem de origem) em vez de descartá-las.

3. Contribuições Principais

A. Programa de Pesquisa Falsificável

O artigo rejeita explicitamente alegações de "milagre". Ele define um ponto final decisivo: o custo total por mudança verificada correta. Esta métrica inclui tokens de origem, contexto, raciocínio, ferramentas, verificação, segurança, proveniência, revisão, loops falhos e custos amortizados da fundição.

O artigo delineia um protocolo de avaliação de três etapas:

Etapa 1 (Teste de Substrato): Um modelo de fronteira amplo deve resolver tarefas pareadas bruto vs. canônico com significativamente menos tokens, chamadas de ferramenta e retentativas antes de qualquer treinamento especialista.
Etapa 2 (Treinamento Especialista): Um especialista canônico é treinado e comparado contra bases amplas em tarefas canônicas.
Etapa 3 (Escala e Economia): Curvas de escala pareadas medem a relação tokens-para-precisão e custos amortizados.

B. Evidência Preliminar (Piloto QLoRA)

O artigo relata um experimento de ajuste fino eficiente de parâmetros:

Modelo: Qwen2.5-Coder-14B-Instruct.
Dados: 64.088 trajetórias de codificação agêntica canonicamente traduzidas.
Resultado: O modelo alcançou convergência (perda de validação ~0.646) e registrou zero marcadores de linguagem proibida (ex: nenhuma violação de def, func ou class em prompts de perfil alvo).
Limitação: Isso prova a aprendibilidade e a aderência ao perfil, mas ainda não prova a preservação do comportamento, a redução de tokens-para-alvo ou a economia de custos.

C. Limites e Fronteiras Teóricas

O artigo estabelece um Horizonte de Não-Acidente:

Limite Universal: Para programas arbitrários e adversariais, a fração de trabalho removível é 0% (não há compressão garantida).
Limite de Produto Rotineiro: Para software de produto rotineiro suportado (SaaS, CRUD, auth, billing), o artigo estima um limite de planejamento defensável de uma redução de ~100× no custo total de mudança verificada.
Faixa Teórica: Uma faixa cautelosa de 30×–500× é proposta para fundições maduras, dependente de células de comportamento cobrirem 70–90% das mudanças rotineiras.

4. Resultados e Alegações

O artigo distingue entre resultados medidos, metas de curto prazo e hipóteses:

Métrica	Status	Faixa de Alegação
Tokens de Treinamento	Hipótese	Redução de 30×–150× (Central)
Tokens de Raciocínio/Ferramenta	Hipótese	Redução de 10×–100× (Central)
Custo de Mudança Verificada	Hipótese	Redução de 10×–50× (Central)
Velocidade de Densidade Ativa	Condicional	8.3×–10× mais rápido (se especialista 100B igualar baseline 1T)
Espaço de Ação	Hipótese	Redução de 1.000×–100.000× (Alto nível)

Aviso Crucial: O artigo afirma que essas faixas não são multiplicadas. Elas são denominadores separados (origem, raciocínio, retentativa, custo) que devem ser medidos em corpora pareados. A figura de "100×" é um limite de opções esgotadas, não um multiplicador garantido para cada tarefa.

5. Significância e Voz

A significância do artigo reside na mudança do paradigma de filtragem (selecionar exemplos mais limpos de dados existentes) para portabilidade canônica (transformar a própria distribuição de dados).

Não é "Melhor Estilo": A tese não é sobre elegância de código, mas sobre redução de entropia. O artigo argumenta que a preferência humana (frameworks, rituais de nomenclatura, rituais de CI) cria "graus de liberdade acidentais" que os agentes devem redescobrir.
Preservação de Valor: O artigo enfatiza que o código humano contém valor insubstituível (casos de borda, incidentes, julgamento de produto). O objetivo é preservar o comportamento e a evidência enquanto se descarta a representação acidental.
Defensibilidade: O artigo é "defensável" porque cada número grande está atrelado a um denominador nomeado e um teste de falsificação. Se o teste de substrato do mesmo modelo falhar, a tese colapsa.
A Visão de "Sem Acidentes": O objetivo final é um estado onde os agentes não inventam arquitetura local, redescobrem folclore ou adivinham leis de migração. Eles operam uma máquina de software restrita, gastando computação apenas em novidade, evidência, governança e risco.

O artigo conclui que, embora o "Horizonte de Não-Acidente" seja um limite teórico, o caminho para ele é um programa de engenharia concreto: construir repositórios bruto/canônico pareados, atribuir disposições, portar o comportamento dentro de contratos e medir o custo amortizado por mudança verificada correta. Se este custo não cair, a alegação de "Sem Software Acidental" falha.