AI First Development

J’ai la sensation de vivre dans deux mondes différents en ce moment, et je veux clarifier ma position sur l’utilisation de l’IA dans le développement logiciel. D’un côté, je parle à des ingénieurs seniors qui travaillent sur des applications en production et qui sont enthousiastes à l’idée d’utiliser l’IA pour renforcer leur architecture. De l’autre côté, je parle à des développeurs seniors qui sont sceptiques quant à l’utilisation des agents dans le développement logiciel parce qu’ils craignent le « slop IA » et le code mal généré. J’ai choisi d’être enthousiaste à propos des agents de coding IA pour plusieurs raisons que je veux expliquer ici.

Les agents IA ne sont pas qu’un outil de productivité

Travailler avec des agents de coding vous force à penser en termes de délégation. Vous devez définir clairement les livrables dont vous avez besoin. Une bonne délégation est une compétence, et c’est difficile à entraîner avec des humains parce que cela nécessite des années de management pour comprendre comment déléguer correctement. Je le sais très bien parce que je suis (j’étais ?) très mauvais en management d’équipe. J’ai tendance à résoudre les problèmes par moi-même au lieu de coordonner l’équipe pour qu’elle aide. Je suis donc le premier à en pâtir.

Grâce à l’IA et aux agents de coding, j’ai énormément appris sur la bonne délégation. Au début, je demandais trop ou trop peu : « Change ce bouton en bleu » est trop petit pour être délégué. « Ajoute plus de tests » est trop grand. Vous devez trouver le juste milieu pour vos agents.

• Pour le problème du « trop petit » :

  • Regroupez vos demandes. Demandez plusieurs petits changements à la fois ; prenez le temps de lister tous vos changements et envoyez-les.

• Pour le problème du « trop grand » :

  • Découpez la tâche en étapes logiques.
  • Ajoutez plus de détails dans le brief sur la manière d’écrire les tests. Pointez vers des exemples qui fonctionnent bien.
  • Demandez des résultats mesurables : un lien vers la page à QA, un test vert à vérifier, etc.

Pour en revenir à mon point : arrêtez de traiter l’IA comme un outil et commencez à repenser la manière dont vous travaillez en tant que développeur. Déléguez davantage en créant des systèmes de validation robustes auxquels vous pouvez faire confiance.

Pensez comme ceci :

« Que se passe-t-il si j’ajoute 50 développeurs seniors à l’équipe maintenant ? Comment les staffer ? Comment leur transmettre les specs produit ? Comment suivre l’avancement ? Où devraient-ils me poser des questions, et quand ? Comment valider le travail ? Où est la documentation pour eux ? Comment apprennent-ils collectivement pour éviter de faire les mêmes erreurs deux fois ? »

Ce que signifie un développeur 10x

Un développeur aujourd’hui devrait être capable de travailler sur 8 à 10 applications en même temps plutôt que sur 1 ou 2. Cela signifie être capable de tenir plus de contexte dans sa tête. Il est très difficile de savoir exactement ce qui se passe sur 10 applications différentes quand on n’a pas travaillé directement dessus. Vous devez mettre en place des systèmes pour vous assurer de tracker tout ce qui se passe en input et output des applications. C’est juste de l’ingénierie logicielle :

• Documentation propre : créez des systèmes qui mettent automatiquement à jour la documentation à chaque changement de code afin de savoir exactement ce que font les API.
• Suite de tests robuste : +90 % de couverture de tests, pas de tests flaky, des fixtures massives qui représentent des données du monde réel, et une suite de tests rapide.
• Rapports de bugs : être capable de comprendre les bugs en production, de les répliquer en local, de les corriger, de déployer, et d’écrire les apprentissages dans une documentation centrale pour éviter de refaire cette erreur.
• Chaos monkey : faites tourner des agents en local pour fuzz tester les applications et essayer de trouver des angles morts et des cas d’usage non couverts.
• Serveurs de QA : assurez-vous de pouvoir QA chaque branche individuellement dans des environnements isolés pour essayer plusieurs fonctionnalités en même temps.
• Revues de code propres : vous devez être capable de revoir tout le code poussé en production. Utilisez un agent qui fait une première passe de code review.

Vous avez désormais les outils pour créer de tels systèmes et avoir confiance dans toute votre infrastructure.

Chaque changement est une information

J’entends parfois ceci : « Pourquoi utiliser un LLM pour changer la couleur d’un bouton ? » Le problème avec ces petits changements, c’est qu’ils proviennent de « canaux non monitorés ». Cela signifie que le problème est systémique, pas atomique. Si, lors d’un appel vidéo avec l’équipe produit, quelqu’un a dit que ce changement était nécessaire, cela signifie qu’il n’y a pas de tracking en place du pourquoi. Le pourquoi est important parce que ce même genre de changement peut s’appliquer à d’autres parties de l’application plus tard, et si vous avez un système de mémoire en place avec vos agents, ils seront capables de s’en souvenir et d’anticiper ces changements. Tout est question de mémoire et de patterns. Plus vous sauvegardez, moins vous aurez à vous répéter plus tard. PS : ne vous méprenez pas, si un changement de couleur est nécessaire quelque part, c’est probablement un changement de design system à appliquer partout pour garder la cohérence dans l’UI. Je faisais juste le point sur les « petits changements ».

