Créer une app Mac avec Claude Code

• Claude Code a généré presque tout le code d’une app macOS de plus de 20 000 lignes, puis l’a menée jusqu’à la sortie, avec moins de 1 000 lignes écrites à la main
• Avec l’arrivée des agents de codage IA, l’expérience de développement devient centrée sur les prompts plutôt que sur l’IDE traditionnel
• La génération de code en Swift et SwiftUI a encore certaines limites, mais on peut améliorer la qualité grâce au priming, à l’ingénierie du contexte et à la conception de boucles de feedback
• Automatisation, déploiement, documentation et tests : Claude a pris en charge l’essentiel, réduisant radicalement les tâches manuelles répétitives et le temps perdu
• L’IDE du futur évoluera vers une nouvelle UX centrée non plus sur l’éditeur de code, mais sur l’usage des agents et la gestion du contexte

---

Mon expérience de publication d’une app macOS avec uniquement Claude Code

Aperçu du projet

• J’ai récemment lancé une app native macOS appelée Context. C’est un outil pour développeurs destiné au débogage de serveurs MCP
• Cette app a été réalisée presque à 100 % avec Claude Code. Sur environ 20 000 lignes, je n’en ai pas écrit 1 000 moi-même
• Construire un logiciel avec Claude demande encore des compétences de développeur, du travail itératif et un vrai savoir-faire dans la rédaction de prompts
• Cet article explique en détail tout le processus de création de l’app avec Claude Code, le choix des outils, les avantages et limites, ainsi que les méthodes pour obtenir du code de haute qualité

1. De Copilot à Claude Code, et l’évolution de l’environnement de développement

• Mon premier outil de codage IA a été GitHub Copilot, et j’ai rapidement constaté qu’un simple autocomplétion augmentait déjà fortement ma productivité
• Ensuite sont arrivés Cursor en mode agent, Windsurf et d’autres outils orientés agents qui collectent le contexte du code et automatisent aussi les boucles de build et de test
• Contrairement aux éditeurs classiques comme VS Code, Claude Code vise un environnement d’agent pur, uniquement dans le terminal et centré sur la saisie de prompts
• C’est une UX minimaliste qui retire la plupart des fonctions d’un IDE classique pour ne montrer qu’une boîte de prompt et les résultats
• L’idée n’est pas que l’agent de codage assiste l’IDE existant, mais qu’il tente carrément de le remplacer
• J’étais sceptique sur cette UX très différente des outils habituels, mais j’ai été séduit par l’approche et j’ai décidé de l’essayer

2. Reprendre un side project

• Comme beaucoup de développeurs qui jonglent avec leur travail principal, j’accumulais les side projects inachevés
• Les prototypes sortent vite, mais il manque souvent le temps et l’énergie pour achever les derniers 20 %, ce qui empêche une vraie mise en production
• En testant des serveurs MCP, je me suis dit qu’il me fallait une app native, et j’ai décidé de la créer moi-même
• C’est à ce moment-là que j’ai commencé à utiliser Claude Code sérieusement, et que j’ai mesuré à quel point un agent IA pouvait aider concrètement

3. Les excellentes capacités de génération de code de Claude Code

• Avec les modèles récents Sonnet 4 et Opus 4, Claude Code produit réellement du bon code, rapidement
• Il lit le contexte du projet, comprend le style du code, consulte la documentation et les spécifications pertinentes pour implémenter une fonctionnalité, et écrit aussi les tests automatiquement
• Build, boucles de test, analyse des logs console et des captures d’écran, correction de bugs : presque tout est automatisé
• En une fraction du temps qu’un développeur mettrait à écrire le code lui-même, il génère un résultat de grande qualité
• Même sans contexte, c’est comme intégrer un junior sur un projet et le voir terminer une fonctionnalité en quelques minutes

4. La qualité réelle du support Swift et SwiftUI

