Modelos, contexto e respostas incorretas

Separe a capacidade da informação disponível

Um modelo de linguagem usa padrões aprendidos e a informação fornecida durante uma tarefa. Os modelos atuais conseguem desenvolver raciocínios complexos e fazer trabalho útil de software. Também podem produzir uma resposta detalhada assente num pressuposto incorreto.

«Modelo de fronteira» descreve um nível de capacidade que muda ao longo do tempo. O termo não prova que o modelo leu o seu repositório. Não demonstra que conhece as versões das dependências ou as regras de negócio não escritas. O ambiente da tarefa tem de fornecer esses factos.

Um agente com ferramentas adequadas pode obter informação. Um chat sem acesso não pode inspecionar o repositório. Quando uma resposta parecer incorreta, faça duas perguntas. O modelo consegue resolver o problema com a informação correta? Recebeu essa informação?

Outro modelo pode ajudar com o primeiro problema. Fornecer uma política em falta ou verificar uma dependência pode resolver o segundo.

Defina o contexto desta tarefa

O contexto é a informação disponível para a resposta atual. Inclui instruções, ficheiros fornecidos, conversa relevante e resultados das ferramentas. Os produtos selecionam e conservam esta informação de formas diferentes. Também podem resumir conteúdo anterior.

Não assuma que o modelo lê todos os ficheiros de uma pasta enviada. Não assuma que uma instrução inicial continua disponível durante toda uma sessão longa. Peça à ferramenta que identifique os ficheiros e as instruções que usou.

Mais contexto nem sempre melhora uma resposta. Uma decisão de arquitetura atual pode ser mais útil do que ficheiros de código sem relação com a tarefa. Um guia de migração obsoleto pode causar uma resposta incorreta por parecer uma fonte de autoridade.

Considere uma funcionalidade fictícia de definições de conta. Forneça a rota, o middleware de autorização, o modelo de dados relevante e um teste existente. Acrescente uma restrição específica: «Um membro pode alterar o nome apresentado. Não pode alterar o seu papel na organização.» O modelo passa a ter uma regra explícita a preservar.

Verifique as afirmações de uma explicação

Uma resposta pode afirmar que um endpoint é seguro porque o middleware verifica a quem pertence o recurso. Verifique cada parte desta afirmação.

1. Confirme que o endpoint usa o middleware indicado.
2. Confirme que o middleware verifica a titularidade do recurso, e não apenas a autenticação.
3. Identifique a origem da identidade do utilizador.
4. Faça um teste negativo como outro utilizador.

Uma referência ao repositório indica onde procurar. Não prova que a explicação corresponde ao código.

Use o mesmo método para uma recomendação de API. O código gerado pode chamar um método que o pacote instalado não exporta. Antes de substituir dependências, verifique a versão do pacote e a documentação oficial. Caso contrário, um pressuposto sem fundamento pode provocar uma migração desnecessária.

Transforme a incerteza numa verificação

«Ser rigoroso» não é um plano de verificação. Identifique o pressuposto, as provas necessárias e as consequências de um resultado incorreto.

Por exemplo: «Ainda não verificámos o isolamento entre tenants neste endpoint. Inspeciona o handler do pedido. Acrescenta um teste em que um utilizador de outro tenant pede o mesmo registo.» Esta instrução dá ao agente uma investigação específica e um resultado observável.

Em questões de implementação, examine a versão real do sistema. Um documento pode descrever o comportamento pretendido. A inspeção do código e os testes ajudam a determinar o comportamento atual. Se houver divergência, registe-a até que um responsável a resolva. Não escolha silenciosamente a resposta mais conveniente.

Os gestores podem usar este método sem ler cada alteração de código. Pergunte que pressupostos a equipa verificou. Identifique os que continuam por esclarecer e os respetivos responsáveis. Esta informação apoia uma decisão de lançamento de forma mais direta do que o nome do modelo.