Pare de Copiar e Colar Contexto de Projetos em Chats de IA

Eu uso ferramentas de IA com frequência quando escrevo código.

E continuo vendo o mesmo padrão irritante.

Você abre um novo chat e começa com:

Aqui está o contexto do projeto...

Então você cola o README.

Depois alguns documentos da API.

Depois um arquivo.

Depois outro arquivo.

Então você explica a parte que não está nos documentos.

Então você diz:

Importante: ignore o serviço antigo, não o usamos mais.

O modelo responde.

Está quase certo.

Mas não realmente.

Então você cola mais contexto.

E amanhã você faz a mesma coisa novamente.

Em algum momento, isso deixa de ser "assistência de IA" e se torna um cuidado manual do contexto.

O fluxo de trabalho usual se parece com isto

Desenvolvedor
   |
   v
Copiar README
   |
   v
Copiar documentos
   |
   v
Copiar arquivos de código
   |
   v
Explicar arquitetura
   |
   v
Corrigir suposições desatualizadas
   |
   v
Fazer a pergunta real

Isso funciona para uma pequena tarefa.

Mas não escala.

Uma janela de chat não é uma memória de projeto. É apenas um lugar temporário onde jogamos texto e esperamos que o modelo entenda o suficiente.

O contexto do projeto geralmente está espalhado

Em um projeto real, o contexto vive em toda parte.

Quando colamos apenas parte disso em um chat, o modelo recebe apenas parte da história.

E então ele adivinha.

Às vezes a adivinhação é útil.

Às vezes cria mais trabalho.

O modelo nem sempre é o problema

É fácil culpar o modelo.

“O GPT falhou.”

“Claude perdeu o ponto.”

“O agente de codificação é burro.”

Mas muitas vezes o modelo fez exatamente o que pedimos.

Demos a ele um contexto incompleto.

Por exemplo:

Pergunta:
Como devo adicionar um novo provedor de pagamento?

Para responder isso corretamente, o modelo precisa saber coisas como:

- Já existe uma abstração de pagamento?
- Os provedores estão armazenados em configuração ou banco de dados?
- Como os webhooks são tratados?
- Os pagamentos são assíncronos?
- O que deve ser registrado?
- O que nunca deve ser registrado?
- Existem provedores antigos que não devem ser copiados?
- Existem testes?

Sem isso, o modelo ainda responderá.

Essa é a parte perigosa.

Ele responderá com confiança a partir de um contexto parcial.

O contexto copiado e colado também fica desatualizado

Outro problema é a deriva de contexto.

Seu README diz uma coisa.

Seu código faz outra coisa.

Seus documentos antigos descrevem um serviço que foi removido há seis meses.

Um ticket contém a decisão real, mas ninguém a moveu para a documentação.

Assim, o contexto do chat se torna uma mistura aleatória de verdade, verdade antiga e talvez-verdade.

Algo assim:

Contexto do projeto no chat
|
|-- README
|      status: quase correto
|
|-- documentos antigos da API
|      status: parcialmente desatualizado
|
|-- arquivo de código copiado
|      status: correto
|
|-- nota de arquitetura
|      status: antiga
|
|-- explicação do desenvolvedor
|      status: correta, mas temporária
|
|-- casos extremos ausentes
       status: desconhecido

Não é de se admirar que o modelo fique confuso.

Janelas de contexto maiores não resolvem isso completamente

Sim, janelas de contexto maiores ajudam.

Você pode colar mais.

Você pode incluir mais arquivos.

Você pode despejar mais documentos.

Mas "mais texto" não é o mesmo que "melhor contexto".

Um gráfico mental simples:

Utilidade
^
|                        contexto limpo e estruturado
|                     /
|                  /
|               /
|            /
|         /
|      /  grande cópia e colagem
|   /
+---------------------------------> Quantidade de texto

Em algum momento, mais texto colado se torna ruído.

O modelo não precisa de tudo.

Ele precisa da coisa certa no momento certo.

Um padrão melhor: contexto de projeto reutilizável

Em vez de colar o contexto do projeto repetidamente, acho que precisamos tratar o contexto do projeto como algo reutilizável.

Não assim:

Todo chat começa do zero

Mas assim:

Chat / agente de IA
      |
      v
Camada de contexto do projeto
      |
      |-- conhecimento do repositório
      |-- documentos
      |-- regras de arquitetura
      |-- exemplos de API
      |-- ferramentas internas
      |-- coisas depreciadas a evitar

Então o agente pode usar o contexto do projeto quando precisar.

O desenvolvedor não deve ter que explicar o mesmo projeto todos os dias.

Como isso poderia ser

Imagine um arquivo de contexto de projeto simples.

Não perfeito. Não mágico. Apenas estruturado.

projeto:
  nome: billing-api
  stack:
    - Laravel
    - MySQL
    - Redis
    - Trabalhadores de fila

regras:
  - Nunca registre cargas úteis de pagamento completas
  - Webhooks devem ser idempotentes
  - Novos provedores devem implementar PaymentProviderInterface
  - OldStripeService está depreciado, não o copie

caminhos_importantes:
  - app/Payments
  - app/Http/Controllers/WebhookController.php
  - database/migrations
  - tests/Feature/Payments

tarefas_comuns:
  adicionar_provedor_de_pagamento:
    ler_primeiro:
      - app/Payments/PaymentProviderInterface.php
      - app/Payments/StripeProvider.php
      - tests/Feature/Payments