Orchestration d’agents

Le vrai sujet aujourd’hui, c’est l’orchestration, et tout le monde essaie de construire de bons systèmes autour de son infra. OpenClaw, PaperClip et tant d’autres essaient de résoudre le problème. Je suis enthousiaste à propos de NanoClaw parce que je pense que c’est la meilleure base sur laquelle bâtir. Isolation Docker par défaut, très léger, et une code base complète et facile à reviewer. Je pousserai plus de mises à jour sur mon setup NanoClaw bientôt, mais c’est probablement la voie à suivre.

La réponse est : il n’y a pas encore de réponse claire. Nous essayons tous de comprendre.

Le produit d’abord

J’ai la chance de venir d’un background produit. J’ai toujours voulu créer des produits et résoudre des problèmes (vous pouvez en apprendre plus sur mon parcours ici). Ensuite, j’ai « dû » coder et créer des systèmes robustes pour que ces produits puissent grandir. Mais je n’ai jamais aimé coder. J’aimais le résultat, pas le processus. Et maintenant, nous pouvons créer un processus qui génère du code propre et valide le résultat tout en gardant le système sain. C’est la meilleure période pour être en vie en tant que développeur senior. J’aime insister sur le fait que je n’aime pas coder. Écrire du code à la main ne devrait plus être autorisé. Je ne serai jamais frustré de ne pas écrire de code. Je veux penser en systèmes et en architecture, pas dans les détails granulaires. Le code n’a plus de vraie valeur, mais vos garde-fous IA, oui.

Qui est en danger

Je pense toujours que les développeurs seront plus demandés que jamais auparavant parce que la demande en logiciels est infinie. Ceci dit, on demandera à chaque développeur de gérer beaucoup plus qu’avant. Les juniors casseront des choses, et je m’attends à beaucoup de fuites de sécurité et de données venant de code IA non supervisé tournant en production. Les entreprises auront alors deux options : embaucher des seniors (toute personne avec +10 ans d’expérience dans le domaine) et pousser des formations avancées aux juniors pour les garder sans casser la production.

Ok, mais qui est en danger :

• Tout développeur essayant de garder pour lui une certaine information sera bientôt hors-jeu. Les agents de coding aident déjà les équipes produit à comprendre la code base et à voir ce qui existe ou pas, le flux de données, les conditions, et peuvent poser des questions à la code base à la place des développeurs.
• Tout product manager essayant de justifier des livraisons en retard avec « les développeurs sont plus lents que prévu sur cette tâche » ne pourra plus le faire. Ils doivent s’assurer que les specs produit initiales soient claires parce que c’est la racine de tout. L’exécution n’étant plus le bottleneck, cela passe à des specs claires et au QA, qui est le travail de l’équipe produit.
• Les développeurs qui aiment coder ne devraient pas être autorisés à le faire dans un environnement professionnel, mais seulement comme hobby. Vous ne pouvez pas perdre votre temps à taper des caractères sur un clavier alors que vous devriez vous concentrer sur l’architecture, les stratégies de refactoring, la cohérence des données, la couverture de tests, les environnements de QA, et bien d’autres tâches de plus haut niveau. Vous n’êtes pas autorisé à écrire des lettres manuscrites pour coordonner une équipe quand vous avez Slack. Mais vous pouvez tout à fait faire de la poésie le week-end.
• Les développeurs qui ne passent pas au moins 3h à 4h par semaine à lire des news sur la tech, les outils et l’IA.
• Les développeurs qui n’ont pas de side projects où ils peuvent pousser les limites de l’IA et casser des choses sans véritable impact en production. Les développeurs doivent essayer de nouveaux outils et techniques de context engineering pour suivre le rythme.
• Les développeurs qui ne sont pas capables de communiquer clairement avec les autres équipes.

C’est dur d’entendre quelqu’un dire « Ahhh, pourquoi ce bouton ne marche pas ? C’est inacceptable » quand ce bouton est un sprint de 3 semaines que vous avez fait avec 3 tours de QA et que « tout allait bien ». Jusqu’à ce qu’un commercial fasse une démo à un client avec des données très random et casse la fonctionnalité, perdant la confiance du client juste sous ses yeux. En tant que développeur, vous devez faire face à ces situations et trouver des solutions pour résoudre le problème et garantir que cela ne se reproduira pas. Les développeurs ne peuvent plus se cacher du monde réel parce que le monde leur arrive dessus avec des arguments clairs. Une personne produit peut tout à fait demander à une code base « Pourquoi cette fonctionnalité casse quand je fais ça ? » et sortir un plan parfait sur les tests manquants et les angles morts que le développeur a manqués au départ.

Conclusions

C’est en fait tellement drôle que j’ai posté cet article il y a presque 10 ans, et rien n’a changé, l’ingénierie logicielle tient toujours sur les mêmes fondations : How to become a good software engineer.