Desde o primeiro commit do meu projeto em Python, uma regra importava mais do que qualquer outra: o agente de programação nunca deve ver os critérios de aceitação. Por isso construí dois agentes que nunca trocam anotações. Um escreve os testes a partir da especificação completa, e um agente de programação separado escreve o código a partir da mesma especificação, mas com os critérios removidos. Na maioria dos ambientes de programação, o mesmo agente escreve os dois, o que compromete a validade dos resultados dos testes.
Forcei o corte a acontecer no código, por meio da montagem do contexto, a etapa que constrói o prompt do agente de programação, onde a seção de critérios do arquivo de tarefa é removida antes de o prompt ser montado. Por um tempo achei que esse corte era perfeito. Depois descobri que uma única linha de comentário o quebrava: o corte parava ali, e cada critério posterior ao comentário chegava ao agente de programação. Uma semana depois, um critério que quebrou para uma segunda linha causou o mesmo problema. Os dois erros eram meus. Desta vez, depois de corrigi-los, adicionei testes para que qualquer build futuro falhe se o corte não for aplicado como esperado.
Skills e servidores MCP costumam ser comparados entre si, mas, para a regra da qual meu projeto depende, a resposta acabou sendo nenhum dos dois. Eu queria que os usuários pudessem acessar o qikly, minha ferramenta de linha de comando, a partir de um assistente de IA como o Claude Code ou o Cursor. Isso coloca dois LLMs em jogo, e nenhum deles deveria ver os critérios de aceitação. O assistente já conseguia executar o qikly, mas não sabia quando usá-lo, então escrevi um Skill: uma pasta de instruções em Markdown que o assistente carrega quando um pedido corresponde à sua descrição.
Escrever o Skill separou dois trabalhos. O papel do Skill é dar conselhos sobre o que deve estar nos requisitos e o que deve estar nos critérios de aceitação. Isso só pode ser ensinado, não garantido. O papel da montagem do contexto é remover os critérios sempre, com ou sem um Skill instalado. O conselho ainda importa, porque um critério também escrito nos requisitos chega ao agente de programação de qualquer forma, por isso adicionei ao qikly --validate uma verificação que avisa sobre essas repetições.
Pergunta frequente
P: Por que não confiar em um modelo melhor ou em temperatura zero para impedir que o LLM veja os critérios?
R: Um modelo melhor segue conselhos com mais frequência, mas nem sempre, e definir a temperatura como zero torna as respostas mais repetíveis, não mais obedientes. Regras que devem valer sempre precisam ser impostas no código, como a montagem do contexto, enquanto orientações baseadas em julgamento podem ficar em um Skill.
Fonte: Towards Data Science · Resumido por HeadlinesBriefing