Retour d’expérience sur l’implémentation de fonctionnalités avancées de Ghostty avec le vibe coding

• Publication de l’ensemble du processus de développement de la fonction de notification automatique de mise à jour non perturbatrice de Ghostty sur macOS, réalisée principalement avec des outils de codage agentique par IA, avec une fonctionnalité réellement déployable finalisée en environ 8 heures sur 16 sessions pour un coût de tokens de 15,98 $
• À la suite de l’incident où une invite de mise à jour de Ghostty a perturbé une démo pendant la keynote d’OpenAI, décision de passer à une approche non modale affichant l’état des mises à jour via un petit élément d’interface dans la barre de titre ou en bas de la fenêtre, sans interrompre le travail
• Avant de démarrer avec l’IA, élaboration d’un plan général backend/frontend en s’appuyant sur le protocole d’UI personnalisée du framework Sparkle et sur le contrôleur d’accessoires de barre de titre, puis utilisation de l’IA comme outil de prototypage
• Utilisation d’une approche par étapes : prototypage UI, changement de direction en cas d’échec de résolution de bug, et sessions de nettoyage répétées (documentation, refactorisation) pour améliorer les performances des futures sessions IA, générer du code de simulation, etc.
• Mise en avant de la valeur d’un mode de travail asynchrone permettant de faire autre chose, comme préparer le petit-déjeuner de la famille, pendant que l’IA travaille ; tout le code généré par l’IA est rigoureusement relu manuellement avant déploiement, avec comme principe de ne jamais déployer du code qui n’est pas compris

---

Aperçu de la fonctionnalité

• La fonctionnalité terminée est une notification de mise à jour non perturbatrice sur macOS qui ne masque pas la fenêtre
  • Affiche l’état des mises à jour dans la fenêtre du terminal sans perturber le travail, par exemple en créant une fenêtre ou en lui donnant le focus
  • Le besoin d’améliorer l’UX a été confirmé après l’apparition d’une invite de mise à jour de Ghostty pendant une keynote d’OpenAI
• Décision de rendre la notification de mise à jour non intrusive
  • Au lieu d’une fenêtre popup, choix d’un petit élément GUI non modal affiché quelque part sans déranger l’utilisateur
  • L’emplacement par défaut de la notification est à droite de la barre de titre, avec des alternatives comme une surcouche en bas de la fenêtre selon le style, par exemple si la barre de titre est masquée
• Adoption d’une stratégie d’outil d’assistance piloté par l’humain consistant à utiliser des agents IA tout au long du développement, tout en effectuant en parallèle des retouches manuelles, du polish et la revue finale

Planification avant l’utilisation de l’IA

• Établissement d’un plan général avant même d’ouvrir un outil d’IA
  • Étude de la documentation de Sparkle, le framework de mise à jour macOS utilisé par Ghostty et extrêmement populaire
  • Découverte de la prise en charge d’une UI personnalisée via un protocole Obj-C, rendant la chose possible même s’il faut réimplémenter beaucoup d’éléments
• Une fois une idée générale du backend acquise, réflexion sur le frontend
  • Idée vague d’intégrer un petit bouton dans la barre de titre
  • Il était déjà connu que macOS prend en charge une UI personnalisée dans la barre de titre via le contrôleur d’accessoires de barre de titre, mais l’apparence et le ressenti restaient flous
• Le point de départ était jugé suffisant pour commencer
  • L’IA est un excellent outil de prototypage, donc savoir ce qu’on ne sait pas suffit déjà pour démarrer
  • Une vision d’ensemble assez solide était en place

Première session : prototypage UI

• Prompt de départ de la première session de codage agentique
  • Personnaliser SPUUserDriver pour fournir une notification de mise à jour non intrusive et demander l’activation de l’installation
  • Limiter le travail uniquement à l’UI
  • Demander un plan pour créer une vue SwiftUI capable d’afficher les différents états requis par SPUUserDriver
  • Demander un plan pour l’affichage dans le coin supérieur droit de la barre de titre de la fenêtre macOS
  • Oracle, c’est quoi ? — le sous-agent en lecture seule propre à Amp, qui utilise un modèle plus lent et plus coûteux, mais généralement meilleur pour raisonner
