Ce que vous possédez après avoir embauché un développeur IA

Recherchez ceci et la première page se divise proprement en deux. La moitié des résultats sont des pages de destination d'agences avec un formulaire, l'autre moitié sont des guides étape par étape publiés par ces mêmes agences. Chacun décrit un processus d’embauche, et chacun se termine par le parcours vendu par son éditeur.

La décision en dessous n’est pas quel développeur embaucher. Il s’agit de savoir s’il faut embaucher quelqu’un, et les trois réponses disponibles vous laissent avec des choses très différentes lorsque le travail s’arrête.

Les trois routes, par ce qui reste

Un entrepreneur, un placement de plateforme et un engagement d'agence sont généralement comparés en termes de coût et de rapidité. Cette comparaison est la moins utile disponible, car les trois peuvent se ressembler sur une grille tarifaire et ils diffèrent énormément dans ce qui survit à l'engagement.

• Un entrepreneur que vous gérez directement. Vous possédez le code car il a été écrit dans votre référentiel après votre examen. Vous êtes également responsable de toutes les décisions concernant l'architecture, l'évaluation et le déploiement, car personne d'autre ne peut les prendre. C'est la voie la moins chère si vous disposez déjà d'une fonction d'ingénierie capable d'absorber ces décisions, et la plus coûteuse dans le cas contraire, puisque la facture arrive plus tard comme un système qu'une seule personne disparue a compris.
• Un placement sur une plateforme. La plateforme résout le sourcing et la vérification, qui sont véritablement la partie la plus lente du recrutement, et ne résout rien par la suite. Ce que vous possédez à la fin dépend de ce que votre propre processus a extrait en cours de route. Le problème structurel est que l'incitation de la plate-forme se termine au placement, de sorte que personne dans l'accord n'est responsable du fonctionnement de l'objet expédié.
• Un engagement d'agence ou de studio. Vous achetez un système livré plutôt que des heures, ce qui signifie que la remise est le produit. C’est également l’itinéraire où l’écart entre les fournisseurs est le plus grand, car le transfert est la partie que personne ne met sur la page de tarification et la partie la moins chère à ignorer.

Quel que soit l'itinéraire que vous choisissez, notez avant de commencer ce que vous prévoyez retenir à la fin. Cette liste est la seule chose qui rend les trois comparables, et c'est la question que chaque page de ce SERP évite, car deux des trois itinéraires y répondent mal.

Ce que doit réellement contenir un transfert

Pour les logiciels ordinaires, la réponse est en gros le code et un déploiement. Pour tout ce qui contient un modèle, le code est la moitié la plus petite, car le comportement n'est pas dans le code. C'est dans les invites, la récupération, la version du modèle et les seuils, et rien de tout cela n'est lisible à partir du seul référentiel.

• L'ensemble d'évaluation et le harnais qui l'exécute. Il s'agit du seul élément qui détermine si vous pouvez modifier quelque chose plus tard. Sans cela, vous ne pouvez pas distinguer une amélioration d'une régression, donc chaque modification future est une supposition, et une supposition sur un système que vous n'avez pas construit est une supposition que vous ne ferez pas. Ce qu'une suite d'évaluation doit contenir est la version longue de cet argument.
• Les cas d'échec, écrits et toujours en échec. Un transfert avec une suite de tests verte et aucune faiblesse connue n'est pas un transfert, c'est un document de vente. Demandez quelles entrées le cassent. Un ingénieur qui a livré ce type de système répond immédiatement, car la liste est ce à quoi il a consacré son temps.
• Le modèle de coût, avec des chiffres réels. Coût par jeton d'appel, volume attendu et qu'arrive-t-il à la facture si l'utilisation triple. Vous pouvez créer ce côté vous-même avec le calculateur de coûts LLM et vérifier la moitié de l'hébergement dans le calculateur de coûts AWS, ce qui vaut la peine d'être fait avant qu'un fournisseur vous donne son chiffre plutôt qu'après.
• Les décisions de modèle et de contexte, avec le raisonnement. Quel modèle, quelle taille de contexte et pourquoi celui-là. La comparaison de la fenêtre contextuelle LLM est la référence pour le compromis, et la raison pour laquelle la décision doit être documentée est qu'elle expire : les files d'attente de modèles changent et un choix enregistré sans raisonnement ne peut pas être revisité.
• Un runbook pour l'échec qui réveille quelqu'un. Panne du fournisseur, pic de latence, changement de comportement du modèle après une mise à jour de version. Ces trois situations se produisent, aucune n’est hypothétique et la réponse doit exister sur papier avant d’être nécessaire.

