Des codes d'IA pour 24 heures. Le futur est là (et imparfait).

Cole Medin voulait savoir ce qui se passe lorsque l'on cesse de considérer l'IA comme un simple complément de code et qu'on commence à la traiter comme un ingénieur junior qui ne dort jamais. Il a donc mis en place le nouveau « Claude Code agent à long terme » d'Anthropic et a contraint une IA à travailler pendant 24 heures complètes, sans pauses, sans bouton « J'ai fini ». Le résultat : un test de résistance non pas de l'intelligence brute du modèle, mais de la capacité des systèmes agentiques à mener à bien un projet logiciel de bout en bout.

Au lieu de demander une application de liste de tâches ou un simple script Python, Medin a fixé un objectif brutal : un clone fonctionnel du site claude.ai. Cela implique l'historique des discussions, les flux de conversation, les artefacts et une interface utilisateur réactive qui se comporte comme le véritable produit, et non comme une simple page d'atterrissage statique. Le cahier des charges a défini le succès comme une application full-stack fonctionnelle, et non comme un extrait de code éphémère.

Medin a structuré l'expérience autour du développement piloté par les tests dès le départ. Avant que l'IA n'écrive une seule ligne de code, il a défini des tests automatisés de bout en bout qui lancent un serveur de développement, démarrent un navigateur sans interface graphique et naviguent à travers les flux essentiels. La tâche de l'agent : continuer à modifier le code jusqu'à ce que ces tests soient réussis.

Le système open source développé par Anthropic, que Medin a extrait de GitHub, assemble le tout. Un agent « initialiseurs » définit les spécifications, les tâches et les suites de tests, puis un agent de codage modifie de manière répétée les fichiers, exécute les tests et examine les échecs. Chaque session fonctionne comme un mini sprint, et le système enchaîne des dizaines de ces sprints consécutivement.

Environ 24 heures, le système a traversé plus de 50 sessions de codage, touchant aux API backend, aux composants frontend et aux fixtures de test. Les tests dans le navigateur ont agi comme un arbitre impitoyable : ils confirmaient soit qu’une fonctionnalité fonctionnait, soit renvoyaient l'agent dans l'éditeur. Les progrès se sont déroulés par à-coups tandis que l'IA réparait un flux défaillant, puis rencontrait un nouveau cas limite d'intégration.

À la fin, un peu plus de la moitié des tests totaux ont été réussis, ce qui est suffisant pour produire une interface reconnaissable de style claude.ai, mais loin d'être un clone parfait. L'essai a montré que "24 heures d'IA" ne veut pas dire magiquement "SaaS prêt pour la production", mais il a également prouvé que les agents modernes peuvent soutenir un travail logiciel non trivial et à plusieurs niveaux lorsqu'ils disposent d'une structure, de la persistance et des métriques strictes pour définir l'achèvement.

L'agent harness en open source d'Anthropic transforme Claude d'un simple compléteur de texte bavard en quelque chose de plus proche d'un ingénieur junior qui ne se déconnecte jamais. Au lieu d'un seul prompt et d'un amas de code, le harness relie Claude à une structure qui peut fonctionner pendant des heures, voire des jours, sans qu'une personne ait besoin de surveiller chaque étape.

Au cœur de tout cela, le harnais impose une boucle : planifier → coder → tester → affiner. Claude propose un changement, modifie des fichiers, exécute des tests automatisés ou un serveur de développement, inspecte les résultats, puis décide de la prochaine étape. Ce cycle se répète des dizaines de fois, exactement ce sur quoi Cole Medin s'appuie lorsqu'il demande à Claude de poursuivre un clone de claude.ai pendant 24 heures d'affilée.

Les invites à réponse unique vous donnent une réponse instantanée basée sur un aperçu statique du contexte. Une session d'état durable et prolongée accumule l'historique du projet : tests échoués, différences antérieures, décisions architecturales, même commentaires TODO. Au fil de plus de 50 sessions de codage, l'agent peut refactoriser des choix antérieurs, démêler des régressions et poursuivre des stratégies en plusieurs étapes qui seraient impossibles dans une seule fenêtre de réponse.