• Décision de se concentrer d’abord sur le prototype UI
  • L’agent n’a pas reçu pour consigne de construire toute la fonctionnalité
  • Premièrement, l’UI/UX souhaitée n’était pas encore claire, donc on ne pouvait pas raisonnablement attendre de l’IA qu’elle gère cela de manière cohérente au milieu d’autres changements
  • Deuxièmement, de petits blocs de travail sont plus faciles à relire, comprendre et itérer
• Demande explicite de ne rédiger qu’un plan et pas de code
  • Comme la demande était relativement floue, il était important de revoir le plan avant de lancer beaucoup de travail — et donc beaucoup de consommation de tokens
  • Conseil : construire de manière interactive un plan global avec un agent est une première étape importante pour les tâches non triviales
  • En général, cela peut être enregistré dans un fichier comme spec.md, puis réutilisé dans de futures sessions avec une demande du type « réfère-toi à @spec.md et effectue telle tâche »
• L’agent a proposé un plan jugé suffisamment convaincant, et l’implémentation a donc été autorisée
  • L’UI générée allait dans une très bonne direction
  • Il y avait de nombreux problèmes de finition (espacements, couleurs, etc.), mais voir l’UI a déclenché une vraie inspiration sur ce qui était souhaité
  • Conseil : l’IA est utilisée très souvent pour obtenir de l’inspiration ; dans ce cas, une grande partie du code UI généré a été conservée (mais pas tout), mais il arrive aussi très souvent de donner un prompt à l’agent, de tout jeter ensuite, puis de refaire manuellement
  • L’étape créative du « zéro à un » est très difficile et chronophage, et l’IA joue très bien le rôle de muse

Se heurter à un mur

• Entrée dans la zone de slop entre les chats 11 à 14
  • Le code généré par l’agent comportait des bugs sérieux et il a complètement échoué à les corriger
  • Et moi non plus, je ne savais pas comment les corriger
• Quelques tentatives désespérées pour corriger les bugs
  • Si l’agent trouvait la solution, cela permettrait de l’étudier et d’apprendre
  • Et en cas d’échec, le coût restait presque nul
  • Si l’agent réglait le problème mais que le code restait incompris, retour en arrière : aucun code incompris n’est déployé
  • Pendant les échecs, changement d’onglet pour rechercher le problème et tentative de le résoudre soi-même
• À ce stade, prise de conscience qu’il fallait prendre du recul, revoir le travail effectué et établir son propre plan
  • Temps nécessaire pour s’autoformer et réfléchir de manière critique
  • L’IA n’était plus une solution, mais une dette

Sessions de nettoyage

• Les sessions suivantes ont été consacrées à guider l’agent pour nettoyer le code
• Deuxième session : déplacement de certaines méthodes vers un meilleur emplacement
  • Déplacement et généralisation des fonctions de fond plein, premier plan et badge de UpdateAccessoryView.swift vers UpdateViewModel.swift
• Troisième session : ajout de documentation au code
  • Mise à jour de la documentation de UpdateBadge.swift
  • Conseil : ajouter de la documentation permet de revalider sa propre compréhension du code et aide à former les futurs agents qui devront lire et modifier ce code
  • Les agents sont bien plus performants lorsqu’ils disposent à la fois d’explications en langage naturel et du code
• Quatrième session : déplacement du view model vers un emplacement global à l’application
  • Le travail initial l’avait placé au niveau de la fenêtre, alors que les informations de mise à jour relèvent du niveau application
  • De petites modifications manuelles, généralement mineures, ont aussi été effectuées au passage
• Importance de la phase de nettoyage
  • Nettoyer efficacement exige une assez bonne compréhension du code, ce qui oblige à ne pas accepter aveuglément le code écrit par l’IA
  • Un code mieux structuré et mieux documenté aide à améliorer les performances des futures sessions agentiques
• Cela a été surnommé, sur le ton de la plaisanterie, des « sessions anti-slop »

Face aux bugs

• Revenir au bug découvert lors des premières sessions
  • Reconsommer quelques sessions pour amener l’agent à l’identifier
  • Partir d’une formulation vague puis rendre progressivement l’approche plus précise