• Utilisation de Swift 6.1, macOS 15.5 et de la dernière version de SwiftUI
• Claude maîtrise globalement bien Swift jusqu’à la version 5.5, mais il est plus fragile sur les évolutions récentes comme la concurrence
• Il lui arrive aussi de mélanger API modernes et API legacy, ou Objective-C et SwiftUI, et de se tromper
• Pour le code SwiftUI, les premières ébauches sont parfois incomplètes ou un peu grossières, mais des instructions itératives permettent de bien les affiner
• Quand le code UI devient complexe, des erreurs du compilateur peuvent apparaître, comme des échecs d’inférence de types, et Claude peut alors le refactorer automatiquement en fonctions plus petites
• En consignant des instructions dans CLAUDE.md, on peut encore améliorer d’un cran la qualité du code produit par Claude
  • Par exemple : privilégier SwiftUI, respecter les Apple Human Interface Guidelines, exploiter activement les fonctions récentes de macOS et Swift 6
• En complément, utiliser les recommandations du dépôt agent-rules permet d’obtenir un code encore plus qualitatif

5. Demander : « rends ça plus joli »

• Avec un prompt simple comme « rends ça plus beau / plus élégant / plus agréable à utiliser », on peut demander à Claude d’améliorer le design de l’UI
• Pour les bugs ou les axes d’amélioration UI, il suffit souvent de coller des captures d’écran dans Claude et de lui donner du feedback de manière itérative pour voir les changements immédiatement pris en compte
• De manière plus structurée, on peut d’abord demander « propose-moi des idées pour rendre l’UI plus belle », puis sélectionner uniquement les modifications souhaitées

6. L’importance de l’ingénierie du contexte

• Les modèles IA récents comprennent déjà très bien des prompts imparfaits ou comportant des erreurs de syntaxe
• Le vrai enjeu, c’est de placer uniquement les informations nécessaires dans une fenêtre de contexte limitée (200k tokens)
• Quand le contexte de la conversation est saturé, Claude résume automatiquement (compaction) puis réinitialise le contexte, mais ce processus peut faire perdre certains détails ou dégrader la qualité
• Par conséquent, le vrai défi de l’usage des agents IA est cette “context engineering” qui consiste à tirer la meilleure qualité possible d’un contexte limité

7. Le priming de l’agent

• Comme ce processus de compaction peut faire disparaître un contexte important, il est utile, si nécessaire, de demander un résumé manuel ou d’ajouter des informations de priming en amont
• Au-delà de CLAUDE.md, la qualité des sorties augmente quand on demande explicitement à Claude de lire et résumer à l’avance certains fichiers source, documents de spécification, etc.
• Pour des bibliothèques récentes ou des API apparues après le knowledge cutoff de Claude, on peut aussi convertir la documentation avec des outils spécifiques (Context7, llm.codes, etc.) afin de la rendre plus facile à comprendre pour Claude
• Le priming consiste à donner une instruction du type : « lis tous ces fichiers source, documents et spécifications, puis résume-les », afin que Claude comprenne d’abord pleinement le contexte

8. Un agent a besoin de spécifications claires

• Quand on demande à Claude d’implémenter une fonctionnalité, il faut impérativement fournir une spécification concrète et détaillée pour obtenir le résultat souhaité
• Les démonstrations du type « créer une app avec un prompt d’une phrase » ne permettent en réalité d’aller guère au-delà du prototype
• Même si la spec n’est pas très formelle, il suffit de l’expliquer de la façon la plus confortable possible, à la voix ou au clavier

9. « Ultrathink and Make a Plan »

• Si Claude se lance directement dans l’implémentation, la qualité du résultat baisse ; il est donc plus efficace de lui demander d’abord d’établir un plan en activant un mode de réflexion étendue comme think ou ultrathink
• Faire valider le plan étape par étape, puis donner du feedback avant l’implémentation, améliore la qualité
• L’article d’Anthropic Claude Code: Best practices for agentic coding est recommandé comme lecture indispensable

10. Mettre en place une boucle de feedback

