Escrevi que a IA empresarial precisa de pessoas que possam transformar o entendimento do negócio em algo que um sistema possa usar. O mesmo se aplica a fornecedores que tentam obter a recomendação de um agente. Alguém precisa selecionar tarefas representativas do cliente, identificar falhas significativas e decidir quais limitações devem ser explicitadas. A IA pode ajudar a gerar e executar os testes; isso não torna a escolha dos testes comercial ou tecnicamente neutra.
Uma disciplina útil seria incluir casos em que o produto não deveria vencer. A maioria dos fornecedores reluta em dizer ao mundo para não usar seus produtos, mas quando bem feito, é uma ótima maneira de ganhar a confiança dos desenvolvedores (e de seus empregadores). Por exemplo, nos primeiros anos do MongoDB, o cofundador Dwight Merriman insistiu em ter uma página que identificasse onde o banco de dados era excelente, mas também onde não era. Esses casos de uso mudaram à medida que o produto evoluiu, mas é uma boa prática para qualquer fornecedor ou projeto de código aberto. Por exemplo, o agente reconhece um requisito de implantação não suportado ou avisa sobre um custo que importa na escala do cliente? Um fornecedor que mede apenas a frequência com que seu nome aparece pode acabar queimando a confiança se a otimização eficaz do mecanismo de resposta (AEO) direcionar sua tecnologia para ser incorporada em aplicativos onde é provável que falhe.
O desenvolvedor também tem trabalho a fazer aqui. Por exemplo, indicar as restrições antes de pedir uma recomendação e perguntar que provas favoreceriam uma escolha diferente. Quando a decisão for importante, examine as alternativas antes que o agente construa uma aplicação em torno de uma delas. Estas práticas não garantem independência, mas dão ao desenvolvedor uma melhor oportunidade para exercê-la.
