Le week-end dernier, j'ai passé du temps à tester divers outils et plateformes de codage d'IA. Claude Code et Windsurf se sont révélés être les concurrents les plus impressionnants, et étonnamment complémentaires.

Ce que nous vivons n'est rien de moins qu'une révolution dans le domaine du génie logiciel. Le rôle traditionnel d'un ingénieur logiciel est en train de subir une profonde transformation, et pour rester pertinent, nous devons nous adapter. Voici un article en deux parties sur le sujet.

La première partie traite de l'état actuel et la seconde de l'impact sur le rôle de l'ingénieur logiciel.

L'état de l'IA pour la SWE

Les assistants de codage basés sur l'IA sont passés de simples compléteurs automatiques à de puissants outils qui comprennent le contexte, appliquent des modèles et génèrent du code de haute qualité à grande échelle. Permettez-moi de partager avec vous où je l'ai trouvée pour 1. vous permettre de faire les choses 10 fois plus vite 2. vous permettre d'écrire un meilleur code 3. où cela ne suffit pas.

Comment l'IA vous permet de faire les choses 10 fois plus vite

Ce compartiment est simple et c'est le premier que vous devriez adopter en tant qu'organisation. Chez Beavr, nous l'avons adopté et avons donc mis les ingénieurs logiciels sous stéroïdes.

Tout ce qui est répétitif peut être rationalisé par l'IA. Tout modèle de codage répétitif, comme un module backend écrivant des interfaces de type CRUD que vous modifiez ensuite pour ajouter une logique métier, est un endroit formidable pour utiliser l'IA. Autre exemple appliqué à l'ingénierie des données : l'une des étapes d'un processus de pipeline de données est la standardisation des données brutes : renommer les champs, les ordonner pour rendre la table facilement lisible, conversion de type, etc. Lorsque vous souhaitez standardiser un grand nombre de tableaux provenant de la même source, cela peut être très long. Ces tâches sont importantes mais très répétitives, ennuyeuses et prennent beaucoup de temps. Avec l'IA, c'est beaucoup plus rapide et les résultats sont également plus cohérents. Les tests sont un autre domaine dans lequel l'IA devrait être beaucoup plus exploitée. La rédaction de tests est fastidieuse et répétitive, mais relativement facile à réaliser. Cela rend la prise en compte du TDD plus pertinente que jamais, d'autant plus que l'IA écrit plus de code et que de meilleurs tests deviennent une nécessité.

Où l'IA fait de vous non seulement un ingénieur plus rapide, mais aussi un ingénieur vraiment meilleur

C'est dans cette partie que l'IA est vraiment libérée et c'est là que j'ai été le plus impressionné.

• Nommer les variables : lorsque vous nommez des variables, il ne faut pas essayer de faire preuve de trop d'inventivité. Au contraire, nous devrions nous en tenir à des noms simples et peu originaux. Le fait de sélectionner une variable et de demander à l'IA une meilleure alternative suscite des interrogations et améliore la qualité et la lisibilité de votre code. Il faut tout de même être conscient du fait que votre dénomination actuelle n'est peut-être pas la meilleure.
• Écrire des commits : Claude fait des merveilles en utilisant l'interface de ligne de commande git et github pour écrire des commits. Il ne me reste plus qu'à écrire le code. Quand je suis content de la différence, je git reset main et demandez à Claude d'écrire une bonne histoire des commits. Il écrit de meilleurs relations publiques que moi et améliore la journée de mes critiques. Élimine les fautes d'orthographe dans les commentaires et la documentation pour une base de code plus propre et plus professionnelle.
• Débogage : Interagir avec Claude et lui demander de vous aider à déboguer est vraiment impressionnant. Chez beavr, nous avons ce qui est devenu une architecture backend NestJS spaghetti. Confronté à un problème d'injection circulaire de dépendances dans NestJS, j'ai demandé à Claude de m'aider. Il a réussi à épingler vers la droite un maillon manquant dans le code qui serait autrement difficile à démêler pour un œil humain.
• Demandez l'avis d'un expert : je n'ai cessé de repousser mes limites en suivant le bogue ci-dessus. J'ai demandé à Claude de m'aider à rédiger un document de conception pour réorganiser les modules afin de supprimer cette dépendance circulaire. Il a fait d'excellentes suggestions, y compris d'excellentes suggestions de dénomination. Le niveau de perspicacité qu'il m'a donné était celui d'un grand ingénieur logiciel senior ayant de nombreuses années d'expérience dans ce type de problème. C'est époustouflant !
• La condition pour que Claude soit un excellent outil pour jouer au ping-pong est d'avoir un problème bien formalisé avec déjà quelques idées de l'endroit où vous voulez aller. On pourrait dire qu'une fois cela fait, la moitié du problème est déjà résolue. C'est vrai, mais Claude et t'aider dans cette seconde période n'est pas une mince affaire.