• La vraie force de Claude Code atteint son maximum quand il peut faire tourner une boucle de feedback de manière autonome
• L’essentiel est donc de mettre en place un cycle automatisé dans lequel Claude modifie lui-même le code, le build, analyse les causes d’échec en collectant le contexte, puis recommence
• Plus cette boucle est bien conçue, plus Claude peut finaliser du code de haute qualité de façon autonome
• 1. Build (compilation)
  • Claude doit pouvoir effectuer lui-même le build (la compilation) de l’app
  • Pour un package Swift, un build est simple via la commande swift build, et Claude gère cela naturellement
  • En revanche, pour une cible d’app macOS (par exemple un projet Xcode), Claude hésite souvent sur la bonne commande xcodebuild à utiliser
  • Pour résoudre ce problème, j’ai utilisé un outil appelé XcodeBuildMCP, qui fournit à Claude une interface simplifiée pour builder et lancer l’app plus facilement
• 2. Test (tests)
  • Après avoir buildé le code, Claude doit pouvoir lancer automatiquement les tests et analyser les résultats
  • Pour un package Swift, swift test permet d’exécuter naturellement les tests, et Claude gère bien cette étape
  • Je n’ai pas encore expérimenté l’exécution directe par Claude de tests d’application complets ou de tests UI, mais cela nécessitera probablement là aussi un outil comme XcodeBuildMCP
  • À partir des résultats de test (logs de succès ou d’échec), il poursuit la boucle de correction du code
• 3. Fix Bugs (correction de bugs)
  • Claude peut suivre les problèmes en ajoutant des logs pour le débogage
  • En revanche, Claude ne peut pas manipuler lui-même l’app pour générer ces logs
  • Il faut donc que l’utilisateur interagisse manuellement avec l’app, puis copie-colle les logs de la console dans Claude
  • Cette méthode fonctionne en pratique, mais sans un bon niveau de tests unitaires ou de tests UI écrits à l’avance, une correction de bugs entièrement automatique reste difficile
  • Pour les apps web, il existe des solutions d’automatisation navigateur comme playwright-mcp, mais pour les apps natives, il manque encore une alternative vraiment solide
• 4. Fix UX Issues (correction des problèmes UX)
  • Pour améliorer des problèmes UI/UX, on peut coller directement des captures d’écran dans Claude et fournir un feedback itératif
  • Des outils comme Peekaboo permettent aussi d’automatiser les captures d’écran, mais il faut toujours manipuler l’app manuellement au préalable pour l’amener dans l’état voulu avant de capturer
  • En d’autres termes, l’automatisation liée à l’UX nécessite encore une intervention humaine

11. Claude Code fait plus qu’écrire du code

• Comme Claude Code repose sur un grand modèle de langage polyvalent (LLM), il peut servir à bien d’autres tâches non directement liées au développement
• Par exemple, on peut lui demander naturellement de retravailler les textes de l’app, d’élaborer un plan de release ou de proposer des pistes d’amélioration produit
• L’un des usages les plus utiles a été sa capacité à générer automatiquement des données mock au tout début du projet, avant de disposer de vraies données
  • Lors du développement de l’app Context, je voulais avancer sur les prototypes UI alors que la bibliothèque cliente MCP pour Swift n’était pas encore terminée
  • En temps normal, créer soi-même des données mock réalistes aurait été très fastidieux et chronophage, au point que je ne l’aurais probablement pas tenté
  • Mais Claude a généré en quelques secondes des données mock très crédibles, au point de produire des états d’interface presque impossibles à distinguer du réel
  • Quand j’ai partagé l’UI avec des amis, j’ai d’ailleurs utilisé des captures d’écran fondées sur ces données mock, qui donnaient une impression équivalente à celle d’un vrai service
  • Pour les serveurs MCP, beaucoup d’implémentations n’avaient alors qu’une partie des fonctions de la spécification officielle, ce qui rendait l’obtention de données réelles difficile
  • Malgré cela, les données mock générées par Claude ont permis de valider l’ensemble du flux UI et le fonctionnement des fonctionnalités