Le design d'Anthropic divise cela en rôles distincts. Un agent d'initialisation s'exécute en premier, lisant le dépôt, les spécifications et les tests prédéfinis, puis rédige un plan de haut niveau : pile technologique, structure des répertoires, jalons et quels tests définissent « terminé ». Il peut même générer ou affiner des suites de tests afin que le système dispose d'un tableau de scores objectif avant d'écrire du code sérieux.

Une fois que l'initiateur a mis en place le contexte, un agent de codage dédié prend le relais. Cet agent parcourt des tâches concrètes : créer des composants React, relier des routes API, ajuster des schémas de base de données ou corriger un test Playwright spécifique échouant. Chaque itération utilise les outils exposés par le harnais—commandes d'édition de fichiers, exécutables de tests, vérifications de navigateur sans interface graphique—pour effectuer et vérifier les modifications.

Parce que le harness conserve l'état sur disque et le réintègre dans les prompts, Claude peut raisonner sur les migrations d'hier ou sur ce test UI fragile qui continue de faiblir. La course de 24 heures de Medin montre le résultat : le harness ne se contente pas de générer du code, il orchestre une négociation continue entre le plan et la réalité, mesurée en tests réussis plutôt qu'en démonstrations élégantes.

Vos tests, pas vos instructions, ont vraiment conduit cette cascade de 24 heures. Cole Medin a traité le développement piloté par les tests (TDD) comme le volant : définir ce que signifie "terminé" en code, puis laisser Claude Code fonctionner jusqu'à ce que la réalité corresponde à la spécification. Pas de ressentis, pas de "ça semble bien pour moi", juste du rouge ou du vert.

Avant que l'agent n'écrive une seule ligne d'interface utilisateur, Cole a mis en place une suite de tests complète qui capturait les flux principaux de claude.ai. Le cadre connaissait la création de conversations, l'historique des messages, et les artéfacts comme des exigences explicites, et non des objectifs vagues. Le succès signifiait que ces tests réussissaient, sinon l'agent continuait à travailler.

Cette suite de tests agissait comme un contrat entre l'humain et l'agent. Au lieu de gérer chaque composant de manière minutieuse, Cole a simplement dit : voici les comportements, voici les affirmations, satisfaites-les. L'autonomie de l'agent vivait entièrement à l'intérieur de ce contrat, le harnais veillant à son application, course après course.

Les progrès ont cessé d'être subjectifs presque immédiatement. Après chaque session de codage, le harnais exécutait les tests et produisait un simple tableau de résultats : X sur Y réussis, plus les traces de pile pour les échecs. Au fil d'environ 50 sessions sur 24 heures, ce nombre est passé de zéro à « un peu plus de la moitié » des tests réussis.

Les tests ont servi à la fois de navigation et de garde-fous. Lorsqu'une refonte a cassé un flux antérieur, les tests en échec ont ramené l'agent en arrière, le contraignant à concilier le nouveau code avec les anciennes promesses. Ce cycle de rétroaction a remplacé la révision de code humaine par quelque chose de plus froid et de plus fiable : des vérifications automatisées.

Cole s'est appuyé fortement sur des tests de bout en bout qui simulaient un utilisateur réel dans un navigateur sans interface graphique. En utilisant des outils comme Playwright ou Puppeteer, le cadre effectuerait les actions suivantes : - Démarrer le serveur de développement - Ouvrir une instance Chromium sans interface graphique - Naviguer à travers la connexion, le nouveau chat et la création d'un artefact - Vérifier le contenu du DOM, les appels réseau et l'état persisté

Ces tests du navigateur ont transformé des exigences abstraites en étapes concrètes : « cliquez sur ce bouton », « tapez cette invite », « attendez cette forme de réponse ». Lorsqu'ils échouaient, l'agent voyait des sélecteurs exacts, des messages d'erreur et des valeurs attendues par rapport aux valeurs réelles, puis corrigeait le code et relançait la suite.

