Neuberg : Terminal de Trading Multi-Marché Open-Source Construit avec Claude AI

Ce qu'est Neuberg

Neuberg est un terminal de trading open-source basé sur navigateur conçu pour consolider plusieurs interfaces de trading en une seule application. Il se connecte à des marchés réels incluant Hyperliquid, Polymarket et Alpaca, normalise les ordres en interne, et superpose des actualités ainsi que des signaux structurés.

Domaines où Claude a excellé

1. Conception d'une abstraction d'ordre multi-plateforme

Claude a aidé à concevoir un format interne normalisé pour gérer différentes plateformes avec des modèles d'authentification, des règles de précision, des sémantiques d'ordre et des limites de taux variables. L'architecture a évolué vers : Intention d'ordre → Adaptateur de plateforme → Appel API.

Claude a excellé pour :

• Identifier les cas limites comme les exécutions partielles, la troncature de précision et l'idempotence
• Suggérer des modèles d'isolation des adaptateurs
• Repérer où le couplage deviendrait problématique
• Proposer des conceptions cohérentes des surfaces d'erreur

Il a donné ses meilleurs résultats lorsque les vraies documentations API étaient collées, que les contraintes réelles étaient clairement décrites, et qu'on lui demandait de critiquer une conception proposée plutôt que d'en inventer une à partir de zéro.

2. Refactoring sans briser les modèles mentaux

Au fur et à mesure que le projet grandissait, Claude a aidé à :

• Unifier les modèles de marché entre les perpétuels, les actions et les marchés de prédiction
• Découpler l'état de l'interface utilisateur de la couche de transport
• Réduire les re-rendus pendant les mises à jour WebSocket haute fréquence

Les contributions spécifiques incluaient expliquer pourquoi certains modèles React déclencheraient des rendus en cascade, suggérer des limites de mémorisation, et aider à restructurer l'état pour que les différences de carnet d'ordres à haut volume ne figent pas l'interface utilisateur.

3. Conception de la couche d'actualités et de signaux structurés

Neuberg récupère les déclarations Form 4 EDGAR, les données de calendrier macro, les données des plateformes et les actualités financières générales. Claude a aidé à concevoir :

• Un pipeline simple d'étiquetage de sentiment
• L'extraction d'entités pour les tickers, secteurs et géopolitique
• Des heuristiques d'« étiquetage d'impact »

Lorsqu'on lui demandait « Étant donné ce schéma JSON structuré, quel système de notation minimal éviterait le surajustement tout en restant explicable ? », Claude penchait systématiquement vers des systèmes plus simples et interprétables plutôt que vers la sur-ingénierie.

Domaines où Claude a eu des difficultés ou nécessité des adaptations

1. Contexte long et itération rapide

Pour les modifications multi-fichiers importantes, la gestion de la fenêtre de contexte est devenue problématique. Claude réintroduisait occasionnellement des modèles qui avaient déjà été écartés. Ce qui a aidé était de maintenir un court document « vérité terrain » architectural, de ne coller que les modules pertinents, et de réexpliciter clairement les contraintes.

2. Nuances des systèmes en temps réel

Pour la logique de différences WebSocket et les mises à jour haute fréquence du carnet d'ordres, Claude adoptait parfois par défaut des abstractions propres mais peu pratiques, et sous-pondérait les implications sur les performances. Il avait besoin de contraintes explicites comme « supposez 50 mises à jour/sec », « supposez 5000 niveaux » et « optimisez pour une pression GC minimale » pour s'adapter efficacement.

3. Limites de sécurité

Pour un logiciel de trading impliquant de l'argent réel et des clés API, les suggestions de Claude concernant la sécurité n'étaient jamais acceptées aveuglément, en particulier concernant la gestion des clés, les hypothèses de confiance client/serveur et le stockage de l'authentification. Bien qu'utile pour énumérer les surfaces de menace, les décisions sensibles en matière de sécurité nécessitaient toujours une validation par rapport aux meilleures pratiques.

Insight clé sur l'utilisation de Claude pour l'infrastructure

Claude était plus fort lorsqu'il était utilisé pour la critique architecturale, l'énumération des cas limites, la clarté du refactoring et l'explication des compromis. Il était plus faible lorsqu'il devait deviner des contraintes non énoncées, était censé se souvenir de l'intégralité du système, ou était chargé d'inventer des conceptions à partir de zéro sans paramètres clairs.