23 points par GN⁺ 2026-01-07 | 3 commentaires | Partager sur WhatsApp
  • Claude Opus 4.5 montre un niveau de développement autonome qui, contrairement aux agents d’IA de coding existants, lui permet de construire des applications abouties sans intervention du développeur
  • D’un simple utilitaire Windows de conversion d’images à un outil d’enregistrement et de montage vidéo, en passant par une application d’automatisation de publication basée sur l’IA et une application de suivi de commandes et de calcul d’itinéraires, il a finalisé en peu de temps des projets réellement fonctionnels
  • Opus 4.5 gère de lui-même des tâches de développement complexes comme la configuration d’un backend Firebase, l’analyse des logs d’erreur et leur correction automatique ou encore la mise en place du déploiement avec GitHub Actions
  • L’auteur explique qu’il ne comprend pas entièrement la structure du code, mais a constaté qu’Opus 4.5 corrige lui-même les bugs et propose même des refactorings
  • À travers cette expérience, il souligne que la possibilité pour l’IA de remplacer entièrement les développeurs devient concrète, et qu’il s’agit d’un tournant vers une ère de développement centrée sur l’IA

L’arrivée d’Opus 4.5 et sa différence avec les agents IA existants

  • Les agents IA existants souffraient souvent d’une génération de code inefficace et de corrections d’erreurs répétitives, ce qui réduisait fortement la productivité
    • Après de nombreux copier-coller et cycles de correction, la base de code finissait souvent détériorée
  • Opus 4.5 dépasse ces limites : il écrit correctement l’essentiel du code dès le départ et, lorsqu’une erreur survient, il enchaîne lui-même les builds et corrections via le CLI
  • L’auteur le décrit comme « le modèle dans lequel la promesse du coding par IA s’est enfin concrétisée »

Projet 1 – Utilitaire Windows de conversion d’images

  • Opus 4.5 a réalisé en une seule demande un utilitaire permettant de convertir des formats d’image depuis le menu contextuel du clic droit dans l’Explorateur Windows
    • Utilisation du dotnet CLI pour automatiser le build et la correction des erreurs
    • Seules les erreurs XAML ont été vérifiées dans Visual Studio avant d’être copiées puis transmises
  • Il a aussi mis en place le site web de déploiement, le script d’installation PowerShell et le pipeline de déploiement automatique avec GitHub Actions
  • Le logo a été créé avec Figma AI, et Opus a rédigé le script de conversion SVG ainsi que le script de génération des formats d’icônes

Projet 2 – Outil d’enregistrement d’écran et d’édition

  • En partant d’un utilitaire d’enregistrement GIF similaire à LICEcap, il l’a étendu à des fonctions de montage vidéo et image
    • Des fonctions d’édition comme l’ajout de formes, le recadrage ou le flou ont été implémentées en quelques heures
  • Le code source est publié sur GitHub, et l’auteur précise que « le développement a atteint un niveau déjà très avancé en quelques heures »
  • Cela montre qu’Opus 4.5 peut gérer non seulement l’UI, mais aussi les intégrations backend

Projet 3 – Application d’automatisation de publication par IA

  • Une application mobile basée sur l’IA capable de publier automatiquement sur une page Facebook a été développée avec Opus 4.5
    • Après l’envoi d’une photo, l’IA génère une légende puis planifie la publication
    • Le backend Firebase, l’authentification, le stockage et les fonctions cloud ont été configurés directement par Opus via le CLI
  • L’auteur raconte qu’Opus a terminé l’application pendant qu’il installait des stores
  • Opus analyse automatiquement les logs d’erreur pour les corriger et a même créé un tableau de bord d’administration
  • Un travail qui prenait auparavant plusieurs mois a été bouclé en quelques heures

Projet 4 – Application de suivi de commandes et de calcul d’itinéraires

  • L’application parse les e-mails de commande Gmail pour calculer automatiquement le planning, l’itinéraire, le temps de conduite et le journal kilométrique pour la fiscalité
  • Opus 4.5 a traité en une seule fois l’intégration de l’authentification Google et la connexion à Firebase
  • L’auteur estime qu’« Opus a parfaitement exécuté un travail qui aurait été pénible à réaliser manuellement »