À la fin, les tests passés décrivaient un clone partiel mais réel de claude.ai. Les tests échoués correspondaient précisément à des comportements manquants ou défaillants, sans vagues déceptions.

L'élan se manifeste presque immédiatement. Claude Code, connecté au système d'agents de longue date d'Anthropic, lance un nouveau projet, installe les dépendances et crée une application full-stack avant qu'un humain ne termine de dessiner l'architecture. Dans la première heure, il génère un frontend React, une API backend basique, et le câblage nécessaire pour exécuter des tests de bout en bout contre un serveur de développement local.

Le travail sur l'interface utilisateur avance rapidement et avec assurance. L'agent recrée une mise en page de style claude.ai : une barre latérale pour les conversations, un panneau de chat principal et un panneau d'artefacts capable d'afficher des blocs de code et du texte formaté. Il ébauche des composants pour les bulles de messages, les zones de saisie et les listes de conversations, puis les connecte à des données temporaires afin que l'interface semble vivante même avant que la logique réelle soit intégrée.

Parce que Cole Medin effectue en amont une série de contrôles TDD, les progrès sont mesurés sur un tableau de bord. Les premiers tests couvrent les fondamentaux : l'application démarre sans planter, la vue de chat s'affiche, les messages s'affichent dans l'ordre et le routage de base fonctionne. Claude aborde ces tests comme un ingénieur senior lors d'un sprint sur un terrain vierge, corrigeant souvent les tests échoués en une seule itération.

La plomberie de bas niveau suit. L'agent câble les routes API pour créer des conversations, publier des messages et récupérer l'historique, puis met à jour le front-end pour les appeler. Les types TypeScript, une gestion simple des erreurs et la configuration de l'environnement apparaissent sans être sollicités, un effet secondaire du harnais qui relance constamment les tests et fait surface les traces de pile.

Pendant cette période de "fruits à portée de main", le système ressemble de manière troublante à de la magie. Vous observez les commits s'accumuler : nouveaux composants, ajustements CSS, fonctions utilitaires, fichiers de test. Chaque test réussi débloque le niveau d'ambition suivant : flux multi-messages, états de chargement, rendu d'artefacts de base - sans qu'un humain touche le clavier.

Pendant quelques heures, le goulet d'étranglement n'est pas l'intelligence, mais l'entrée/sortie. L'agent attend sur `npm install`, les tests de navigateur et les redémarrages du serveur de développement plus qu'il n'attend des idées, parcourant les 30 à 40 % faciles de la suite de tests avant que le travail ne devienne réellement difficile.

L'élan ne s'éteint pas avec un effondrement ; il s'amenuise dans la répétition. Après environ une douzaine d'heures et des dizaines de sessions avec des agents, le clone de Cole Medin, claude.ai, cesse de progresser et commence à tourner en rond. De nouveaux commits continuent d'arriver, mais ils se contentent principalement de réorganiser la logique existante, de modifier les sélecteurs ou de renommer des composants sans débloquer de nouveaux tests concluants.

La complexité cesse d'être locale et devient systémique. L'agent doit désormais lutter avec des problèmes à plusieurs sauts : des flux de navigateur qui dépendent de l'état d'authentification, des fils de conversation qui doivent persister entre les rechargements, et un rendu d'artefacts qui touche les API backend, le routage front-end et l'état de l'interface utilisateur. Chaque changement corrige un cas particulier tout en brisant discrètement deux autres.

Les tests instables deviennent l'antagoniste principal. Les vérifications sur navigateur sans interface échouent parfois en raison de conditions de concurrence, de problèmes de temporisation ou de légères différences dans le DOM. Le cadre considère avec diligence chaque test échoué comme un vrai bug, ce qui fait que l’agent passe course après course à traquer des échecs non déterministes qu'un humain identifierait rapidement comme “le test est mauvais, pas l'application.”

Vous pouvez voir le plateau dans les chiffres. Après 24 heures, le harnais rapporte un peu plus de la moitié des tests de bout en bout réussis—impressionnant pour un système automatisé, mais un plafond strict plutôt qu'une courbe fluide. Les premières heures éliminent les gains évidents ; les heures suivantes se heurtent à des tests d'intégration qui saisissent la nuance du produit, pas seulement la correction syntaxique.