12. L’époque où une automatisation de haute qualité devient (presque) gratuite

• Dans les derniers 20 % d’un lancement logiciel, l’une des parties les plus douloureuses est l’automatisation du processus de release
• Pour une app macOS en particulier, les procédures de déploiement sont complexes — signature de code, notarization, packaging (création de DMG) — et les sorties étaient souvent retardées par du travail manuel ou des scripts fragiles
• Jusqu’ici, il fallait forcer la mise en place d’outils d’automatisation comme fastlane, ou écrire soi-même au minimum quelques scripts Python
• Sur ce projet, quelques heures de prompts itératifs et de débogage ont suffi pour que Claude génère un script complet d’automatisation des releases
• Principales tâches prises en charge par ce script :
  • Vérification de l’environnement : contrôle que les outils nécessaires sont bien installés
  • Génération automatique du changelog : extraction de l’historique depuis les commits git, fusion avec des éléments rédigés à la main, puis création de notes de release HTML
  • Build et packaging de l’app : automatisation de toute la chaîne, du build à la signature de code, puis à la notarization et à la création du DMG
  • Génération du flux de mise à jour Sparkle (appcast) : pour distribuer les mises à jour automatiques aux utilisateurs existants
  • Tag et publication de release : ajout du tag sur GitHub et publication de la release
  • Upload des symboles Sentry : envoi automatique des symboles de debug pour l’analyse des crash reports
• Une fois le script terminé, une simple ligne de prompt — « rends la sortie CLI plus jolie » — a suffi pour améliorer aussi l’UI de la ligne de commande
• Le résultat final représente environ 2 000 lignes de code Python ; à la main, je me serais probablement arrêté au strict minimum, alors qu’avec Claude j’ai pu viser une finition de haute qualité
• Grâce à ce script d’automatisation, chaque release me fait désormais économiser des dizaines de minutes de tâches répétitives
• Il suffit d’expliquer la spec en langage naturel et de faire corriger à Claude les erreurs repérées à l’exécution pour accomplir l’essentiel du travail

13. L’IDE du futur sera complètement différent

• Pendant ce projet, les seuls outils que j’ai réellement utilisés du début à la fin ont été Claude Code et GitHub Desktop (pour visualiser les diffs)
• Les fonctions centrales d’un IDE traditionnel — arborescence de fichiers, éditeur de code, extensions, plugins, etc. — n’étaient presque pas nécessaires
• J’ai parfois ouvert Xcode pour corriger directement du code, mais j’ai très peu utilisé ses fonctions spécifiques comme SwiftUI Previews ou le View Debugger
• C’est précisément parce que les capacités des agents de codage IA sont encore à leur point le plus faible aujourd’hui que j’ai le sentiment que les IDE vont évoluer vers une forme entièrement nouvelle

• Copilot, Cursor, Windsurf et les autres sont tous partis de VS Code en y ajoutant des fonctions, mais VS Code lui-même diffère à peine des IDE JetBrains d’il y a 20 ans
• Des projets comme Warp essaient de moderniser le terminal pour en faire un environnement de développement pour agents, mais une UX centrée sur le terminal ne sera probablement pas non plus la réponse ultime

• Le cœur de l’IDE du futur sera sa capacité à aider les développeurs à préparer efficacement le contexte de l’agent (priming) et à concevoir puis gérer les boucles de feedback
• Autrement dit, l’éditeur de code ne sera plus au centre : on se dirige vers une UX largement centrée sur l’usage des agents et la gestion du contexte

14. Je peux de nouveau lancer des side projects

• Le point le plus marquant de toute cette aventure n’est pas seulement d’avoir créé une app impressionnante, mais surtout d’avoir retrouvé la capacité de publier réellement mes side projects
• Comme si j’avais gagné 5 heures de plus chaque jour, pour un coût d’à peine 200 $ par mois
• Grâce à des agents de codage IA comme Claude Code, j’ai retrouvé l’élan et la confiance nécessaires pour transformer en réalité des idées que je repoussais depuis longtemps

