Le code que l'IA n'écrira pas
J'utilise la validation de formulaires comme question d'entretien technique. Cela semble simple. La manière dont les gens le résolvent révèle leur façon de penser.
J'ai testé ce problème sur Claude, ChatGPT et Gemini. Ils ont tous opté pour la même solution.
La plupart des gens utilisent l'une des trois méthodes suivantes pour le résoudre :
- Utiliser une fonction unique avec des drapeaux pour gérer différents types.
- Utiliser la récursion pour parcourir la structure des données.
- Utiliser un schéma pour piloter la validation.
Les modèles d'IA ont tous choisi l'approche par schéma. Elle est techniquement solide. Elle gère les clés manquantes. Elle passe bien à l'échelle. Si vos données changent au moment de l'exécution, le schéma est le bon choix.
Mais il existe une meilleure approche pour la plupart des logiciels.
Au lieu d'essayer de trouver un modèle unique pour tout, utilisez la composition. Donnez à chaque concept métier sa propre fonction.
- Créez un validateur d'adresse de base.
- Créez un validateur d'expédition qui utilise le validateur de base.
- Créez un validateur de facturation qui utilise le validateur de base.
Cette approche n'utilise pas la récursion. Elle n'utilise pas de schéma. Elle utilise des fonctions claires et distinctes.
L'avantage est simple. Le code reflète le métier. Une adresse de facturation est un concept distinct. Elle mérite sa propre logique. Lorsque vous ajoutez un nouveau type, vous ne modifiez pas une fonction existante. Vous en ajoutez une nouvelle. Cela permet de limiter vos modifications à un périmètre local.
L'IA choisit rarement cette voie. Elle choisit le modèle qui centralise la logique. Notre éducation nous apprend à éliminer la duplication et à généraliser. L'IA apprend de cette culture.
L'IA n'échoue pas. Elle suit simplement les mêmes instincts d'ingénierie que nous lui avons enseignés.
La meilleure solution n'est pas celle qui contient le moins de lignes de code. C'est celle qui reflète le plus fidèlement votre domaine métier.
La prochaine fois que vous concevrez une solution, posez-vous une question :
Cette variabilité se trouve-t-elle dans mon code ou dans mes données ?
La réponse change toute votre conception.
Source : https://dev.to/iceonfire/the-code-ai-wont-write-1ieb