# Codage au feeling en SwiftUI : Le co-créateur de Django construit des utilitaires macOS sans connaître le langage
Simon Willison, co-auteur de Django et créateur de Datasette, a bricolé deux utilitaires macOS en SwiftUI en une seule soirée : le moniteur de trafic réseau Bandwidther (1 063 lignes) et le moniteur GPU/mémoire Gpuer (880 lignes). Sans aucune expérience en Swift ou Xcode, il s’est contenté de quelques prompts dans Claude. Les deux apps sont des outils à barre de menu en un seul fichier pour le MacBook Pro avec M5 Max.
Comment l’IA a géré un framework inconnu
SwiftUI est parfait pour le codage au feeling : tout le code tient dans un fichier. Claude Opus 4.6 et GPT-5.4 ont fait preuve d’une compétence égale. Willison a souligné la facilité à générer des interfaces de barre de menu et des graphiques.
Bandwidther suit le trafic réseau par processus, tandis que Gpuer surveille l’utilisation du GPU et la répartition de la RAM. Les prompts étaient minimaux : une description basique plus quelques ajustements d’interface.
Technique de recombinaison de code
La méthode clé consiste à transférer des motifs entre projets. D’abord, Bandwidther a eu son interface de barre de menu. Puis le prompt : « Regardez les changements récents dans Bandwidther et reproduisez-les. » Claude a automatiquement adapté la structure pour Gpuer, en conservant un style cohérent.
Cela a accéléré le développement : le deuxième outil a été bâti en quelques minutes, sans dupliquer l’effort. La recombinaison minimise les erreurs dans les éléments répétés comme les menus, graphiques et mises à jour de données.
- Avantages de la recombinaison :
- Transfert automatique de motifs éprouvés.
- Réduit le temps de développement de l’UI de heures à minutes.
- Assure la cohérence entre les apps.
Défis de vérification en codage au feeling
Willison a ajouté un avertissement : il ne connaît pas Swift et n’a qu’une compréhension superficielle des métriques macOS. Le lendemain matin, Gpuer indiquait 5 Go de mémoire libre, alors que Activity Monitor montrait autre chose.
Il a envoyé une capture d’écran de l’erreur à Claude, et le modèle a corrigé les calculs. Les nouvelles valeurs paraissent plausibles, mais l’auteur ne peut pas les vérifier sans une connaissance approfondie de l’API.
Le paradoxe du codage au feeling : le code se compile, l’UI fonctionne, les graphiques se mettent à jour — mais la précision des données reste incertaine. Un développeur sans expertise dans le domaine ne peut valider correctement les résultats.
Enseignements clés
- Le codage au feeling en SwiftUI permet de créer des apps macOS complètes en quelques heures sans connaître le langage.
- La recombinaison de code entre projets est une technique efficace pour scaler.
- Risque principal : impossibilité de vérifier les métriques sans comprendre les API de la plateforme.
- Claude et GPT gèrent aussi bien les projets SwiftUI en un fichier.
- Idéal pour les prototypes, mais la production exige une expertise.
Implications pour les développeurs middle/senior
Pour les développeurs seniors, le codage au feeling est un outil de prototypage rapide. SwiftUI abaisse la barrière d’entrée : il est déclaratif et garde le code compact.
Cela dit, les apps de production nécessitent des tests des métriques. Par exemple, dans Gpuer, les valeurs devraient être recoupées avec host_statistics64 ou task_info de l’API Mach, plutôt que de se fier aux calculs de l’IA.
Dans Bandwidther, le trafic est surveillé via getifaddrs et sysctl — appels standards, mais sans audit, des fuites ou imprécisions sont possibles.
— Editorial Team
Aucun commentaire pour le moment.