Projet de Code Claude de 34 Jours du Développeur Senior : Une Ingénierie Solide, des Angles Morts Critiques

Aperçu du projet

Un cadre technique senior avec plus de 35 ans d'expérience (rôles de VP Engineering, CIO, Head of Software Engineering) a utilisé Claude Code pour un projet solo sur 34 jours. Le développeur a joué le rôle de propriétaire produit, architecte et chef d'équipe tandis que Claude écrivait tout le code.

Résultats techniques

Le projet a généré plus de 300 commits en 34 jours. Claude et ChatGPT ont indépendamment examiné la base de code et ont constaté :

• Une architecture propre avec une solide séparation des préoccupations
• Une bonne couverture de tests (272 tests)
• Une documentation approfondie décrite comme « exceptionnelle compte tenu du stade du projet »
• Une architecture qui était « non pas aspirationale ; elle est implémentée »

Approche de gestion de projet

Le développeur a créé un fichier CLAUDE-md avec des règles de travail pour gérer l'assistant IA, incluant :

• Ne jamais décrire du code sans l'avoir lu d'abord
• Ne jamais avancer sans permission
• Diagnostiquer avant de réparer

Ce document de gestion a été qualifié de « l'un des meilleurs documents de gestion d'assistant de codage IA que j'aie vus » par les examinateurs. Gérer Claude Code donnait l'impression de « gérer un développeur junior très rapide et très littéral ».

Le projet : Pipeline de conversion de documents

Le projet était un pipeline complexe de conversion de documents avec cinq étapes :

1. Extraire le contenu des pages web
2. Assainir le contenu
3. Analyser en un modèle structuré
4. Rendre sous forme de HTML accessible

Le concept original était une CLI et une bibliothèque pour que les développeurs puissent les intégrer dans leurs applications.

Opportunité critique manquée

Le développeur connaissait le moteur d'extraction du mode lecteur de Firefox (Readability.js) mais n'a jamais demandé : « est-ce aussi une bibliothèque autonome que je pourrais utiliser ? » Au lieu de cela, il ne l'a vu que comme une fonctionnalité du navigateur. Cette seule question aurait révélé que :

• La partie difficile était déjà résolue
• La vraie valeur (typographie, thèmes, sortie accessible) pourrait être une extension de navigateur basée sur un moteur existant

Ni le développeur ni Claude n'ont fait émerger cette approche alternative, malgré la propre règle d'ingénierie du développeur : « ne jamais construire quelque chose si une solution existe déjà ».

Pivot de l'interface utilisateur

Les utilisateurs cibles (parents, enseignants, étudiants) ne pouvaient pas utiliser une CLI ou un pipeline. Le développeur a d'abord essayé une simple page HTML de test pour obtenir des retours, mais a ensuite construit une interface web complète :

• Plus de 100 commits en huit jours
• Cinq thèmes
• Design réactif
• Image de marque et déploiement

Cette interface est devenue le produit au lieu d'être simplement un mécanisme de retour.

Expansion de l'infrastructure de test

Le projet a développé une infrastructure de test étendue :

• Harnais d'évaluation avec 16 métriques de qualité
• Benchmarks contre plus de 4 000 pages web
• Pipeline de comparaison
• Outil de filtrage

L'effet cumulatif était de « cinq lignes d'infrastructure de test pour chaque ligne de produit ».

Expérience du développeur

Le développeur a rapporté : « Travailler avec Claude Code donnait l'impression de gérer une équipe à nouveau. Brainstormer pour débloquer des problèmes, prendre des décisions architecturales, voir les choses se concrétiser à grande vitesse. C'était comme avoir la Justice League qui écrivait mon code. »

Cependant, cela a créé un piège : « Chaque fois que j'avais un doute persistant sur le fait que j'étais sur la bonne voie, je pouvais le mettre de côté en construisant autre chose d'impressionnant. La qualité du travail est devenue sa propre justification pour continuer. »

Les retours utilisateurs n'ont été collectés qu'au jour 30 sur 34.