[geek12356]

Faites-en beaucoup

[GN⁺]

Commentaires sur Hacker News

• Il y a encore 2 ans, j’étais convaincu d’être un très bon ingénieur Python, et maintenant je peux créer en quelques jours, voire quelques heures, des apps mobiles natives, des apps desktop qui communiquent avec Slack, des API écrites en Go, et même des applications web complètes basées sur React
  J’ai l’impression d’avoir acquis un super-pouvoir, avec une explosion de productivité, de vitesse et de créativité, mais en même temps j’éprouve une étrange tristesse
  Mon métier, ma passion, tout ce que j’ai appris avec effort et au prix de sacrifices pendant longtemps, tout cela est désormais en grande partie remplacé par des machines
  Les entreprises qui créent ces outils n’en sont encore qu’au point de départ
  Je me demande ce que cela signifiera pour la prochaine génération d’ingénieurs et jusqu’où cette dynamique va aller
  Je me demande si d’autres ressentent la même chose que moi

  • Si je peux aujourd’hui manier efficacement des outils variés sur plusieurs plateformes — natif, mobile, Go, React, etc. — c’est grâce à mon expérience du développement logiciel en tant qu’ingénieur Python
    Ce que les LLM remplacent, c’est le besoin de mémoriser les petits détails spécifiques à chaque plateforme
    Je peux ne pas connaître par cœur la syntaxe d’une boucle for en Go et pourtant écrire immédiatement du code Go utile
    En revanche, il faut toujours comprendre les principes fondamentaux : les boucles, les concepts de Go, la programmation structurée, les compilateurs, les scripts de build et de test, etc.
    C’est précisément ce qui manque fortement aux personnes sans bagage en programmation
    J’ai le sentiment que les LLM sont un amplificateur et un accélérateur qui rendent immédiatement applicable à différents langages et plateformes le savoir diffus accumulé pendant ma longue carrière
    Si auparavant je résolvais tout avec Python, JavaScript et SQL, c’était parce que réapprendre les petites différences d’un nouveau langage ou d’une nouvelle plateforme me paraissait trop coûteux
    Désormais, j’utilise volontiers Go, Bash, AppleScript, jq, ffmpeg, etc., et j’envisage même un projet Swift

  • J’ai déjà vu des personnes non techniques fabriquer des choses avec des LLM, et en général c’est bien plus lent, ou presque un échec
    Les compétences techniques ne sont peut-être pas absolument indispensables au final, mais une capacité à communiquer clairement l’est forcément
    Le simple fait de comprendre le HTML permet déjà d’insérer proprement du texte pour que le LLM comprenne plus clairement
    Je pense toujours qu’un bagage technique reste un avantage

  • Je pense que les travailleurs artisans avant la révolution industrielle ont probablement ressenti quelque chose de similaire
    Mais il faut aussi se rappeler que la plupart n’avaient pas vraiment reçu d’éducation, que 1 ou 2 de leurs enfants mouraient avant 10 ans de maladies bénignes, et qu’ils vivaient sans électricité, sans eau courante, sans plomberie intérieure ni réfrigérateur
    Fabriquer des outils de ses propres mains a quelque chose de romantique, un peu comme écrire du code Python à la main, mais à mesure que l’époque progresse, vivre à des niveaux d’abstraction plus élevés profite aussi, je pense, à nos ancêtres eux-mêmes
    Personne n’empêche qui que ce soit d’écrire lui-même son code Python, et je pense qu’il y aura forcément des gens pour en faire un hobby, comme le travail du graphite

  • J’ai du mal à adhérer à l’idée que les machines remplacent désormais le métier, la passion et les compétences que j’ai construits
    Une machine ne fait que suivre des instructions, sans expérience, sans anticipation, sans réflexion, sans capacité de planification ni créativité
    Seuls les humains ont des idées, de la créativité, des objectifs, de l’empathie, et la capacité de convaincre les autres avec de bonnes idées ou de prendre en compte le contexte selon la situation
    Je pense que le métier de programmeur ne disparaît pas : il se déplace simplement vers un niveau d’abstraction bien plus élevé
    Autrefois, on pouvait déjà devenir développeur sans connaître les bits, les octets ni la moindre ligne d’assembleur, alors qu’il fut un temps où l’assembleur était indispensable
    Aujourd’hui, c’est une époque où l’on peut créer des programmes sans même connaître un langage de programmation, à condition de bien maîtriser l’anglais et les exigences
    Cela dit, ceux qui comprennent la mémoire, l’assembleur et les concepts bas niveau comprennent toujours mieux ce qui se passe en arrière-plan et peuvent faire les choses « mieux » quand c’est nécessaire
    Je ne pense pas pour autant que les couches d’abstraction supérieures deviennent inutiles ou vont disparaître

  • Je ressens exactement la même chose
    Je développe des logiciels professionnellement depuis plus de 20 ans, et j’ai vraiment adoré ce métier
    Aujourd’hui, j’exploite Claude Code à 100 % et ma productivité a clairement augmenté, mais alors que l’ancien processus me semblait relever de l’art, j’ai maintenant l’impression d’une production de masse industrialisée
    Dans cette nouvelle réalité, j’aimerais retrouver quelque chose qui me soit propre, qui me permette de me replonger profondément dans le logiciel, et il est certain que le plaisir a beaucoup diminué