Compréhension du code et questions de qualité

  • L’auteur souligne que l’application fonctionne parfaitement bien qu’il ne connaisse pas Swift
  • Opus 4.5 détecte et corrige lui-même les bugs, ce qui lui permet de poursuivre le développement sans comprendre la structure interne du code
  • À propos de la qualité du code, il affirme que « si le code est destiné à être lu et maintenu par une IA, la lisibilité humaine importe peu »
  • En utilisant dans VS Code un prompt dédié à l’écriture de code pour l’IA, il génère un code structuré avant tout pour être facile à comprendre par un LLM

Principes de coding centrés sur l’IA

  • Le prompt part du principe qu’il s’agit de « code écrit et maintenu par une IA »
    • Il met l’accent sur une structure simple, des points d’entrée clairs, un minimum d’abstraction et un faible couplage
    • Il privilégie aussi un flux de contrôle explicite, des fonctions simples, des logs structurés et une régénération facile
  • Lors d’un refactoring, Opus rassemble dans un document les améliorations prioritaires par niveau (haut, moyen, bas)
  • Lors des vérifications de sécurité, il lui demande d’examiner les clés API, la gestion du login et le stockage éventuel de données sensibles
    • L’auteur précise qu’il reste « encore inquiet », avec un niveau de confiance d’« environ 80 % » sur la sécurité

Le basculement vers l’ère du développement par IA

  • L’auteur dit ressentir à la fois « de l’excitation et une forme de vide face à cette réalité où l’on peut créer en quelques heures »
  • Il pensait autrefois que « l’IA ne pourrait pas remplacer les développeurs », mais reconnaît désormais qu’il n’est plus possible d’écarter cette éventualité
  • En conclusion, il insiste : dans un environnement de développement centré sur l’IA, il ne faut pas hésiter à se lancer et à construire soi-même
  • Enfin, il avertit que « la gestion des clés API doit rester de votre propre responsabilité »

Résumé : Opus 4.5 est présenté comme un modèle au niveau d’un développeur IA capable, au-delà d’une simple assistance au code, de concevoir, implémenter et déployer de manière autonome des applications complètes. L’auteur affirme avoir ainsi fait l’expérience directe de la possibilité réelle que l’IA puisse remplacer les développeurs humains.

3 commentaires

 
wegaia 2026-01-08