Là où ça ne suffit pas

• Frontend : Le développement du frontend s'est avéré beaucoup plus difficile. J'ai mis en place un figma MCP et j'espérais rationaliser la mise en œuvre du système de conception. Je ne me suis pas senti capable d'y parvenir. La complexité du frontend semble trop importante pour le moment.
• En génie logiciel, il existe notoirement de nombreuses manières différentes d'atteindre les mêmes objectifs. Bien souvent, il n'y a pas de meilleur choix, mais il y en a probablement de meilleurs pour votre équipe en fonction du produit que vous créez, de votre équipe et de nombreux autres paramètres. L'IA ne peut certainement pas définir ces modèles. Si vous laissez l'IA faire cela, votre code deviendra bientôt un monstre de Frankenstein, ce qui le rendra totalement impossible à évoluer. Il faut être très prudent lorsqu'il s'agit de mettre en place les bons garde-corps et les bons modèles.
• Et bien sûr, le rôle d'un ingénieur logiciel implique une multitude de réflexions sur les produits. Comprendre vos personnages, affiner les flux d'expérience utilisateur, concevoir et hiérarchiser les bonnes fonctionnalités ne sont pas des choses que l'IA peut faire aujourd'hui.
• Bonne nouvelle, il existe encore de nombreux domaines où nous, les humains, les penseurs clairs, devançons largement l'IA. Il est notoire que nous avons un esprit critique.

Les prochaines choses que j'aimerais essayer

Le fait de tester ces outils m'a donné envie de continuer à approfondir. Voici certaines choses que j'aimerais explorer :

