J’ai écrit que l’IA d’entreprise a besoin de personnes capables de transformer la compréhension commerciale en quelque chose qu’un système peut utiliser. La même chose s’applique aux vendeurs qui tentent d’obtenir la recommandation d’un agent. Quelqu’un doit sélectionner des tâches client représentatives, identifier les échecs significatifs et décider quelles limitations doivent être explicitées. L’IA peut aider à générer et à exécuter les tests ; il ne rend pas le choix des tests commercialement ou techniquement neutre.
Une discipline utile serait d’inclure les cas où le produit ne devrait pas gagner. La plupart des fournisseurs sont réticents à dire au monde de ne pas utiliser leur produit, mais lorsque c’est bien fait, c’est un excellent moyen de gagner la confiance des développeurs (et de leurs employeurs). Par exemple, dans les premières années de MongoDB, le cofondateur Dwight Merriman insistait pour avoir une page identifiant les domaines dans lesquels la base de données était excellente, mais aussi ceux où elle ne l’était pas. Ces cas d’utilisation ont changé à mesure que le produit a évolué, mais il s’agit d’une bonne pratique pour tout fournisseur ou projet open source. Par exemple, l’agent reconnaît-il une exigence de déploiement non prise en charge ou avertit-il d’un coût important à l’échelle du client ? Un fournisseur qui mesure uniquement la fréquence à laquelle son nom apparaît peut finir par détruire la confiance si une optimisation efficace des moteurs de réponse (AEO) ordonne d’intégrer sa technologie dans des applications où elle est susceptible d’échouer.
Le développeur a également du travail à faire ici. Par exemple, énoncer les contraintes avant de demander une recommandation et demander quelles preuves favoriseraient un choix différent. Lorsque la décision est importante, examinez les alternatives avant que l’agent ne construise une demande autour de celle-ci. Ces pratiques ne garantissent pas l’indépendance, mais elles donnent au développeur une meilleure opportunité de l’exercer.