• Première session vague : avec les onglets natifs standard, la vue accessoire de mise à jour n’est pas visible ; il faut qu’elle reste visible dans la barre de titre de la fenêtre — échec
• Deuxième session plus précise : mettre à jour les contraintes de la barre d’onglets dans TerminalTabsTitlebarTahoe.swift pour aligner le bord droit de la barre d’onglets sur le bord gauche de la vue accessoire de mise à jour — échec
• Troisième tentative d’une autre approche plus précise : modifier TitlebarTabsTahoeTerminalWindow.swift pour faire de la barre d’onglets une vue accessoire supérieure plutôt qu’une vue accessoire inférieure, afin de placer les onglets dans la barre de titre — échec
• Dernière tentative : la vue accessoire de droite et sa mise en page entrent en conflit avec la configuration de la vue accessoire de mise à jour dans TerminalWindow.swift ; peut-on imposer que la barre d’onglets apparaisse toujours à gauche de la notification de mise à jour ? — échec
• Pendant tout ce processus, tentative aussi de résoudre le problème par moi-même via recherche manuelle et effort humain
  • Les prompts plus précis s’appuyaient sur ce que j’avais appris pendant ce processus
  • Globalement, cela ne fonctionnait clairement pas
• Conclusion que je ne pouvais pas le résoudre seul, décision de changer de direction
  • Pour le style de barre de titre problématique, placer la notification de mise à jour dans le coin inférieur droit, superposée au-dessus de la vue de contenu de la fenêtre plutôt que dans la barre de titre
  • Ghostty dispose d’une configuration qui masque complètement la barre de titre, donc il fallait de toute façon prendre cela en charge
  • Même si le problème de style de barre de titre pouvait être résolu plus tard, il faudrait quand même conserver la prise en charge de cet autre mode
• Session suivante menée selon ce plan avec un prompt très précis
  • Renforcer le système Update pour prendre aussi en charge l’approche par superposition dans TerminalView.swift
  • La notification de mise à jour doit apparaître en bas de la fenêtre et au-dessus du texte (donc sans redimensionner la vue du terminal)
  • Tous les comportements au clic sont identiques à ceux de la vue accessoire
• Exécution vraiment réussie ; j’ai ensuite fait beaucoup de travail manuel de finition (déplacements, renommages, etc.), mais le cœur du travail était solide

Démarrage du backend

• L’UI me semblait suffisamment bonne
  • J’ai noté de nombreux problèmes de finition à traiter plus tard, mais je voulais surtout passer au backend pour découvrir d’éventuelles inconnues susceptibles de faire dérailler le plan
• Création manuelle d’un fichier d’échafaudage avec des fonctions incomplètes et divers commentaires TODO. Démarrage d’une nouvelle session
  • Demande de compléter UpdateDriver.swift et de lire la documentation Sparkle pour comprendre le fonctionnement
  • Conseil : l’IA est excellente pour remplir les blancs ou dessiner le reste de la chouette
  • Ce schéma consistant à créer un échafaudage avec des noms de fonctions descriptifs, des paramètres, des commentaires todo, etc. est très courant et fonctionne très bien
• En pratique, il a fait un très mauvais travail et j’ai jeté tout ce code
  • Le code généré fonctionnait, mais l’approche était manifestement mauvaise
  • Il mélangeait beaucoup de préoccupations différentes et la manière de stocker l’état dans le driver était clairement incorrecte
• En étudiant ce qui avait été produit, j’ai réalisé que les view models étaient structurés de façon sous-optimale
  • Pour fournir un meilleur cadre à l’IA (et à un humain si j’avais choisi de l’écrire manuellement), passage en mode nettoyage

Grand nettoyage de structure

• D’expérience, la propreté de l’UI frontend et du backend métier dépend souvent de la qualité des view models intermédiaires
  • J’ai passé du temps à restructurer manuellement les view models
  • Passage de structs remplies d’optionnels à des unions taguées, avec renommage et déplacement de certains types
• Je savais d’expérience que ce petit travail manuel au milieu aiderait l’agent à réussir dans les futures sessions, aussi bien côté frontend que backend
  • Une fois la restructuration terminée, la première chose que j’ai faite a été de demander à l’agent de finir à nouveau la chouette
  • Cette fois, il a examiné les modifications, mis à jour le code dépendant selon le nouveau style et supprimé l’ancien code