• Des instructions et des instructions de plus en plus rapides. Je pourrais probablement repousser les limites de ce que j'ai pu faire en consacrant plus d'efforts à définir de meilleures invites et en pointant l'IA vers un fichier d'exemple qu'elle devrait utiliser comme exemple pour l'architecture.
• Hook de pré-validation qui parcourt le code modifié et vérifie automatiquement s'il existe de meilleurs noms de variables pour les variables nouvellement définies
• Ingénierie rapide et action de Claude pour écrire l'historique des commits selon le modèle d'équipe (cf. rédaction d'un paragraphe de validation)

Le nouvel ingénieur logiciel :

Qu'est-ce qu'un ingénieur logiciel basé sur l'IA

À l'ère des assistants de codage basés sur l'IA, le rôle des ingénieurs logiciels connaît une profonde transformation. Pour rester pertinents et efficaces, nous devons nous concentrer sur des activités à forte valeur ajoutée tout en tirant parti de l'IA pour les tâches répétitives. Voici comment évolue le rôle de l'ingénieur logiciel moderne :

1. Définition de modèles et d'instructions d'ingénierie

Tout d'abord, le rôle d'un ingénieur logiciel doit être celui d'un architecte. L'ingénieur logiciel doit continuer à faire ce qu'il a toujours fait

• Sélection des meilleurs frameworks et bibliothèques pour leurs usages
• Établir des règles et créer un code exemplaire qui établit des normes
• Mise en œuvre de cadres de test et de modèles de codage

Les ingénieurs devraient probablement réfléchir sans trop d'aide à l'IA pour limiter les biais. Pour rester au fait des nouveautés, il faut consommer du contenu provenant de YouTube, de blogs et d'autres ressources afin d'intégrer des technologies de pointe et des pratiques de codage pertinentes.

Tout comme un architecte doit s'adapter à l'innovation en matière de matériaux (pensez à Le Corbusier et au béton), le code architectural doit être compatible pour tirer le meilleur parti de l'IA. Les modèles architecturaux doivent être conçus en tenant compte de l'IA. Les principes clés sont notamment les suivants :

• Dénomination cohérente et intuitive des fichiers et des variables
• Colocation logique des composants associés
• Restez très simple

L'objectif est de pouvoir configurer et affiner des assistants IA tels que Claude Code ou Cursor/Windsurf afin qu'ils puissent appliquer les règles prédéfinies. Un ingénieur logiciel de l'ère de l'IA devrait développer une expertise en ingénierie rapide pour « programmer » efficacement l'IA. Associer les fonctionnalités de l'outil à une bonne configuration (ingénierie rapide) garantira l'application constante des modèles, ce qui augmentera considérablement la qualité d'une base de code.

2. Rédaction de spécifications

Une fois que votre IDE AI est bien configuré, passons à la mise en œuvre effective des fonctionnalités. Que faut-il pour y parvenir avec l'IA ? La traduction des idées en exigences réalisables implique :

• Rédaction de spécifications précises et détaillées qui
  • Soyez aussi précis dans cette définition tout en laissant l'IA faire le gros du travail
  • Élaboration d'exigences précises que l'IA peut transformer en code fonctionnel. En règle générale, l'IA peut créer un commit par puce
  • Identifier les cas extrêmes
• Définition des critères d'acceptation auxquels le code généré par l'IA doit satisfaire

Ensuite, celui-ci peut être envoyé à une IA qui rédigera un projet de PR. Pour les tickets simples, il fera parfaitement l'affaire du premier coup, tandis que les tickets plus complexes devront probablement être peaufinés.

3. Itérer avec l'IA pour affiner l'écriture de code

Pour les tâches plus complexes nécessitant des itérations et des ajustements, l'ingénieur logiciel doit reprendre le contrôle. On ne sait toujours pas comment cela va se dérouler, mais je vois deux manières d'y parvenir :

1. Interagir avec l'IA par le biais des relations publiques et de la révision du code. Généralement, on rédige une critique sur github, commit par commit, et l'IA adapte le correctif et répond au commentaire en conséquence
2. En train d'écrire du code, une fois que l'IA a élaboré un projet de PR. Être un assistant Git fera probablement partie du code de triche pour cela. Vous voudrez peut-être simplement récupérer le PR localement de manière classique, modifier un commit spécifique et repousser les modifications. C'est ce qui est le plus accessible aujourd'hui.

4. Révision du code et assurance qualité

La couche de validation garantit la qualité, la fonctionnalité et l'évolutivité, et elle est de plus en plus importante. Au cours des dernières années, on a eu tendance à mettre plus de charge sur le développeur et moins sur la révision, en particulier dans les équipes seniors. Cette tendance va s'inverser. C'est à la fois critique et très difficile à l'ère de l'IA où aller à l'encontre de ce que l'IA a écrit nécessite beaucoup de réflexion critique. Les systèmes d'IA ont cette capacité de présenter les choses « mauvaises » d'une manière qui semble toujours « correcte ». L'IA générant une plus grande partie de notre code, les tests deviennent plus critiques que jamais.

Le flux typique d'écriture de code dans quelques mois/années :

• Le produit, le concepteur et l'ingénieur travaillent ensemble et répètent la rédaction d'un ticket
• Un ingénieur logiciel rédige les spécifications des tickets qui peuvent être prises en charge par une IA.
• Une fois prêt, un tag est attribué au ticket.
• L'IA obtient ce déclencheur. Le code est généré lors de la création d'un PR.
• Les ingénieurs itèrent eux-mêmes avec l'IA.
• Le ticket passe par un processus typique de révision du code et est fusionné.
• Pour que tout cela fonctionne, il y a certainement un niveau de tuyauterie et d'automatisation qui devra être géré par une équipe d'ingénieurs. Cela inclut le bon pipeline CI/CD et l'automatisation des outils connectés. C'est un autre domaine où les compétences et la compréhension de bons vieux architectes en génie logiciel seront nécessaires.

Les implications pour les individus : une barre montante

L'essor des outils de codage basés sur l'IA redéfinit radicalement à la fois les compétences requises des ingénieurs et la progression de carrière de ceux qui entrent dans ce domaine. Les implications sont particulièrement importantes pour les professionnels en début de carrière. Le niveau de pensée critique requis pour être un ingénieur logiciel performant atteint de nouveaux sommets. Les ingénieurs doivent désormais :

• Évaluez les solutions générées par l'IA avec un œil averti
• Comprenez la conception des systèmes à un niveau plus approfondi pour guider efficacement l'IA
• Développez des compétences analytiques plus solides pour identifier les insuffisances des solutions d'IA
• Posséder le jugement nécessaire pour savoir quand utiliser l'IA et quand le codage humain est préférable
• Soyez particulièrement doué pour définir les modèles et les instructions, comme indiqué précédemment

Penser que l'IA peut transformer un SWE de niveau B en un SWE de niveau A est une chimère. L'IA est un multiplicateur de force, pas un activateur.

Le parcours traditionnel des ingénieurs débutants est donc bouleversé. Les tâches de programmation de routine, qui constituaient autrefois un terrain d'entraînement pour les débutants, sont de plus en plus prises en charge par l'IA. L'époque d'apprentissage après des années de mise en œuvre de routine est en train de disparaître, laissant place à une courbe d'apprentissage abrupte qui exige une réflexion de haut niveau dès le départ. Ce changement signifie que la barre pour les ingénieurs débutants est tout simplement beaucoup plus élevée.

Fusion des rôles

Les frontières entre la conception, la gestion de produits et le génie logiciel sont floues. Le rôle du génie logiciel était auparavant axé sur la capacité de codage. Comme nous l'avons vu précédemment, seule une partie du fichier job.AI réduit la valeur de l'ingénieur logiciel. En aval, il automatise le codage ; en amont, il le démocratise. En amont, les chefs de produit peuvent aujourd'hui prototyper et résoudre des bugs faciles et demain implémenter directement des fonctionnalités dans la base de code.

Par conséquent, les ingénieurs logiciels doivent apporter plus de valeur et s'orienteront naturellement vers ce que font les chefs de produit. Ces rôles auparavant distincts convergeront probablement vers une fonction unifiée où l'expertise technique rencontre la vision du produit et les connaissances en ingénierie façonnent la stratégie du produit.

Conclusion

Alors que nous passons de la saisie de chaque ligne de code à l'orchestration de systèmes alimentés par l'IA, la valeur du génie logiciel évolue vers la pensée architecturale, la définition de modèles et le contrôle qualité.

Cette évolution exige de nouvelles compétences : une ingénierie rapide, une rédaction de spécifications efficace et un jugement critique accru. Les ingénieurs les plus performants ne seront pas ceux qui codent le plus rapidement, mais ceux qui peuvent établir des modèles clairs, communiquer avec précision et orienter les outils d'IA vers des solutions optimales.

Les organisations qui s'adaptent rapidement à cette évolution bénéficieront d'avantages considérables en termes de vitesse de développement et de qualité du code. Ils créeront des logiciels plus fiables plus rapidement, avec moins de ressources.

Pour chaque ingénieur, cette transformation représente à la fois un défi et une opportunité. La révolution du codage de l'IA n'élimine pas les rôles du génie logiciel, elle les transforme. Ceux qui peuvent s'adapter, développer leur esprit critique et se positionner à l'intersection de la créativité humaine et des capacités de l'IA deviendront non pas 10 fois mais 100 ingénieurs.

Chez Beavr, nous adoptons ces nouvelles méthodes de travail. Nous n'en sommes qu'à la surface et le potentiel de transformation radicale de la façon dont nous fabriquons nos produits et du rythme auxquels nous les fabriquons est énorme. J'ai hâte de mettre en œuvre à grande échelle les choses dont nous venons de parler.

Quelle période passionnante pour créer des produits logiciels !

NB : Merci Alexis B. pour la critique et les idées ! NB2 : Si cette vision du génie logiciel vous tient à cœur, contactez-nous pour postuler à nos postes dans la SWE ⇒ etienne@beavr.tech

‍