• Le texte est extrêmement bien écrit, et sa lecture est un plaisir en soi
  L’IDE du futur sera totalement différent de celui d’aujourd’hui
  Moi aussi, j’ai commencé avec Cursor, puis utilisé un IDE renforcé autour de VS Code, avant de finir par passer à Claude Code
  Du coup, l’importance du terminal a grandi, et j’ai fait évoluer mon workflow vers iTerm avec Ghostty (rapide, léger et moderne), Tmux, Tmuxinator et NeoVim
  Je vérifie les fichiers avec les commandes cat ou bat, je n’édite du texte qu’occasionnellement, et Claude Code se charge de la plupart des tâches lourdes
  J’écris surtout des spécifications et des prompts dans NeoVim ou Emacs, et j’adore ce workflow
  Je ne m’en sers pas seulement pour générer du code : je lui assigne aussi des tâches pour modifier des fichiers de config comme zsh, neovim ou ghostty
  Même le refactoring des fichiers de configuration se règle en quelques minutes
  Je lui confie aussi les questions sur le codebase, le refactoring, la documentation du code, la génération de messages de commit, etc. C’est absolument génial

  • À la fin, il est question de questions sur le codebase, de refactoring, de documentation du code et même de commits pertinents ; moi aussi, j’ai déjà obtenu d’excellents messages de commit avec CC en plaçant des informations et des exemples sur les Conventional Commits dans le fichier CLAUDE.md

  • Je me demande si CC sauvegarde automatiquement des fichiers de configuration personnels comme .zshrc avant de les modifier

• Terminal + Claude Code + dossier du projet
  Je me rends seulement maintenant compte que cela suffit vraiment
  Je n’aimais déjà pas les setups d’IDE complets parce qu’ils sont pénibles, et pour faire du cross-compiling selon l’OS, la configuration de QT était aussi compliquée ; j’ai toujours trouvé que la combinaison éditeur + terminal était la plus logique
  Avec Claude Code en plus, dans une autre fenêtre de terminal ouverte pour aider à traiter les demandes, j’ai l’impression d’avoir « level up », en passant de développeur à chef de projet
  Et sans le stress de gérer des employés
  Depuis que Claude est arrivé en mars, j’ai terminé en quelques mois tous les side projects que je voulais faire depuis longtemps

