Ideia principal

Um motor de contexto se decompõe em três funções e nada mais: algo que raciocina sobre a informação, regras que dizem como trabalhar, uma memória que sobrevive à conversa. Escrito assim, levá-lo para um assistente de grande público deixa de ser uma reconstrução. O ChatGPT já raciocina; as diretrizes de um Projeto ChatGPT já carregam as regras; só falta a terceira função, porque uma conversa de assistente se apaga. O Google Sheets a fornece.

O gesto consiste, portanto, em inventariar as funções, reconhecer aquelas que a plataforma já entrega e construir apenas o resto. É o inverso do reflexo habitual, que consiste em migrar um sistema reimplementando-o função por função sobre a nova base — e que fracassa menos por dificuldade técnica do que por carga inútil.

Por que isso importa

Isso muda o que olhamos antes de decidir se um sistema é portável. A pergunta deixa de ser "esta plataforma sabe fazer o que o meu sistema faz?" e passa a ser "quais das minhas funções esta plataforma já entrega, e o que sobra?". Uma migração julgada impossível na primeira pergunta muitas vezes fica modesta na segunda.

Isso também dá um critério de concepção lá na frente: um sistema decomposto em funções nomeadas é portável, um sistema cujas responsabilidades estão embaralhadas não é, porque não sabemos o que poderíamos delegar à base.

Nuances e limites

A decomposição em três blocos é a de um motor de contexto; ela não se generaliza para todo sistema. Um sistema que precisa executar código, chamar APIs ou manter um ambiente de execução tem mais de três, e a migração para por aí.

E uma função entregue pela plataforma é entregue nos termos dela: as diretrizes de Projeto carregam as regras, mas com um teto de tamanho que não existia no sistema de origem. Delegar um bloco é herdar as restrições dele.

Questões em aberto

• Como reconhecer, antes de tentar, que uma função entregue pela plataforma é entregue de forma fiel o bastante para que deixemos de construí-la por conta própria?