• Poursuite d’une série de sessions marathon de nettoyage
  • Demande de suppression supplémentaire de code mort
  • Après avoir moi-même cassé la build, demande à l’agent de corriger pendant que j’assistais à une réunion
  • Conseil : « j’ai mis le bazar, merci de corriger mes erreurs » est un autre cas d’usage fréquent pour un agent
  • Début d’un peu de refactorisation dans les vues
  • Travail de nettoyage supplémentaire

Simulation

• Lors de la première session UI, demande à l’agent de générer du code de démonstration pour pouvoir réellement voir l’UI sans effectuer de vraie vérification de mise à jour
  • Le flux de mise à jour comporte plusieurs scénarios, et jusqu’ici seul le happy path avait été testé
• Session suivante : extraction du code de simulation dans un fichier dédié et demande à l’agent de générer davantage de scénarios
  • Extraction du code de simulation de mise à jour de AppDelegate.swift vers un fichier dédié dans Features/Update
  • Inclusion de plusieurs scénarios de simulation (happy path, introuvable, erreur, etc.) afin de tester facilement différentes démos
  • Conseil : l’agent excelle dans la génération de tests et de simulations
  • Le code de simulation généré ici est honnêtement assez horrible, mais il fonctionne et ne fait pas partie du binaire de release, donc sa qualité importe peu
  • Je ne l’ai même pas nettoyé au-delà du minimum visible dans la session
• Exécution de diverses simulations et découverte de plusieurs améliorations UX
  • Nettoyage de l’état « pas de mise à jour »
  • Réinitialisation de l’état lors de la vérification d’erreur
  • Modification du texte et du style pour l’état de demande d’autorisation

Dernier kilomètre

• À ce stade, il y avait un backend et un frontend fonctionnels, et il fallait simplement tout relier
• Session suivante : prompt à l’agent
  • Créer une classe UpdateController semblable à SPUStandardUpdaterController.m de Sparkle, mais pour le type d’updater
  • Il a fallu quelques allers-retours et un peu de finition manuelle, mais on y est arrivé
• Ensuite, ajout de petites améliorations
  • Pour l’état « mise à jour disponible » avec appcast, examiner SUAppcastItem et afficher d’autres métadonnées pertinentes si elles sont définies
  • Par exemple, la longueur du contenu pour la taille

Autre chose ?

• Pour l’agent, le dernier prompt consiste toujours à demander ce qui a été manqué
  • Faire cela, que j’aie écrit le code moi-même manuellement ou non
  • Y a-t-il d’autres améliorations possibles dans la fonctionnalité Features/Update, sans écrire de code, type conseil Oracle, et en réfléchissant aux parties du code où ajouter davantage de tests unitaires
• Comme j’avais mis en avant le vrai problème, j’ai demandé de l’implémenter
  • J’ai constaté qu’il était plus simple de dire à l’agent de « tout faire » que de demander précisément quoi faire, car il est plus facile de nettoyer ensuite dans un commit optionnel
• Ce qui était amusant dans cette session, c’est que l’agent a vraiment commencé à partir dans un terrier de lapin complètement fou, et j’ai dû intervenir pour lui dire d’arrêter
  • « Stop stop stop. Annule tous les éléments des acteurs principaux »
• J’ai aussi remarqué qu’il existait une meilleure méthode, alors que cela avait été fait de manière assez médiocre
  • Pour les messages d’erreur, il doit bien exister une méthode standard de SwiftUI plutôt que de les tronquer ; il faut ajouter un élément d’UI supplémentaire permettant de voir le message complet

Coût et temps

• Le travail a représenté au total 16 sessions distinctes, pour une dépense de 15,98 $ de tokens dans Amp
  • Je ne vais pas spéculer sur le fait que ce soit généralement cher ou bon marché, mais personnellement j’ai dépensé plus que ça au café pendant les deux jours consacrés à cette fonctionnalité
• J’estime le temps réel total passé sur cette fonctionnalité à environ 8 heures
  • Le premier et le dernier commit s’étalent sur 3 jours, mais je n’ai travaillé sur ordinateur qu’environ 4 heures par jour
  • Je n’ai pas consacré tout ce temps uniquement à cette fonctionnalité
  • Par exemple, pendant que je travaillais dessus, j’ai aussi géré la publication d’une mise à jour de Ghostty, fait une apparition d’une heure chez ThePrimeagen, et donné une présentation invitée lors de l’événement annuel all-hands de Zoo
  • J’ai un jeune enfant à la maison, donc le « temps ordinateur » est très planifié et très limité
  • L’estimation de 8 heures est donc plutôt généreuse