À mesure que les tâches deviennent plus floues, l'intuition architecturale commence à jouer un rôle important et l'agent n'en dispose pas. Il peut refactoriser des composants React, réorganiser des gestionnaires d'API et ajuster les types TypeScript, mais il lui manque un modèle mental solide de l'application dans le style de claude.ai. Lorsque les flux du navigateur ne correspondent pas aux hypothèses du backend, l'agent réagit localement plutôt que de repenser le flux.

Les ingénieurs seniors gèrent cette phase en prenant du recul et en modifiant la structure du système. Ils : - Réduisent les abstractions fuyantes - Introduisent des limites plus claires entre l'interface utilisateur, l'état et l'API - Réécrivent des tests fragiles qui codifient le mauvais contrat

L'agent ne fait rien de tout cela tout seul. Il considère chaque échec comme un défaut corrigeable, et non comme un signal que l'architecture ou la suite de tests doit être repensée. Cela en fait un mécanisme puissant—un développeur junior inflexible qui ne cesse jamais de coder—mais pas la personne que vous souhaitez décider comment votre application devrait réellement fonctionner.

Ce plateau, plus que la démonstration flashy de la première heure, montre où se situe la codification autonome à la pointe de la technologie : brillante dans l'exécution, encore naïve en matière de conception.

Au bout de 24 heures, l'expérience de Cole Medin s'est terminée avec un métrique très peu inspiré de la Silicon Valley : seulement "un peu plus de la moitié" des tests automatisés ont réussi. Pas de tour triomphale, pas de clone poli de claude.ai, juste un harnais signalant discrètement qu'environ 50 à 60 % de ses propres spécifications avaient été atteintes.

Vu autrement, un agent de codage IA en grande partie non supervisé a passé une journée entière à travailler sur une véritable application full-stack et a livré quelque chose qui fonctionne réellement, qui gère les routes et qui rend. Pour un système autonome, c'est une avancée incroyable par rapport à l'époque de l'« application CRUD jouet en une seule invite », mais cela reste largement en deçà des logiciels de qualité production.

Les tests réussis se sont concentrés sur ce que les modèles actuels excellent : la structure, les modèles standards et les flux prévisibles. Les vérifications de rendu de l'interface utilisateur, de mise en page des composants, de navigation de base et des points de terminaison API simples ont principalement été concluantes car elles s'alignent parfaitement sur des modèles que les grands modèles de langage connaissent déjà.

Les échecs s'accumulaient là où vivait un état désordonné et interconnecté. Des conversations complexes imbriquées, des règles de cycle de vie des artefacts, des flux en plusieurs étapes et la gestion des erreurs dans les cas extrêmes ont produit un cimetière de tests échoués, révélant à quel point le refactoring autonome devient fragile lorsque chaque changement peut casser trois autres sous-systèmes. L'agent fixait souvent un test échoué pour réanimer un test précédent.

Le harnais de Cole s'appuyait fortement sur des tests de bout en bout basés sur le navigateur, lançant un environnement sans tête et cliquant à travers l'interface fictive de claude.ai. Ces tests validaient un comportement réel—boutons, modales, appels réseau—plutôt que de simples signatures de fonction, ce qui rendait chaque test réussi plus significatif et chaque échec plus difficile à contourner par la force brute.

En termes de coûts, le système se comportait moins comme un tube d'entrée de jetons infini et plus comme un serveur CI limité par le CPU. Les tests réels, et non la longueur des invites, dominaient le temps d'exécution, vous permettant d'obtenir des dizaines de itérations complètes sans franchir le territoire absurde d'un million de jetons par heure.

Ce compromis met en évidence une contrainte importante pour les agents à long terme : la latence en temps réel crée une limitation naturelle sur la combustion de jetons, mais elle limite également le nombre de fois que le système peut explorer, échouer et se rétablir. On ne peut pas simplement « augmenter le nombre de jetons » et s'attendre à ce que les 40 % restants des tests — souvent les cas d'intégration les plus épineux — tombent comme des dominos.

