En 1992 (tabarnak, je suis vieux), alors que je travaillais à la radio terrestre, un ingénieur nommé Michael Liles m'a dit quelque chose qui m'est resté depuis : « David, l'ingénierie, ce n'est pas être capable de régler tous les problèmes. C'est avoir les numéros de téléphone des personnes qui le peuvent. »
C'était un conseil pratique dans un secteur où le silence radio était une urgence et où l'équipement contribuait parfois littéralement à la discussion en produisant de la fumée. Il comprenait que l'expertise comprend l'ingéniosité: évaluer le problème, reconnaître les limites de ses connaissances et savoir où trouver de l'aide.
Plus de trente ans plus tard, l'IA a donné aux développeurs un nouveau numéro à appeler. Malheureusement, elle répond aussi à tous les appels avec l'assurance de quelqu'un qui n'aura jamais à assister à la revue d'incident. Cela change les compétences dont nous avons besoin. Cela nous laisse aussi, sans équivoque, responsables des conséquences.
Pendant des années, le développement logiciel a récompensé les gens qui connaissent une langue particulière sur le bout des doigts. Chaque fonction. Chaque comportement obscur. Chaque bout de syntaxe qui donne l'impression qu'un chat est mort à mi-chemin sur le clavier. Ces connaissances ont de la valeur. Une grande familiarité aide les développeurs à reconnaître des schémas, à enquêter sur les défaillances et à anticiper les problèmes.
Mais nous avons parfois confondu une excellente mémoire avec l'ensemble des compétences d'ingénierie. Les entrevues techniques peuvent devenir de vastes rituels où quelqu'un reproduit un algorithme de mémoire pendant que trois personnes regardent, comme si le plus grand risque opérationnel de l'entreprise était une panne simultanée d'Internet et de tout le matériel de référence. Pendant ce temps, le vrai travail consiste à gérer des exigences ambiguës, des systèmes vieillissants, des priorités contradictoires et une colonne de base de données appelée temporary_fix_2014.
L'IA devrait nous forcer à repenser ce que nous mesurons.
Un développeur qui utilise efficacement l'IA peut être plus précieux qu'une personne dont le principal avantage est de connaître une langue par coeur. L'avantage vient de la combinaison de la compréhension technique, d'une communication claire, de l'adaptabilité et d'un bon jugement.
Le mot efficacement porte beaucoup de poids dans cette phrase. Ne l'enterrez pas sous une pile de code généré.
N'importe qui peut demander à l'IA d'écrire une fonction. Obtenir quelque chose d'utile exige de comprendre le problème, de fournir le bon contexte, d'évaluer le résultat et de reconnaître quand la conversation dérive vers des absurdités confiantes. Une explication convaincante peut très bien accompagner une très mauvaise décision. Quiconque a déjà assisté à une réunion sur le budget le sait déjà.
Le travail commence avant l'invite.
Qu'est-ce que l'utilisateur essaie vraiment d'accomplir? Quelles contraintes comptent? Quelle information manque? Ce processus doit-il être automatisé, ou tout le monde s'est-il simplement attaché émotionnellement à faire quelque chose d'inutile? Si les exigences sont mauvaises, l'IA peut nous aider à mettre en oeuvre la mauvaise chose à une vitesse auparavant réservée aux grandes organisations disposant d'un financement important.
Ça fait de la curiosité, de l'écoute et la capacité de poser des questions inconfortables des compétences essentielles en développement.
Parfois, la question la plus précieuse est: « Pourquoi faisons-nous ça? »
Elle devrait idéalement être posée avant le déploiement. La poser après coup exige généralement une conférence téléphonique et quelqu'un du service juridique.
Vient ensuite le jugement.
L'IA peut produire du code qui semble sensé, qui se lit bien et qui échoue lorsqu'il rencontre de vrais utilisateurs. Les vrais utilisateurs sont exceptionnellement doués pour découvrir des possibilités auxquelles personne n'avait pensé, y compris plusieurs qui devraient sans doute enfreindre les lois de la physique.
Le développeur doit quand même évaluer le résultat.
Est-ce que ça convient à l'application? Est-ce que ça protège les données? Que se passe-t-il lorsqu'une requête échoue à mi-chemin? La prochaine personne qui n'utilise pas l'IA pourra-t-elle le maintenir? Avons-nous ajouté une dépendance parce qu'elle résout un vrai problème, ou parce que le modèle semble recevoir un accomplissement spirituel de l'installation de paquets? Répondre à ces questions exige des connaissances techniques.
La sécurité, la modélisation des données, le débogage, les tests et la conception des systèmes demeurent essentiels. Une connaissance approfondie des langages reste importante, particulièrement lorsque le problème devient subtil. L'IA nous donne plus de façons d'appliquer ces connaissances et plus de raisons de savoir où s'arrête notre compréhension. Sinon, nous risquons de devenir des livreurs de défauts que nous ne pouvons pas expliquer.
L'analogie avec la radio a ses limites ici. La personne que vous avez appelée avait peut-être gagné votre confiance par des années de travail compétent. L'IA peut proposer une solution correcte ou inventer une fonction avec exactement le même ton rassurant. L'assurance est donc une mauvaise stratégie de vérification. Elle reste populaire parce qu'elle est plus rapide que la vérification.
Le développeur a besoin de preuves : inspecter le code, tester le comportement, vérifier les hypothèses et observer ce qui se passe quand les choses tournent mal. « L'IA a dit que ça marcherait » aura l'air spectaculaire dans une analyse des causes profondes. Mettez-le juste au-dessus de « on ne pensait pas que quelqu'un cliquerait là-dessus ».
Cela devrait aussi changer notre façon d'embaucher.
Joel Spolsky a résumé la question d'embauche en deux critères dans The Guerrilla Guide to Interviewing:
- Intelligent, et
- Faire avancer les choses.
Il a aussi critiqué les entrevues qui prennent la connaissance d'anecdotes de programmation pour du talent. Ce principe mérite qu'on lui accorde une attention renouvelée alors que nous décidons comment évaluer les développeurs qui travaillent avec l'IA. La question centrale devrait être: Cette personne peut-elle résoudre les problèmes que nous devons faire résoudre?
Connaître la langue est une preuve qui mérite d'être prise en compte. Il en va de même pour la capacité d'apprendre un système inconnu, d'enquêter sur une défaillance, d'évaluer les solutions possibles et de livrer quelque chose de fiable. Nous devrions cesser de traiter la mémorisation de la syntaxe comme un rite de passage sacré. Le serveur de production se soucie peu que vous vous souveniez de la signature de la fonction. Il a d'autres projets pour gâcher votre fin de semaine.
Appliqué au développement assisté par IA, un entretien utile pourrait proposer aux candidats un petit problème réaliste: un bogue dans une application inconnue, une demande de fonctionnalité comportant une ambiguïté importante, ou une opération lente qui nécessite une enquête. Donnez-leur accès à la documentation et aux outils d'IA qu'ils seraient autorisés à utiliser au travail. Fournissez un accès comparable et des attentes claires afin que l'exercice évalue leur travail équitablement.
Ensuite, observez leur façon d'aborder le problème.
Clarifient-ils l'exigence? Lisent-ils le code environnant? Vérifient-ils ce que l'IA suggère? Repèrent-ils un problème de sécurité? Testent-ils le chemin d'échec? Peuvent-ils expliquer leurs décisions et s'adapter lorsqu'une exigence change? Une solution générée par IA donne à l'intervieweur beaucoup à discuter. Demandez au candidat d'expliquer une section particulière, de trouver une faiblesse ou de modifier le comportement. La compréhension devient visible lorsque la conversation va au-delà de la réponse déjà affichée à l'écran.
Gardez l'exercice circonscrit et pertinent. Demander à quelqu'un de passer une fin de semaine non payée à construire une fonctionnalité dont votre entreprise a besoin relève d'une stratégie d'approvisionnement déguisée en entrevue.
Évaluez les candidats selon des critères cohérents: compréhension du problème, raisonnement technique, vérification, communication et qualité du résultat. Laissez-leur de l'espace pour réfléchir. Une pause réfléchie ne devrait pas perdre face à des absurdités confiantes simplement parce que les absurdités sont arrivées avec une excellente prestance.
Les candidats doivent aussi changer leur approche.
Un CV qui énumère douze langues me dit ce que vous avez rencontré. Je veux aussi savoir ce que vous avez accompli. Quel problème avez-vous résolu? Quelles contraintes le rendaient difficile? Qu'avez-vous appris? Comment avez-vous établi que la solution fonctionnait? Apportez des exemples que vous pouvez expliquer. Si l'IA a aidé, décrivez comment vous l'avez utilisée, quelles suggestions vous avez rejetées et ce que vous avez vérifié vous-même. Montrez-moi où la première approche a échoué et comment vous vous êtes rétabli. Une démonstration parfaitement peaufinée peut cacher beaucoup de choses. L'histoire de la découverte et de la correction d'une mauvaise hypothèse me dit comment vous travaillez.
« Je ne sais pas encore, mais voici comment je m'y prendrais » devrait être un bon début, à condition que vous puissiez y donner suite avec une enquête sensée. Et apprenez à démontrer clairement votre contribution. « L'IA l'a écrit » laisse l'intervieweur se demander lequel d'entre vous a postulé pour le poste.
Nous avons aussi besoin d'une meilleure définition de l'efficacité.
Générer mille lignes de code en quelques minutes prouve seulement que mille lignes de code peuvent être générées en quelques minutes. Leur valeur dépend de ce qu'elles accomplissent et du coût de leur maintenance. Chaque ligne inutile est quelque chose qu'une autre personne devra peut-être finir par comprendre à 2 h du matin. Cette personne, ça pourrait être vous. Les logiciels ont une merveilleuse façon d'organiser ces petites retrouvailles.
Un développeur efficace utilise l'IA pour enquêter, comparer des approches, expliquer du code inconnu, repérer des tests manquants et remettre en question les hypothèses. Parfois, le meilleur résultat est un changement plus petit. Parfois, c'est de découvrir que la fonctionnalité existe déjà. Parfois, c'est de supprimer du superflu, ce qui mérite davantage de reconnaissance comme acte de service public. J'ai aussi l'impression que plus de gens ont besoin de connaître la définition du mot cruft.
Cela change aussi la façon dont les développeurs apprennent.
Les développeurs expérimentés apportent des instincts durement acquis. Ils ont vu des changements innocents devenir des pannes et des « correctifs rapides » durer plus longtemps que les entreprises qui les avaient commandés. Ces instincts peuvent rendre l'assistance de l'IA beaucoup plus utile.
Les nouveaux développeurs doivent aussi développer ce jugement. L'IA peut expliquer des concepts inconnus et les aider à expérimenter, mais accepter des réponses sans les examiner crée une illusion dangereuse de compréhension. Ils doivent prévoir ce que le code fera, tester cette prédiction et enquêter sur la différence. Casser quelque chose dans un environnement contrôlé demeure un excellent enseignant. Casser la production, c'est le même cours avec des frais de scolarité beaucoup plus élevés.
Les équipes devraient faire place à cet apprentissage plutôt que de supposer que l'accès à l'IA inclut vingt ans d'expérience comme accessoire gratuit. Les compétences que nous enseignons, le travail que nous récompensons et la manière dont nous menons les entretiens devraient tous refléter la même attente: les développeurs doivent être capables de comprendre les problèmes, d'utiliser les ressources à leur disposition et de livrer des résultats qu'ils peuvent défendre.
Cet ingénieur de 1992 comprenait quelque chose que notre industrie oublie parfois: votre valeur comprend la manière dont vous allez efficacement au-delà de ce que vous savez déjà.
L'IA nous offre une ressource extraordinaire pour y parvenir. Bien l'utiliser exige l'humilité de demander de l'aide et assez de compréhension pour remettre la réponse en question. Sachez qui appeler. Sachez quoi demander. Vérifiez le travail. Parce que l'IA sera parfaitement heureuse d'expliquer la panne.
Vous serez celui ou celle au téléphone.