• Beaucoup de gens sur Internet débattent de savoir si l’IA permet de travailler plus vite
  • Dans ce cas, je pense que j’ai livré plus vite que si j’avais tout fait moi-même
  • En particulier parce que les itérations triviales de styling SwiftUI sont, pour moi, bien trop ennuyeuses et chronophages, et que l’IA est très forte là-dessus
• Ce que je préfère, plus que le débat plus rapide/plus lent : l’IA peut travailler pour moi pendant que je vais faire autre chose
  • Une photo a été prise pendant l’une des sessions de nettoyage alors que je préparais le petit-déjeuner pour ma famille
  • Il y a toutes sortes de réactions du type « je n’ai pas envie de coder en cuisinant » ou « sois plus présent »
  • C’est très bien si vous voulez faire ainsi ; dans mon cas, dans cet exemple précis, j’étais la première personne réveillée à la maison et je préparais le petit-déjeuner pendant que tout le monde dormait encore
  • Je ne fais pas ça à chaque instant où je suis éveillé
• Conclusion : ça marche pour moi
  • Je n’essaie absolument pas de vous convaincre
  • Je n’ai aucun lien financier avec une entreprise d’IA
  • En tant que personne qui obtient beaucoup de succès avec les outils d’IA et aime en parler, on me demande souvent de partager des exemples
  • C’est ce que je fais ici

Conclusion

• La fonctionnalité est belle, fonctionne très bien, et a été fusionnée après une révision manuelle finale
  • La « révision manuelle finale » est très, très, très importante ; ne déployez pas de code écrit par l’IA sans une revue manuelle approfondie
  • Si vous faites partie des utilisateurs de Ghostty qui utilisent les versions tip, c’est disponible dès maintenant
  • Si vous utilisez les versions taguées, ce sera disponible dans Ghostty 1.3
• Je défends ouvertement l’importance de partager publiquement les sessions de coding agentique
  • L’une des raisons est que c’est une méthode incroyablement puissante pour apprendre aux autres à utiliser efficacement ces outils
  • J’espère que ce billet aidera à le montrer

[GN⁺]

Avis Hacker News

