Codage assisté par IA : ce que je délègue et ce que je garde

Il y a un an, j'ai commencé à tenir un journal de chaque tâche où j'utilisais l'assistance IA au codage et de la qualité du résultat. Pas une étude formelle. Une note personnelle dans mon gestionnaire de tâches avec une évaluation en une ligne : ce que j'ai demandé, ce que j'ai obtenu, si c'était utilisable, et si je déléguerais à nouveau cette catégorie. Après 12 mois d'entrées, le pattern est suffisamment clair pour en écrire.

La version courte : l'IA est un ingénieur junior très compétent qui a lu tous les tutoriels et toute la documentation jamais publiés, mais qui n'a jamais travaillé sur un codebase de production sous pression. Elle connaît extrêmement bien les patterns. Elle ne connaît pas votre système, vos contraintes, l'historique de votre équipe, ni pourquoi ce service spécifique a été conçu de cette façon. Déléguez en conséquence.

Ce que je délègue sans hésiter

Boilerplate et scaffolding

Générer un nouveau composant Angular standalone avec OnPush change detection, un fichier spec correspondant, une interface pour ses inputs et la structure SCSS de base me prend bien moins d'une minute avec un assistant IA. À la main, cela prend plusieurs minutes. Sur une journée avec plusieurs composants, ça s'accumule. Le résultat est fiable, cohérent avec les patterns que j'ai configurés dans le fichier d'instructions personnalisées du projet, et nécessite un minimum de revue.

// Prompt I use for scaffolding:
// "Create a standalone Angular component called UserProfileCard.
// It should accept a User input (use the existing User interface from core/models).
// OnPush change detection. Include a loading skeleton state.
// SCSS using design tokens. Spec file with a basic render test."

// Output quality: usable on the first pass, small adjustments for project-specific patterns
// Time saved: most of the typing per component
// Review required: light scan for any deviances from the project rules

Tests unitaires pour les fonctions pures

C'est là que j'observe la meilleure qualité de résultat de manière constante. Étant donné une fonction pure avec des entrées et sorties claires, l'IA génère des tests unitaires complets incluant des cas limites que j'aurais pu manquer. Je fournis la signature de la fonction et une description du comportement attendu, et la suite de tests revient avec le chemin nominal, les conditions aux limites, la gestion de null/undefined et les tests de validation de type.

// Function I provide:
export function formatCurrency(
  amount: number,
  currency: string,
  locale: string
): string {
  if (amount < 0) throw new Error('Amount must be non-negative');
  return new Intl.NumberFormat(locale, {
    style: 'currency',
    currency,
    minimumFractionDigits: 2
  }).format(amount);
}

// AI-generated tests cover:
// - Standard formatting for CAD/USD/EUR
// - Zero amount
// - Large amounts with thousands separators
// - Locale differences (en-CA vs fr-CA)
// - Negative amount throws error
// - Invalid currency code behavior
// Output quality: the most reliable category in my log, week after week
// Time saved: most of the test-writing time per function

Regex et manipulation de chaînes

Je n'écris plus d'expressions régulières de zéro. Je décris le pattern dont j'ai besoin en langage naturel, je demande la regex, je demande des cas de test, et je vérifie par rapport à ceux-ci. Le résultat regex de l'IA est plus lisible que ce que je produisais sous pression temporelle, et les cas de test qu'elle génère révèlent souvent des cas limites auxquels je n'avais pas pensé. Regex de validation pour les codes postaux canadiens, vérifications de format du NAS, normalisation des numéros de téléphone. Tout est délégué. Notez la séparation : la règle de format est générique et sans risque à confier, alors que ce que le code fait ensuite de la valeur, la masquer, la journaliser, la stocker, ne l'est pas, et cette partie-là je l'écris moi-même.

Refactoring de patterns connus

Convertir un composant déclaré dans un NgModule en composant standalone, migrer des formulaires réactifs non typés vers l'API de formulaires typés, mettre à jour du code RxJS plus ancien vers des patterns RxJS plus récents, extraire un bloc répété dans un composant partagé. Ce sont des transformations mécaniques où les règles sont connues et l'IA les exécute avec précision. Je revois toujours le résultat, mais la revue est de la confirmation, pas de la reconstruction.

Mécanique CSS et SCSS

Les layouts CSS complexes, les keyframes d'animation, les feuilles de style spécifiques à l'impression, les CSS grid template areas. Ce sont des domaines où l'IA produit un résultat correct qui me prendrait significativement plus de temps à écrire manuellement. Je décris le comportement de layout dont j'ai besoin et je revois le résultat pour la conformité aux tokens et la compatibilité navigateur.

Documentation et JSDoc

Je donne à l'IA une fonction ou un service et je lui demande de générer les commentaires JSDoc. Elle produit une documentation précise et bien structurée que je revois ensuite et ajuste pour les nuances. C'était la tâche la plus procrastinée sur tout projet. Maintenant c'est un prompt de 30 secondes.

Là où l'IA échoue : ce que je ne délègue jamais

Décisions d'architecture

Cette fonctionnalité doit-elle vivre dans une bibliothèque partagée ou l'application hôte ? Doit-on utiliser un pattern facade ou exposer le store directement ? Ces données doivent-elles être récupérées de manière eagere ou lazy ? Ces décisions nécessitent de comprendre l'historique du codebase, les compétences de l'équipe, le modèle de déploiement, le budget performance et la feuille de route à long terme. L'IA vous donnera une réponse. La réponse sera plausible et bien raisonnée. Elle sera basée sur l'information que vous avez fournie dans le prompt, qui n'est jamais le tableau complet.