• Il y a 1 ou 2 ans, j’avais formulé l’idée suivante : pour les développeurs expérimentés, les LLM sont d’excellents assistants ; si on essaie de les utiliser pour remplacer des développeurs expérimentés, c’est le chaos ; et pour les développeurs inexpérimentés, ce sont des assistants dangereux
  D’après mon expérience, cette idée se vérifie globalement
  Aujourd’hui, je pense qu’un LLM peut aussi devenir un bon mentor pour un développeur inexpérimenté, mais dans la pratique, on voit surtout des gens modifier le code au hasard sans comprendre pourquoi il fonctionne, jusqu’à ce qu’il semble plus ou moins marcher
  Au final, cela renforce encore mon opinion initiale : dans ce genre de situation, le LLM est un assistant dangereux
  Dans ces cas-là, des bugs subtils ou d’autres problèmes se nichent souvent dans le code sans même être remarqués, et même lorsqu’on les repère, il est fréquent de ne pas en comprendre la cause

• J’ai trouvé particulièrement frappante la conclusion selon laquelle les assistants LLM ont considérablement réduit la difficulté des derniers 20 % sur les side projects
  Pour moi, l’aspect le plus intéressant de ce parcours n’est pas tant les nouvelles apps que le fait d’avoir retrouvé l’envie de coder et de pouvoir à nouveau livrer des side projects propres et aboutis
  C’est comme si j’avais gagné 5 heures par jour, et 200 dollars par mois suffisent

• Je m’en sers surtout pour créer de petits utilitaires, et cela fonctionne vraiment de manière fantastique
  Avec Claude, j’ai réalisé en quelques heures, exactement comme je le voulais, un utilitaire qui affiche l’état des tâches launchctl/launchd (en cours, déchargées, en échec, etc.) comme l’icône de menu d’OrbStack

  • Moi aussi, j’ai créé une app iOS et un plugin Wordpress juste pour mon propre plaisir, et j’en ai été vraiment satisfait
    J’ai l’impression que de plus en plus de gens vont faire pareil, et je me demande si tout le monde ne devrait pas partager son code sur github

• Si quelqu’un développe des logiciels pour Mac depuis 2008, je pense qu’il aurait rapidement remarqué où Claude s’était trompé et aurait pu le corriger immédiatement

  • Des outils comme Claude Code servent à amplifier des compétences et une expérience préexistantes
    Ils ne remplacent absolument pas l’expertise

  • Au final, à la toute fin du texte, on découvre que ce travail coûte 200 dollars par mois, et moi je trouve déjà pénible de dépenser 50 dollars pour Autodesk alors que c’est indispensable à mon hobby principal
    Je pense que ces entreprises d’IA ne sont pas rentables, et qu’à partir du moment où les investisseurs commenceront à exiger des profits, une hausse brutale des coûts ou une dégradation de la qualité du service sera inévitable
    Si ces modèles finissent par perdre en justice pour avoir fourni du code appris sans autorisation, la capacité de Claude à générer du Swift chutera elle aussi immédiatement
    Je me demande vraiment s’il faut s’attendre à ce que Disney perde dans les procès contre l’IA
    Honnêtement, mon commentaire n’a peut-être pas beaucoup de sens, mais la fatigue liée à l’IA est vraiment sévère
    À ce stade, je pense qu’il faudrait carrément interdire ce genre de posts sur HN ou sur d’autres forums tech
    Si quelqu’un postait qu’il a facilement écrit du code avec Google ou StackOverflow, tout le monde réagirait avec sarcasme tant ce serait banal ; pour moi, ce genre de post revient exactement au même
    J’en ai assez des histoires de gens qui « voyagent en passager clandestin » dans leur hobby ou leur métier grâce à l’IA

• Construire mes propres outils sur mesure avec des outils comme Windsurf et des outils CLI est devenu bien plus facile qu’avant
  C’est une période vraiment passionnante

• J’ai le pressentiment qu’on arrive bientôt à une époque où quelqu’un utilisera un LLM pour cloner MacOS lui-même

• Il y a quelques semaines, j’ai réussi à utiliser des outils LLM avec retro68 et c++ pour faire démarrer un moteur de rendu filaire 6DOF dans une app system 6 (Mac classique)