• J’utilise souvent l’IA comme source d’inspiration, et cette fois encore j’ai gardé une bonne partie du code UI qu’elle a généré, même s’il m’arrive aussi de confier la tâche à un agent, puis de tout jeter et de réécrire moi-même (à la main !). La phase de création « de zéro à un » est toujours très difficile et prend énormément de temps, donc l’IA excelle vraiment comme muse pour moi. C’est d’ailleurs le plus grand atout des agents de code. Beaucoup s’inquiètent de la maintenance ou du chaos dans les projets centrés sur l’IA, mais personnellement ça ne me dérange pas. Tant que je peux atteindre rapidement un stade où je peux vraiment manipuler la fonctionnalité du projet et continuer à la corriger, ensuite tout s’accélère vraiment. Jusqu’à cet « instant en or », je considère que c’est là que se situe pour moi le coût principal, soit 80 % du travail en programmation. C’est pourquoi, honnêtement, j’ai du mal à comprendre les objections aux agents de code. Même si le résultat n’est que du code qu’on finit par jeter entièrement, j’y vois malgré tout une valeur évidente. PS : il faut toujours peser le bacon

  • J’ai justement discuté de ce sujet avec quelqu’un récemment, et je suis globalement d’accord. Ces outils sont excellents pour produire facilement des prototypes qui permettent de tester des idées en manipulant directement les interactions. Mais il y a deux problèmes. D’abord, c’est déjà pénible de convaincre qu’un prototype qui paraît presque terminé est en réalité encore loin d’être prêt pour la production, et le code généré par LLM en est encore bien plus éloigné que les prototypes que je faisais avant de manière classique. Ensuite, quand je fabrique un prototype à la main, j’apprends directement des choses sur la stack technique ou l’implémentation. L’objectif principal est d’aller vite, mais j’en retire aussi beaucoup d’enseignements techniques, et souvent mes prototypes finissent même par influencer la direction technique. À l’inverse, avec un prototype basé sur un LLM, le code lui-même est presque inutile, et si l’on décide réellement de lancer quelque chose, il faut pratiquement repartir de zéro. On a validé l’idée, mais pas du tout la technique ni la conception. Cela dit, je trouve quand même ça utile. Je crois fermement au principe « les prototypes doivent aller vite », et l’usage des LLM m’a permis d’assembler presque instantanément des systèmes assez conséquents. Mais cela demande un changement de conception du processus. Un prototype sans LLM correspond à peu près aux étapes 4 ou 5 sur 10, tandis qu’un prototype avec LLM est plus proche de l’étape 2. Ce n’est pas forcément mauvais, mais il faut ajuster ses attentes quant à la quantité de travail restante après le prototype, qui est plus importante qu’avant

  • Ce qui compte, c’est votre idée selon laquelle « une fois le projet suffisamment lancé pour qu’on puisse vraiment courir avec, les choses avancent tout de suite ». Pour moi, au contraire, la phase « de zéro à un » est la plus gratifiante et la plus amusante. C’est à ce moment-là que tout semble possible et qu’on peut créer quelque chose qui n’existait pas auparavant. Si l’IA me trace la direction à l’avance, j’ai l’impression d’y perdre une bonne part de cette créativité

  • À vous lire, on dirait que l’angoisse de la page blanche est une vraie difficulté pour vous. Je comprends qu’un outil qui l’efface puisse apporter un gros gain de productivité. Mais tout le monde n’a pas le même problème. Le développement logiciel est une activité très personnelle, donc les workflows et les expériences peuvent être très différents d’une personne à l’autre. Il ne s’agit pas de dire qu’une méthode est meilleure qu’une autre, mais de reconnaître qu’il existe des outils adaptés à chacun, et qu’il est important d’accepter et de faire confiance à l’expérience de chacun telle qu’elle est. Dans les débats autour des LLM, les deux camps ont tendance à supposer que l’autre fonctionne comme eux

  • J’ai vu cette semaine une interview sur l’environnement de développement de Mitchell, et quand on lui a demandé pourquoi il utilise neovim, il a répondu : « Je ne veux pas d’un outil qui écrive du code à ma place. » Ce n’est pas une critique, mais cela montre qu’un excellent développeur comme Mitchell voit tout de même de la valeur dans les LLM, contrairement à l’intellisense d’autrefois, et c’est un point à noter

  • J’explique ça à mes collègues comme « appliquer la loi de Cunningham à moi-même » Cunningham's Law: « pour obtenir la bonne réponse sur Internet, le moyen le plus rapide n’est pas de poser une question, mais de publier une mauvaise réponse ». Quand je me retrouve devant un écran vide, je peux rester bloqué longtemps sans rien faire, mais dès que j’ai quelque chose à critiquer, je deviens immédiatement productif

• Je respecte sincèrement l’avis de Mitchell en réponse à l’incident OpenAI, même si c’est positif pour ghostty. J’ai rarement vu un éditeur de logiciels essayer activement de réduire les frustrations ou les irritations des utilisateurs — surtout quand on pense à des choses comme MS Auto Update —, donc c’est un changement très bienvenu. Et cet article montre aussi un usage responsable de l’IA en programmation ; à mon avis, cela ne correspond pas du tout à la définition originale de vibe coding, telle qu’elle était évoquée de manière exagérée

  • Je pense que le terme même de « vibe coding » ne convient absolument pas ici. Ce terme est utilisé à tort et à travers un peu partout

  • Je suis d’accord avec l’idée d’« utiliser l’IA de manière responsable en programmation ». Ce n’est pas du vibe coding, mais du vibe engineering, tel que simonw l’a présenté ici pour la première fois. Article lié

• À noter que Ghostty impose désormais de divulguer explicitement l’usage d’outils de codage IA lien vers la PR correspondante

• Cet article montre pourquoi les agents IA sont particulièrement efficaces pour le travail sur les frameworks UI. Je développe moi aussi une application en Rust et GTK, et mon workflow est très similaire. Ce n’est pas que je ne sache pas comment faire, mais l’IA m’aide énormément en prenant en charge l’essentiel des recherches répétitives, fastidieuses, et des tâtonnements liés au travail sur les frameworks UI. Mitchell comprend l’ensemble du code pendant tout le processus. Il sait déjà ce qu’il doit faire, et en ce sens, cela n’a absolument rien à voir avec ce qu’on appelle du « vibe coding ». Il n’existe pas de raccourci séparé pour devenir expert. J’aime vraiment beaucoup Ghostty