L'IA va recommander de découper un service en trois microservices sans savoir si votre pipeline de déploiement peut livrer des services indépendamment. Elle va recommander une implémentation NgRx pour un état que votre équipe prévoit déjà de déplacer vers un autre pattern. Les décisions d'architecture nécessitent un contexte qui vit en dehors du codebase.

Logique métier spécifique au domaine

La logique métier réglementée est spécifique et façonnée par des décennies d'évolution produit. Prenons les réclamations d'assurance comme exemple neutre : quelles clauses de la police s'appliquent à la date du sinistre, ce que la franchise fait au montant versé, quand un dossier doit être escaladé à un expert en sinistres. L'IA n'a aucune connaissance des règles d'un assureur donné et générera avec assurance du code à l'apparence plausible qui est faux pour le domaine, et faux d'une manière qui se lit comme correcte en revue. Je ne donne pas du tout ces tâches à l'IA. Je les écris moi-même avec la spécification du product owner ouverte à côté de l'éditeur.

Code sensible en matière de sécurité

Les flux d'authentification, les vérifications d'autorisation, les utilitaires de chiffrement, la validation de tokens, la vérification du consentement. J'écris tout cela manuellement, j'exige une revue avant le merge, et je n'itère pas dessus avec l'IA. Le risque d'une suggestion subtilement incorrecte dans cette catégorie est trop élevé, et l'effort de revue nécessaire pour faire confiance au résultat rend la démarche pas plus rapide que de l'écrire moi-même.

Chemins critiques en performance

Quand j'optimise un composant critique au rendu, un pipeline RxJS complexe qui gère des événements haute fréquence, ou une implémentation de virtual scrolling. J'écris et je profile manuellement. Le code généré par l'IA est correct en termes de comportement mais rarement optimal en termes de performance. Il ne connaît pas votre stratégie de change detection, votre budget de taille de bundle, ni quels appels se produisent dans le chemin de rendu critique.

Comment ma délégation a évolué

Quand j'ai commencé le journal, l'IA faisait déjà partie de mon travail quotidien. Ce que je n'avais pas, c'était une carte. Je déléguais largement et je jugeais chaque résultat isolément, alors je continuais à confier des catégories qui revenaient à réécrire, et je continuais à faire à la main du travail que l'outil gère bien. Les trois premiers mois d'entrées ont surtout servi à trier ces deux listes.

Au sixième mois, le journal m'avait donné un ensemble de patterns de prompting spécifiques à mon workflow : les signatures de fonctions avant les implémentations, les tests avant le code, et les contraintes énoncées explicitement ('ceci s'exécute en contexte OnPush', 'ceci ne doit pas déclencher le change detection de zone.js'). Les patterns eux-mêmes sont simples. C'est de les appliquer à chaque prompt, et pas seulement quand j'y pensais, qui a fait bouger la qualité des résultats.

Au douzième mois, mon workflow s'était stabilisé. L'IA gère une grande part de mes frappes au clavier sur une journée donnée, principalement dans les fichiers de test, le SCSS et le boilerplate. Le reste est de l'architecture, de la logique métier, de la revue et tout ce qui nécessite une connaissance du fonctionnement spécifique de notre système. Cette part est véritablement précieuse parce que c'est celle que je trouvais la moins intéressante et la plus chronophage.

• Délégation haute confiance : tests unitaires, boilerplate, regex, SCSS, refactoring, JSDoc
• Délégation confiance moyenne : scaffolding de tests d'intégration, pipelines RxJS complexes (avec revue), utilitaires de transformation de données
• Délégation faible confiance : effects NgRx avec effets de bord, stratégies de gestion d'erreurs, tout ce qui touche à l'authentification
• Ne jamais déléguer : décisions d'architecture, logique métier du domaine, code sensible en sécurité, chemins critiques en performance

Le bilan honnête

Les outils de codage IA m'ont rendu significativement plus rapide sur les tâches qu'ils gèrent bien. Ils ne m'ont pas rendu meilleur architecte, meilleur expert du domaine, ni meilleur reviewer. Les ingénieurs que je connais qui tirent le plus de valeur de ces outils sont ceux qui sont clairs sur la distinction. Ils utilisent l'IA pour accélérer l'exécution et réservent leur propre jugement pour les décisions qui le nécessitent.

La meilleure utilisation de l'IA en développement n'est pas de remplacer la réflexion. C'est d'éliminer le travail qui n'en nécessite pas, pour que vous ayez plus de temps et d'énergie pour celui qui en nécessite.

Suivez vos délégations pendant un mois. Pas formellement. Juste une note mentale de ce que vous avez demandé à l'IA et si le résultat était utilisable sans révision significative. Vous construirez rapidement une carte personnelle de là où l'outil mérite votre confiance et de là où il vous fait perdre du temps. Cette carte est plus précieuse que n'importe quel guide générique de prompting IA, parce qu'elle est calibrée pour votre domaine, votre codebase et votre style de travail spécifiques.

Références

• GitHub Copilot repository custom instructions. https://docs.github.com/en/copilot/how-tos/copilot-on-github/customize-copilot/add-custom-instructions/add-repository-instructions
• GitHub Copilot. https://github.com/features/copilot