Les agents de code n'ont pas besoin de bonne humeur, ils ont besoin de tests. Le marathon Claude Code de 24 heures de Cole Medin n'est resté sain que parce que chaque comportement important pour le clone claude.ai existait d'abord sous forme de contrôles automatisés. Le travail de l'agent n'était pas de "créer une application", mais de "faire en sorte que ces tests passent au vert", ce qui a transformé une consigne vague en un contrat concret.

Ce cadre de test agissait comme des rails pour un système autrement stochastic. Chaque boucle de codage se déroulait de la même manière : proposer des modifications, exécuter la suite de tests, examiner les échecs, répéter. Au cours de plus de 50 sessions, ce rythme a créé quelque chose de rare dans les expériences de codage en IA : un progrès répétable au lieu d’un tas de dépôts de code sans rapport.

TDD a également donné à l'agent une protection contre les régressions. Lorsque Claude a refactorisé l'interface frontale React ou réécrit les gestionnaires d'API, le cadre a immédiatement relancé les tests de bout en bout dans le navigateur qui parcouraient les conversations, les artefacts et les flux de la barre latérale. Si un « correctif » cassait l'historique des messages ou le rendu des artefacts, un test en échec a immédiatement ramené l'agent en arrière avant que le bug ne se propage.

Ce filet de sécurité encourageait des changements risqués de manière agressive que vous ne feriez jamais confiance dans un flux de travail « demande et expédition » pur. L'agent pouvait retirer des composants entiers, réorganiser les itinéraires ou renommer des structures de données car les tests préservaient le comportement. L'intention résidait dans les assertions ; l'implémentation devenait un détail interchangeable que le modèle pouvait continuer à mélanger.

Le TDD a également clairement séparé l'intention de l'implémentation, ce qui correspond presque parfaitement au fonctionnement des LLM. Les ingénieurs humains ont codé les attentes produit sous forme de tests Jest et Playwright : « Lorsque j'envoie un message, il apparaît dans le fil de discussion », « Les artefacts s'ouvrent dans un panneau avec des métadonnées. » Claude n'avait qu'à chercher dans la base de code des moyens de satisfaire ces déclarations.

Cette externalisation est importante car les modèles hallucinent des exigences lorsque les instructions restent générales. Ici, l'intention existait en dehors de la fenêtre de contexte du modèle, enregistrée sur disque en tant que code. Même après des milliers de tokens et des dizaines d'appels d'outils, la vérité fondamentale pour "fait" restait la même : réussir le test, pas plaire à l'utilisateur.

Comparez cela à la codification habituelle invite‑et‑prie que les gens essaient dans les interfaces de chat. Vous collez une spécification floue, obtenez un ensemble de TypeScript, l'examinez, puis découvrez trois instructions plus tard qu'un « petit ajustement » a silencieusement brisé l'authentification ou la gestion de l'état. Pas de vérifications de régression automatisées, pas d'objectif stable, juste des sensations et des clics manuels.

L'expérience de Medin met en évidence le compromis. Le TDD structuré associé à un cadre a produit une application de style claude.ai avec plus de la moitié des tests réussis après 24 heures. Les flux de travail basés uniquement sur des invites ne survivent que rarement 24 minutes sans sombrer dans un code incohérent et non reproductible.

L'effort humain dans l'expérience de 24 heures de Cole Medin ne s'est pas concentré sur l'écriture de composants React ou l'ajustement des classes Tailwind. Il a été consacré à définir le système dans lequel l'IA allait évoluer : la structure du dépôt, l'ensemble des fonctionnalités à la manière de claude.ai, et les règles de conduite que l'agent devait suivre. Une fois cette structure en place, Claude Code est devenu plus comme un entrepreneur très rapide et très littéral qu'un collègue.

Les mouvements les plus stratégiques de Medin ont eu lieu avant la première ligne de code écrite par l'IA. Il a choisi la pile technologique, connecté le harness de longue durée provenant du dépôt GitHub d'Anthropic, et a décidé que « terminé » signifiait réussir une série de tests automatisés. Cette fondation a dicté tout ce que l'agent pouvait et ne pouvait pas faire pendant ces 24 heures.

