Contexto é o recurso escasso — e sua IA ainda não consegue ver seu site

Parte 2 de uma série sobre a construção de uma plataforma nativa de IA. Esta é sobre a coisa que realmente determina a qualidade da saída — e um recurso que lançamos por causa disso.

O gap do determinismo

Código é determinístico. Mesmo input, mesma saída, toda vez. Essa propriedade é a razão pela qual podemos testá-lo, armazená-lo em cache e raciocinar sobre ele.

IA não é assim. Mesmo prompt, resposta diferente, e nenhuma quantidade de gritos em letras maiúsculas muda o fato subjacente de que você está amostrando de uma distribuição. Se você construiu algo real em cima de um LLM, você já sabe disso em seus ossos: a demonstração funciona, a avaliação é instável, e a diferença entre "envie" e "delete" muitas vezes se resume a algo que você não consegue apontar.

Então aqui está a pergunta que importa para qualquer um que esteja construindo com esses modelos: se o modelo não garante qualidade, de onde vem a qualidade?

O contexto é a variável dominante

A resposta honesta, após alguns anos construindo sobre isso, é contexto. Não folclore de engenharia de prompt. Não um modelo marginalmente mais inteligente. Quanto da situação real o modelo pode ver no momento em que responde.

A maneira mais clara que conheço para sentir isso: pegue a mesma tarefa e execute-a duas vezes.

# Execução A — sem contexto
"Adicione paginação à lista de produtos."

# Execução B — mesma tarefa, repositório em contexto
"Adicione paginação à lista de produtos."
# ...com o componente ProductList real, o cliente da API,
#    e o hook useProducts existente na janela.

A Execução A lhe dá uma resposta genérica e plausível que assume um framework que você não está usando e uma forma de API que você não possui. A Execução B lhe dá um diff que você pode aplicar. Mesmo modelo, mesma temperatura, mesma string de prompt. A única coisa que mudou foi o que ele podia ver.

Esse não é um efeito sutil. Na prática, é a maior parte da diferença entre a saída que você envia e a saída que você descarta. E tem uma propriedade que governa silenciosamente tudo a montante: o contexto é finito. Há um orçamento. Cada token que você gasta em uma coisa é um token que você não gastou em outra.

Uma vez que você aceita isso, há exatamente duas alavancas para melhores resultados. Nós lançamos ambas, e a segunda é o recurso sobre o qual este post realmente fala.

Alavanca um: pare de desperdiçá-lo

Nós expomos um servidor MCP. Em um ponto, ele tinha 59 ferramentas. Agora tem 43, e pretendemos mantê-lo enxuto.

Essa redução foi contra-intuitiva para argumentar internamente, porque em uma página de recurso "mais ferramentas" é lido como "mais capaz." Mas observe o que realmente acontece em uma sessão. Cada ferramenta que um cliente MCP carrega é um esquema — um nome, uma descrição, uma lista de parâmetros — e tudo isso vai para a janela de contexto antes que o modelo faça qualquer coisa. Cinquenta e nove ferramentas é um menu que o modelo lê de ponta a ponta a cada turno, independentemente de a tarefa precisar de alguma delas.

A proliferação de ferramentas parece capacidade e se comporta como ruído. Corte a superfície para as ferramentas que carregam seu peso, mescle as sobrepostas, e o modelo gasta sua atenção em seu projeto em vez de em sua referência de API. Medimos o efeito da maneira chata — executando as mesmas tarefas de construção em modelos antes e depois — e a superfície enxuta saiu na frente em todas elas.

Se você está enviando um servidor MCP, esta é a alavanca que ninguém fala: o número de suas ferramentas é um imposto que os modelos de seus usuários pagam a cada chamada. Projete-o como se o contexto fosse caro, porque para a coisa que o consome, é.

Alavanca dois: preencha-o com o que importa

Aqui está a coisa que me incomodou silenciosamente por um ano.

Para qualquer um com um site existente, a peça de contexto mais densa que eles possuem tem sido completamente inacessível para sua IA. Sua arquitetura da informação. Sua cópia, na sua voz. Seu sistema visual. As cem pequenas decisões que você tomou e depois esqueceu que tomou. Tudo isso sentado em um servidor, e nada disso visível para o assistente que você está pedindo ajuda.

Então o conselho da indústria se tornou: comece de novo. Abra um prompt em branco, descreva seu site de memória e espere que o resultado se assemelhe ao que você já tinha.

Isso não é um novo começo. É uma re-encode com perda de algo que já existia, passado por um canal de texto estreito. Você reavalia decisões que já havia resolvido, e perde silenciosamente aquelas que não consegue lembrar de ter tomado. Para uma categoria de ferramenta cuja proposta de valor inteira é usar suas próprias palavras, dizer às pessoas para jogarem fora seu ativo mais contextual foi um retrocesso.

Então nós construímos o importador. Você dá a ele a URL de um site que você possui; ele produz um projeto real e editável na plataforma, e então você constrói em cima dele com qualquer assistente que você já usa.

Importação que preserva o caminho, tecnicamente

A maneira ingênua de clonar um site é achatar tudo em um diretório e reescrever cada referência para corresponder ao novo layout. Funciona, mas é uma bomba de reescrita: cada href, cada src, cada url() em CSS, cada caminho enterrado em um blob JSON tem que ser encontrado e mutado, e cada mutação é uma chance de quebrar algo.

Nós tomamos o outro caminho. As páginas recebem URLs limpas — about.html se torna /about, contact.php se torna /contact, barras finais são normalizadas — porque essas são as URLs que um humano verá e compartilhará. Mas os ativos de mesma origem mantêm seus caminhos originais. A folha de estilo que referenciava ../../uploads/2019/hero.jpg ainda referencia exatamente isso, porque esse arquivo ainda vive exatamente nesse caminho.

O retorno é que o reescritor encolhe para quase nada. Em vez de remapear cada referência, você está fazendo normalização em nível de host e um pequeno conjunto de reescritas de slug de página. Três passagens:

1. Normalização de host — colapsar https://site.com, //site.com, e caminhos absolutos de mesma origem em uma forma interna.
2. Reescritas de slug — as mudanças de extensão de página (.html/.php → URL limpa), aplicadas da mais longa para a mais curta, para que um caminho mais longo nunca seja cortado por um mais curto que seja um prefixo dele.
3. Limpeza — remover as coisas que pertencem ao antigo host, não ao seu conteúdo: as diretivas robots da fonte, suas tags canônicas, scripts de inicialização injetados pela plataforma. Menos reescritas, menos casos extremos, menos maneiras de acabar com um site 99%-importado (ou seja, quebrado).

Os casos extremos são todo o trabalho

O conceito é um fim de semana. A razão pela qual não é um fim de semana é que a web é trinta anos de estranhezas acumuladas, e um site que importa 99% corretamente é um site quebrado. Uma amostra do que realmente decide se isso funciona:

JSON-LD escapado. WordPress + Yoast emite dados estruturados com barras invertidas escapadas:

{"@type":"CoffeeShop","url":"https:"//site.com/"}

Um reescritor que só entende href="..." passa direto por essa URL e deixa uma referência morta dentro do seu gráfico de esquema. Você tem que analisar a forma escapada.

Extensão vs. contexto DOM. Um arquivo pode mentir sobre o que é.

<link