J’ai demandé à Opus 4.5 de corriger une seule ligne de code, puis je l’ai vu supprimer de sa propre initiative une dizaine de lignes de configuration juste au-dessus. Quand je lui ai demandé pourquoi il les avait supprimées, il m’a répondu qu’elles lui semblaient simplement inutiles.

 
GN⁺ 2026-01-07
Commentaires Hacker News
  • Le travail d’un ingénieur intermédiaire ne consiste pas simplement à créer une nouvelle app, mais à concevoir une structure en tenant compte de la scalabilité et de l’intelligibilité
    Opus 4.5 gère bien les demandes du type « crée-moi une app », mais lorsqu’on lui demande d’ajouter une fonctionnalité à du code existant comme dans un vrai contexte de travail, il utilise des abstractions étranges ou nécessite plusieurs corrections pour atteindre la qualité voulue
    Un non-technicien pensera peut-être que « tant que ça marche, c’est bon », mais un ingénieur sait que ça ne suffit pas

    • Il existe deux façons de faire « correctement » — la façon adaptée au contexte et la façon que les ingénieurs ont tendance à généraliser
      Je me souviens de disputes en équipe autour de la « bonne réponse ». Au final, il a fallu qu’un regard extérieur rappelle ce qui comptait du point de vue business
      Parfois, la vraie « bonne » méthode consiste à bricoler quelque chose rapidement pour valider la direction
      Le problème apparaît quand on surconçoit dès le départ ou, à l’inverse, quand un manager bloque le refactoring. Au final, tout est question d’équilibre
    • Quand je vois ce genre de projet, j’ai l’impression qu’il suffirait de forker un convertisseur d’images ou un clone de Démineur sur GitHub, donc si un LLM le fait à la place, ça ressemble surtout à un moyen de retirer le copyright
    • Certains affirment que « la qualité du code n’a plus d’importance ». Si les tests passent aujourd’hui, ce serait suffisant, et si un refactoring complet s’impose demain, il suffirait de dépenser un peu plus de crédit pour tout refaire en quelques heures
    • J’ai été surpris de voir à quel point Opus 4.5 suit bien les patterns idiomatiques d’une codebase existante
      Si on lui demande explicitement de lire le code adjacent, il fonctionne bien mieux. Une ou deux phrases supplémentaires suffisent
    • Lorsqu’on ajoute des fonctionnalités à du code existant, si on lui indique directement l’abstraction souhaitée, ça fonctionne progressivement assez bien
      Malgré tout, personnellement, je préfère GPT‑5.2
  • Beaucoup d’ingénieurs sous-estiment les performances actuelles des agents LLM comme Claude Code
    Notre équipe a automatisé avec Claude Code les revues de code, l’automatisation ESLint, les checklists de PR, la synchronisation de documentation et la vérification de la couverture de tests
    On automatise aussi le tri des tickets, si bien qu’au moment où un ingénieur commence à travailler, la moitié du travail est déjà faite
    Un dépôt d’exemple est disponible ici : claude-code-showcase
    Je suis convaincu qu’autour de 2026, ce sera le workflow standard du secteur

    • Il y a un énorme écart d’expérience d’usage des LLM entre le frontend (React, HTML, mobile) et les domaines bas niveau (OpenGL, io_uring, libev, etc.)
      Opus 4.5 crée bien des apps JS, mais si on lui demande d’implémenter en C++ un algorithme d’ombres tiré d’un article de 2003, c’est un désastre complet
      Même en lui donnant la revue du threading de Doom3 BFG par Fabien Sanglard, il ne produit que du code inutile
      En réalité, ce n’est pas qu’on sous-estime les LLM, c’est qu’ils ne sont pas encore pratiques dans certains cas et qu’on attend
    • Beaucoup de gens ont essayé le code assisté par IA très tôt, puis ont abandonné à cause des erreurs et de la frustration
      Mais Opus 4.5 est un cran au-dessus. Il fait beaucoup moins d’erreurs, et la plupart restent mineures
    • En enseignant à l’université, j’ai testé Cursor, Claude Code et Codex avec des étudiants,
      et grâce à l’IA, un projet qui aurait pris deux semaines a été terminé en 5 heures.
      Sans IA, on ne l’aurait probablement même pas tenté
    • C’est assez drôle de voir des README générés par IA qui listent la structure des répertoires alors qu’un simple tree montre déjà tout
    • À l’avenir, il est probable que le métier même de « programmeur » diminue en importance, et que la capacité à créer avec les bons outils devienne plus essentielle
  • J’ai beaucoup utilisé Opus 4.5, et il excelle dans l’analyse de code complexe, mais ce n’est toujours pas un solveur de problèmes au niveau humain
    Par exemple, il peut identifier précisément un algorithme de mise en page de graphe, mais il ne corrige pas lui-même ses erreurs
    Il est excellent pour l’analyse de code et l’enrichissement des connaissances, mais la résolution de problèmes complexes reste hors de portée pour l’instant

    • Copilot a des limites à cause de sa structure qui tronque le contexte pour économiser des tokens
      Si on veut de vraies performances, il faut utiliser l’API directement, et une seule PR peut coûter une somme à trois chiffres
      Référence : models.dev
    • Le fait que Copilot compte l’utilisation d’Opus 4.5 comme trois fois plus de tokens, au point de consommer la moitié du quota mensuel en une semaine, est surprenant
    • Même utilisé uniquement comme outil d’analyse de code, l’IA a beaucoup de valeur
      Pour générer de la documentation aussi, elle fait mieux que les humains et avec un taux d’erreur souvent plus faible
    • Le comportement diffère lorsqu’on l’utilise via des outils tiers
      Je recommande d’essayer directement dans VS Code ou Cursor avec un abonnement Claude Code
  • Pendant les vacances, j’ai mené plusieurs projets avec GPT‑5.x —
    outil d’automatisation Swift, intégration d’un moteur JIT ARM, prototype de synthétiseur, etc.
    GPT‑5.2 et la famille Codex sont aussi puissants qu’Opus, au point de configurer tout un workflow CI d’un seul coup
    Pour quelqu’un comme moi, qui a l’habitude de planifier et de relire le code, c’est un multiplicateur de productivité

    • GPT‑5.2 hallucinait souvent l’existence ou les fonctions d’utilitaires CLI
      Il fallait aller fouiller dans le code source réel pour confirmer l’erreur
    • Les outils comme Gemini 3 Pro (High), Antigravity, Amp et Junie étaient aussi impressionnants
      J’ai terminé en deux semaines une bibliothèque de bindings Ratatui pour Ruby
      Antigravity exécute plusieurs agents en parallèle pour assurer la compression du contexte et la gestion automatique
      Ce genre d’outils avancés offre une expérience totalement différente des versions gratuites
      En combinant les outils Unix et le git CLI, on garde un contexte réduit et on maximise l’efficacité
    • Les LLM sont forts pour le code backend et CLI, mais restent faibles dans les domaines nécessitant un retour visuel comme le frontend HTML/CSS ou JS
      Ils sont bons sur les entrées-sorties structurées, mais échouent là où il faut une « finition sensible »
  • J’ai remarqué récemment sur HN une forte baisse des commentaires négatifs à propos des LLM
    Mais la plupart des projets partagés s’arrêtent encore au niveau de la démo technique
    Construire le contexte, c’est-à-dire comprendre les besoins des utilisateurs, reste toujours du ressort humain
    On peut créer plusieurs apps en un week-end, mais il n’y a presque personne pour les maintenir ensuite

    • La baisse des commentaires négatifs vient peut-être simplement du fait que les gens sont fatigués des débats répétitifs sur « le nouveau modèle 1000 fois meilleur »
    • Il se peut aussi que ceux qui construisent des produits monétisables développent en silence sans rien partager
    • Le déploiement en production et la maintenance exigent un effort énorme
      Karpathy a partagé une expérience similaire — le prototype est facile, le déploiement est difficile
      Pour des outils personnels, une approche centrée sur la résolution de problème plutôt que sur la finition peut suffire
    • Plus les gens utilisent l’IA, plus ils butent sur cette dernière tranche de 20 % qui exige une pensée intégrative
      Si on délègue la réflexion à l’IA, on affaiblit sa propre capacité à penser
    • Même dans le développement de jeux, la règle des 80/20 s’applique telle quelle
      Tester une idée va vite, mais transformer cela en produit fini demande toujours la persévérance humaine
  • Avec Opus 4.5, ce n’est pas seulement la connaissance qui progresse, mais surtout la capacité autonome à résoudre des problèmes
    Dès lors qu’un problème est clairement défini, il a presque toujours réussi à le résoudre, y compris en reverse engineering
    Récemment, au lieu de coder moi-même, je rédige les spécifications puis je pilote Opus pour qu’il exécute et améliore

    • Comme exemples publiés, il y a coding-agent-benchmark et
      un projet de reverse engineering d’un jeu C64
    • Je me demande comment empêcher la « surconception »
    • De mon côté, j’utilise l’app web Claude pour du rubber duck debugging, ce qui est plus efficace
      Claude Code est puissant parce qu’il peut voir toute la codebase, mais il consomme le quota beaucoup trop vite
      Donc je suis revenu à la version web
    • Moi aussi, ces derniers temps, je mène presque tous mes side projects de cette manière
  • Avec Opus 4.5, j’ai tenté un interpréteur JavaScript en Python, un runtime WebAssembly, et même un portage en C d’une routine de recherche de chaînes en Rust
    J’ai fait la plupart de ces expériences sur smartphone, avec des résultats étonnants

    • Si « l’interpréteur JS écrit en Python » est basé sur le MQJS de Bellard, il faut en indiquer la source
      Référence : micro-javascript
    • Il reste faible sur les problèmes qui demandent du raisonnement visuel, par exemple un algorithme de trajet de moisissure visqueuse
    • Je suis curieux du résultat obtenu en « portant une routine Rust en C pour la rendre plus rapide »
    • Je lui ai demandé « écris un interpréteur Python 3 en JavaScript », et j’ai été surpris qu’il fasse même passer les tests
    • Mais récemment, je n’ai pas senti de grande différence. Les modèles stagnent, et ce sont plutôt les frameworks d’agents qui semblent progresser
      Vidéo d’exemple : lien Mastodon
  • Si les développeurs sont réellement embauchés, c’est à cause de leur sens des responsabilités
    Même à l’époque où l’on copiait du code depuis StackOverflow ou GitHub, les outils existaient déjà,
    mais quand un problème survient, c’est toujours une personne qui en porte la responsabilité

    • Aujourd’hui, ce qui compte le plus, c’est quelqu’un capable d’assumer la responsabilité
      Si un collègue digne de confiance est prêt à mettre son nom sur du code généré par IA, alors pourquoi pas
    • Mais le secteur récompense davantage ceux qui fabriquent du nouveau que la responsabilité
      La maintenance reste négligée
    • Désormais, la revue de code en temps réel devient le mode par défaut
      Ce week-end, j’ai construit 80 % d’un SaaS avec l’IA et je n’ai écrit moi-même que le cœur
      En collant une spécification de langage écrite il y a 22 ans, Opus a terminé en 3 minutes le parseur et les tests
      On arrive finalement à un moment où il faut s’adapter au changement comme l’industrie minière
    • C’est pour cela que je préfère utiliser l’IA comme éditrice ou relectrice plutôt que comme autrice
      J’écris le code, et l’IA se charge de chercher les problèmes et de proposer des tests
  • Opus 4.5 m’aide actuellement à créer un nouveau langage de programmation
    Nous discutons même des détails d’implémentation bas niveau, presque comme en pair programming
    Mais sur de grandes codebases, il faut toujours un contrôle systémique humain
    Sinon, Opus modifie les spécifications ou recouvre le tout de rustines temporaires
    Ce n’est pas un outil universel, mais cela pourrait être l’année la plus productive de ma vie
    En même temps, si cette technologie se généralise, j’espère aussi une renaissance des petites communautés web

    • Peut-être qu’un jour l’IA maintiendra elle-même le code,
      mais d’ici là, je pense que des langages faciles à comprendre pour les humains resteront plus importants
    • Certains restent sceptiques et se demandent si cela a vraiment un sens de construire ce genre de chose
    • D’autres réagissaient en plaisantant : « Qui achètera ce roman ? »
  • J’ai demandé à Opus 4.5 « améliore l’ensemble du projet », et il en est sorti une architecture absurde et une multitude de bugs
    Il est excellent pour les tests ou la détection de bugs, mais lui confier la conception de la structure globale mène au regret

    • À la place, il est plus efficace de lui demander « propose des idées d’amélioration », puis d’en sélectionner certaines et de faire expliquer leur logique par Claude avant implémentation
    • Il fonctionne le mieux quand on sait clairement ce qu’il faut améliorer
      « Améliore n’importe quoi » est le pire prompt possible
    • Ce type de cas illustre très bien les faiblesses du modèle
      Quelqu’un avait déjà raconté qu’après avoir laissé un agent « améliorer » un projet toute la nuit, il s’était retrouvé avec 100 000 lignes de code poubelle
      C’est pour cela que le développement guidé par un plan est important
      Référence : The Highest Quality Codebase
    • La plupart des modèles, Opus compris, sont faibles pour améliorer du code existant, mais bons pour écrire du nouveau code
    • 90 % des suggestions de revue de code faites par l’IA sont inutiles, mais les 10 % restants attrapent de vrais problèmes
      On pourrait presque imaginer qu’elle continue à proposer des modifications à l’infini, comme une boucle sans fin
 
[Ce commentaire a été masqué.]