Le harnais lui-même a efficacement codé une nouvelle description de poste pour les humains. Un agent « initialisateur » définissait les spécifications, les tâches et les tests ; un agent « de codage » itérait sur la base de code, exécutait la suite et visait les cochets verts. Le rôle de Medin était de concevoir cette boucle, et non de gestionner chaque fonction ou règle CSS à la minute.

Les futurs développeurs qui prospéreront dans ce monde seront obsédés par le cadrage des problèmes, et non par la syntaxe. Ils définiront :

• 1L'espace problématique : ce que l'application doit faire, quels flux sont importants, quels cas limites comptent.
• 2Les contraintes : choix de technologies, budgets de performance, règles de sécurité, points d'intégration.
• 3Les critères de réussite : tests de bout en bout, seuils d'acceptation et comportements non négociables.

Ces décisions ont façonné pourquoi Claude pouvait faire passer "un peu plus de la moitié" des tests et aussi pourquoi cela s'est arrêté là. L'absence de tests ou des tests ambigus signifiaient que l'agent n'avait aucun incitatif à corriger certains bugs d'intégration. Des objectifs trop vagues le laissaient se débattre avec des flux d'interface utilisateur complexes au lieu de prioriser la fonctionnalité de base.

La valeur se déplace vers l'ingénierie de l'harnachement lui-même : les prompts, outils et signaux de retour qui maintiennent les agents orientés vers la bonne cible. Cela inclut la rédaction de suites de tests impitoyables, la conception de mécanismes d'observation autour des exécutions des agents, et la décision de réinitialiser le contexte ou de revoir les spécifications. Les humains deviennent architectes de l'IA, responsables du plan et du mètre ruban, tandis que le modèle s'occupe des cloisons sèches et du câblage.

Le codage agentique ne se limite plus seulement aux articles de recherche et aux démonstrations. Le défi de 24 heures de Cole Medin place la harnachement d'agent d'Anthropic directement dans la même conversation que GitHub Copilot, Codeium et Replit Ghostwriter—sauf que cet outil ne se contente pas de compléter automatiquement une fonction, il exécute un sprint logiciel entier par lui-même. Le système construit un clone de claude.ai, connecte les flux d'interface utilisateur et effectue des tests de bout en bout pendant toute une journée.

Ce saut de « complétion automatique intelligente » à « travailleur persistant » est la véritable histoire. Des outils comme GitHub Copilot fonctionnent au niveau des frappes : ils prédisent la prochaine ligne, peut-être le prochain bloc. La configuration de Medin opère au niveau des tâches : « mettre en œuvre des artefacts, organiser des conversations, satisfaire ces 40 tests », puis s'acharner à travers des dizaines de sessions d'agents jusqu'à ce que la réalité corresponde aux spécifications—du moins à moitié.

Les cadres d'agents semblaient autrefois être des jouets réservés à DeepMind, cachés derrière des architectures d'orchestration internes. Le claude-code-harness en open source d'Anthropic renverse cette dynamique. Un développeur seul peut désormais créer : - Un agent d'initialisation qui définit des spécifications et des tests - Un agent de codage qui modifie le code et exécute des navigateurs - Une boucle de retour d'expérience qui se prolonge sur plus de 50 sessions

Cette accessibilité change qui peut expérimenter avec des agents autonomes. Vous n'avez plus besoin d'une équipe d'infrastructure sur mesure pour faire fonctionner des outils à long terme qui appellent des CLI, lancent des navigateurs sans interface graphique et gèrent l'état du projet. Vous avez besoin d'un dépôt GitHub, d'une suite de tests et d'une carte de crédit.

D'un point de vue sectoriel, cela pointe vers une nouvelle couche dans l'empilement : des « pipelines de construction d'IA » qui se situent à côté de CI/CD. Les copilotes d'IDE aident les humains à taper plus rapidement ; les agents exploités exécutent des feuilles de route, refactorisent des bases de code pendant la nuit ou s'attaquent à des tests d'intégration instables. La course de 24 heures de Medin semble désordonnée et incomplète, mais elle préfigure un avenir proche où chaque organisation d'ingénierie sérieuse possède au moins un dépôt dont le principal contributeur est un bot.