Si un candidat ou un fournisseur ne peut pas décrire cette liste, il a créé un prototype plutôt qu'il l'a expédié. Ce n'est pas une disqualification en soi, puisqu'un prototype est parfois exactement ce que vous voulez, mais il doit changer le prix et il doit changer vos attentes.

Les questions qui séparent l'expédition du prototype

La difficulté de cette embauche est que l’acheteur ne peut généralement pas évaluer les compétences. Les deux types de candidats se démontrent bien, car une démo est l'artefact produit par un prototype. Il est difficile de répondre à ces questions à partir de la seule expérience du prototype et il est facile de répondre à partir de l’expérience de la production.

• Qu'est-ce qui s'est cassé en production et que vos tests n'ont pas détecté, et qu'avez-vous changé dans les tests par la suite.
• Comment avez-vous décidé que le système était suffisamment performant pour être expédié ? Plus précisément, quel était le numéro et qui l'a accepté.
• Expliquez-moi la dernière fois où une mise à jour du modèle a modifié votre comportement. Comment l’as-tu découvert.
• Pourquoi avez-vous arrêté d'utiliser un modèle après l'avoir essayé ?
• Comment gérer une demande à laquelle il ne faut pas répondre du tout.
• Combien cela coûte-t-il par appel aujourd'hui et combien cela coûtait-il lorsque vous avez commencé.

La quatrième est la question la plus informative de la liste. Chaque système de production a un cas d’utilisation abandonné, car le processus honnête de construction d’un tel système consiste à trouver la limite. Un candidat qui n’a rien à y mettre n’a pas trouvé de limite, ce qui signifie généralement qu’il n’a pas poussé quoi que ce soit assez loin pour en atteindre une.

Quand la réponse n'est pas une embauche

Deux situations reviennent assez souvent pour être citées, et dans les deux cas, la question de l'embauche est prématurée.

La première est de ne pas avoir décidé à quoi sert le système. Un brief qui dit que nous voulons utiliser l'IA en support n'est pas un brief, et aucun développeur ne peut le convertir en un pour vous, bien que plusieurs essaieront de facturer cette tentative. L'évaluation de l'état de préparation suit le même chemin : ce qui est écrit, ce qui se trouve dans les systèmes et lequel d'entre eux est prêt à être automatisé.

Le second est un problème qui concerne principalement la plomberie des données. Une grande partie de ce qui est considéré comme un travail d'IA concerne la récupération, les autorisations et l'intégration, avec un modèle créant une fine couche à la fin. Ce travail nécessite un ingénieur back-end compétent plutôt qu'un spécialiste, et payer une prime pour le spécialiste ne vous rapporte rien car la spécialisation n'est pas là où vont les heures. La question de savoir qui construit les logiciels d'IA explique comment distinguer les deux avant de rédiger une description de poste, et comment le coût de développement de l'IA est réellement structuré explique pourquoi la plomberie domine l'estimation.

Comment nous définissons cela

Nous livrons des engagements plutôt que de placer des personnes, alors considérez cela comme une divulgation plutôt que comme une neutralité. Ce qui mérite d’être emprunté, c’est la forme du transfert, indépendamment de celui qui fait le travail.

Chaque engagement se termine ici par la suite d'évaluation dans le référentiel du client, le modèle de coût dans une feuille de calcul qu'il peut modifier, la liste des échecs connus et un runbook. Ces quatre-là existent dès la première semaine plutôt que d'être assemblés à la fin, car une passation écrite à la fin est écrite par quelqu'un qui part.

La chose à copier, c'est la commande. Décidez de ce que vous voulez conserver à la fin, puis choisissez l'itinéraire qui le produit. Faire l’inverse, choisir un itinéraire et découvrir ensuite le transfert, voilà comment une démo fonctionnelle devient un système que personne ne peut changer.