Harry Tan et Y Combinator critiqués pour un site créé avec AI et lourd de 6,4 Mo

Après que le PDG de Y Combinator, Gary Tan, se soit vanté de générer 37 000 lignes de code par jour, un audit indépendant de son site garryslist.org s'est transformé en un examen manuel des conséquences d'une telle approche. L'audit de la partie client a révélé non pas simplement une page lourde, mais une production où l'IA a accéléré la sortie de code plus vite que les révisions de code, l'optimisation et l'hygiène basique du frontend n'ont pu suivre.

Ce que l'audit a trouvé

La page d'accueil de garryslist.org s'est avérée être étonnamment lourde pour un blog d'actualités ordinaire avec infolettre. En un seul chargement, le navigateur effectue 169 requêtes et télécharge 6,42 MB de données. Pour un site de ce type, cela ressemble moins à une redondance intégrée qu'à une conséquence d'accumulation incontrôlée de code et d'actifs. L'auteur de l'audit souligne qu'il a analysé uniquement ce qui va réellement au navigateur, sans plonger dans le code source interne.

«

Semaine absolument folle pour le développement avec des agents. 37 000 lignes de code... »

C'est précisément sur ce fond de vantardise publique que l'audit sonne particulièrement dur. La vitesse de lancement en elle-même ne dit rien sur la qualité du résultat, et dans ce cas montre plutôt l'inverse : plus il y a de code et d'automatisation qui vont en production sans filtrage strict, plus il y a de chances que l'utilisateur reçoive quelque chose d'inutile, de cassé ou simplement d'indésirable. L'analyse du site est devenue non pas une dispute sur le style, mais un test de ce à quoi ressemble le « vibe coding » en environnement de combat.

Où le site s'est gonflé

La découverte la plus notable est 28 fichiers de test qui sont livrés au visiteur comme faisant partie du chargement normal de la page. Ce ne sont pas des rapports de test, mais de véritables enveloppes de test comme membership_form_controller.test et d'autres fichiers, totalisant environ 300 KB. Tous renvoient HTTP 200 et sont réellement téléchargés par le navigateur. Pour les utilisateurs, c'est du trafic sans sens ; pour l'équipe, c'est un signe qu'il n'y a pas de filtre approprié pour les artefacts dev dans le pipeline de publication.

En outre, la page charge 78 contrôleurs Stimulus totalisant environ 154 KB, y compris les modules de génération d'images, d'extraction vocale, de génération vidéo et même un modèle hello world. Ces fonctionnalités ne sont pas utilisées sur la page d'accueil, mais le code est quand même transmis à chaque visiteur.

Il y a une histoire séparée avec le logo : le même ours est livré huit fois dans différents formats, et un fichier AVIF a même une taille nulle.

• 169 requêtes et 6,42 MB sur une page d'accueil
• 28 fichiers de test en production, environ 300 KB de code inutile
• 78 contrôleurs Stimulus inutiles qui sont quand même téléchargés
• 4 MB de PNG brut où le navigateur demande WebP ou AVIF
• Le même logo se charge huit fois, y compris un AVIF vide

Le trafic le plus consommé provient des images des articles : le serveur les envoie comme PNG bruts non compressés via CloudFront, même si le navigateur demande explicitement des formats modernes. L'audit fournit des exemples de deux images pesant 2,07 et 1,99 MB. En WebP, elles pourraient occuper beaucoup moins d'espace. Sur ces deux seuls fichiers, le site gaspille environ 4 MB de trafic, et cela montre le mieux le coût de l'absence d'optimisation élémentaire.

Pas seulement des mégabytes

L'analyse ne se résume pas seulement aux performances, mais à la culture d'ingénierie. La page avait une duplication DOM pour les versions mobiles et desktop, des fichiers CSS vides, des balises title répétées et des dizaines d'images sans texte alt. En d'autres termes, le problème n'est pas une seule erreur aléatoire, mais une accumulation de petits défauts que personne n'a systématiquement nettoyés avant la sortie. Quand il y a de nombreux détails de ce genre, ils cessent de ressembler à du bruit et deviennent une conséquence d'un faible contrôle qualité.

L'auteur de l'audit critique particulièrement l'analytique PostHog que le site relaie via le chemin /s/ pour contourner les bloqueurs de publicités. Le code contient un commentaire direct sur le fait que le SDK se charge via un proxy précisément à cet effet. Sur le fond de fichiers de test en production et d'actifs cassés vides, une telle tentative de contourner les paramètres de confidentialité semble particulièrement négligente : une ressource qui se positionne comme socialement utile charge simultanément des ordures et essaie de suivre son audience plus étroitement.

Pour comparaison, l'audit cite Hacker News, qui est maintenu par l'écosystème Y Combinator lui-même : 7 requêtes et 12 KB sur la page d'accueil. Contre ce fond, garryslist.org s'avère être 562 fois plus lourd. Même sans compter les images, environ 73 % du volume transmis est considéré par l'auteur comme des ordures pures. C'est ce qui rend le cas important : il ne s'agit pas de goût, mais de pertes concrètes de réseau, de produit et d'exploitation aujourd'hui.

Ce que cela signifie

L'histoire du site de Gary Tan est un bon exemple de la façon dont l'IA accélère réellement le développement, mais ne remplace pas l'architecture, la révision de code et la responsabilité en matière de production. Si une équipe commence à mesurer les progrès par le nombre de lignes de code et la fréquence des push, elle finit facilement non pas avec un produit plus rapide, mais avec un site plus cher, plus lourd et plus fragile.