La plupart des développeurs n'ont pas besoin d'un marathon d'IA de 24 heures exécuté dans un panneau tmux. Le véritable progrès provient de l'adoption des habitudes agentiques derrière le coup de Cole Medin : encodez vos objectifs sous forme de tests, donnez au modèle des outils et laissez-le travailler à travers une boucle de rétroaction pendant que vous supervisez au niveau du système.

Commencez par une seule fonctionnalité, pas un clone complet de claude.ai. Choisissez quelque chose comme "ajouter une connexion OAuth", "implémenter l'importation CSV" ou "créer une page de paramètres", et définissez 3 à 10 tests automatisés qui décrivent ce que signifie "terminé" plus précisément que n'importe quelle suggestion ne le fera jamais.

Encapsulez cette fonctionnalité dans une boucle tester‑et‑affiner serrée. Faites écrire l'implémentation par l'IA de votre choix, exécutez les tests, puis demandez-lui de corriger ce qui échoue. Résistez à l'envie de faire des corrections immédiates ; considérez-vous plutôt comme l'architecte qui ajuste les spécifications, clarifie les cas particuliers et réécrit de temps à autre une fonction compliquée.

Les propres dépôts d'Anthropic vous offrent un point de départ concret. L'agent à long terme utilisé par Cole se trouve sur github.com/anthropics/claude-agentic-coding, et les exemples plus larges de Claude Code montrent comment intégrer l'édition de fichiers, les exécuteurs de tests et l'automatisation du navigateur dans une seule boucle.

Vous n'avez pas à reproduire les plus de 50 sessions de codage de Cole ni à mettre en place une ferme de navigateurs sans tête dès le premier jour. Vous pouvez obtenir 80 % des avantages en laissant un agent appeler répétemment `pytest`, `npm test` ou des scripts Playwright et en intervenant uniquement lorsque les résultats stagnent manifestement ou commencent à se dégrader.

Une recette de démarrage pratique ressemble à ceci : - Écrivez une courte spécification et des tests pour une fonctionnalité - Donnez à l'IA votre dépôt, la spécification et la commande de test - Laissez-la itérer jusqu'à ce que les tests réussissent ou que les progrès stagnent - Affinez les tests, l'architecture ou les instructions, puis répétez

Utilisé de cette manière, le développement piloté par des agents ne vous remplace pas ; il élargit votre portée. Vous pouvez tenter des fonctionnalités que vous auriez mises de côté comme étant « trop importantes pour ce sprint », explorer des refontes plus ambitieuses et maintenir un niveau de qualité plus élevé car ce sont les tests, et non votre patience, qui l'imposent.

Qu'est-ce qu'un agent AI ?

Un agent d'IA est un cadre qui fournit à un modèle d'IA des outils, de la mémoire et une boucle structurée (planifier, coder, tester, affiner) pour effectuer de manière autonome des tâches complexes et de longue durée, comme coder une application entière.

L'IA a-t-elle réussi à créer l'application en 24 heures ?

L'IA a réalisé des progrès significatifs, en complétant plus de la moitié des tests requis pour un clone de claude.ai. Cependant, elle n'a pas entièrement terminé le projet, mettant en lumière les limitations actuelles des agents IA dans des tâches d'intégration complexes.

Est-ce une méthode pratique pour développer des logiciels aujourd'hui ?

Bien que toujours expérimental, l'approche axée sur les tests présentée est hautement pratique. Elle démontre que définir le succès avec des tests automatisés permet à l'IA de fonctionner de manière plus fiable et de produire de meilleurs résultats que de simples incitations conversationnelles.

Quel modèle d'IA a été utilisé dans l'expérience ?

L'expérience a utilisé le modèle Claude Code d'Anthropic, qui est spécifiquement optimisé pour les tâches de développement logiciel, dans leur environnement d'agent open-source de longue durée.