• Grâce aux LLM, coder est redevenu amusant. Au travail, les LLM m’aident sur l’étape la plus difficile, celle du démarrage, ce qui me permet d’entrer rapidement dans le vif du sujet. Ils sont aussi vraiment utiles pour comprendre une nouvelle base de code ou écrire les parties ennuyeuses. Mais le vrai plaisir commence avec les projets perso. Je peux concrétiser des idées spontanées très rapidement. Je n’ai plus besoin de passer des heures à écrire du code boilerplate ou à me battre avec l’outillage. Les parties qui me sont moins familières, je les délègue à un agent, ou bien je fais générer une fonctionnalité d’un seul prompt, puis si le résultat ne me plaît pas, j’annule immédiatement

• Question un peu hors sujet, mais je ne comprends pas pourquoi presque toutes les applications doivent encore avoir leur propre framework de mise à jour. On ne pourrait pas intégrer cette fonction à l’App Store ou au gestionnaire de paquets ?

  • Dans l’écosystème macOS, ce genre de chose est assez difficile

  • Par exemple, sur Ubuntu, c’est assez pratique. Si on télécharge et installe directement la dernière version, on continue ensuite à recevoir automatiquement les mises à jour

• En fin de compte, la partie même où vous reconnaissez ne pas être très bon — la phase de zéro à un — devient un domaine que vous ne pourrez jamais vraiment apprendre par vous-même si vous le déléguez à l’IA. Si vous voulez continuer à savoir le faire vous-même à l’avenir, il faut aussi l’exercer personnellement

• Ghostty était vraiment excellent, et j’étais presque prêt à abandonner iTerm, jusqu’au moment où j’ai appuyé sur cmd-f et qu’il ne s’est rien passé, donc j’ai renoncé page des issues et retours

  • Je me demande de quoi on parlerait dans les articles sur ghostty si cmd-f avait été là dès le départ. J’avoue que commencer à entendre ça dans chaque discussion devient un peu lassant. Il pourrait y avoir des débats bien plus intéressants sur les outils LLM ou les façons de coder, mais au final tout le monde revient encore à cmd-f

  • Amusant d’ailleurs : le week-end dernier, j’ai utilisé Claude pour implémenter la fonction de recherche dans Ghostty. La recherche elle-même existait déjà dans un code qui fonctionnait vaguement, donc il s’agissait surtout de la raccorder à l’UI. En deux sessions (environ 10 heures au total), j’ai réussi à faire fonctionner dans le frontend Linux la recherche de base, la mise en surbrillance et la navigation vers l’occurrence précédente/suivante. Cette fonction de recherche est encore clairement en WIP et n’est pas prête pour un usage général. En travaillant dessus, j’ai pris la mesure de la complexité qu’il y a à faire fonctionner sur du texte en streaming ce qui semble être une fonctionnalité « basique »

  • Moi aussi, j’ai trouvé Ghostty tellement minimaliste que je suis malheureusement vite revenu à Warp. Pour information, la taille par défaut du tampon de scrollback de Ghostty est d’environ 10 Mo, mais on peut l’ajuster librement dans la configuration

  • Cette fonction de recherche est actuellement prévue pour mars 2026 avec la v1.3 lien vers la roadmap

• En lisant le passage de l’article qui dit « examinons ce qui a conduit à l’ajout de cette fonctionnalité », cela m’a rappelé à quel point nous supportons encore beaucoup d’inconfort au niveau des OS. Les présentations et le partage d’écran existent pourtant depuis des décennies, alors pourquoi est-il encore si difficile d’avoir ne serait-ce qu’un réglage de base qui force uniquement la fenêtre de présentation à être visible à l’écran ?

[xguru]

C’est Ghostty, l’outil auquel Mitchell Hashimoto, cofondateur de HashiCorp, consacre presque tout son temps en ce moment.

Sortie de Ghostty 1.0 - un émulateur de terminal rapide et multiplateforme
libghostty arrive

Tout en défendant le codage agentique, il explique que le partage de session est vraiment important,
et la plupart des liens pointent vers des sessions AMP. Amp - outil de codage agentique