Développeur partage son flux de travail hybride en codage IA : Claude pour la planification, modèles locaux pour l'exécution

Un flux de travail hybride d'IA pour le codage réduit les coûts cloud
Un développeur sur r/LocalLLaMA a partagé un flux de travail détaillé qui combine des modèles d'IA cloud et locaux pour réduire les coûts en tokens tout en maintenant la qualité du code. Cette approche répond à la prise de conscience que de nombreuses tâches de codage ne nécessitent pas de modèles cloud coûteux.
L'architecture du flux de travail
Le système suit une logique « Raisonner dans le cloud, Exécuter localement » :
- Planificateur (Claude 3.5 Sonnet) : Reçoit la tâche et génère un fichier
task_context.mdprécis contenant les instructions, les chemins de fichiers et la logique. Cela coûte environ 300 à 500 tokens. - Codeur (Qwen2.5-Coder 30B local via Ollama) : Prend la spécification et le contenu réel des fichiers pour écrire le code. Cela s'exécute localement sans aucun coût.
- Validateur : Un simple script Bash exécute
tsc --noEmitoumypypour la vérification des types. - Réviseur (Qwen2.5-Coder 7B local) : Fonctionne en parallèle pour vérifier les défauts de logique évidents.
- Correction automatique : Si la compilation échoue, le journal d'erreurs est renvoyé au codeur local pour 2 à 3 itérations.
Détails de mise en œuvre
L'ensemble du pipeline est intégré dans un ensemble de scripts Bash utilisant uniquement jq et curl pour communiquer avec l'API Ollama. Le système détecte automatiquement les standards de langage (TypeScript, Python, C++, etc.) en fonction de la sortie du planificateur et ne nécessite pas d'environnements d'exécution Python/Node lourds.
Le développeur note que les modèles locaux (même ceux de 30B) échouent souvent dans le raisonnement architectural complexe, mais sont étonnamment bons pour l'exécution lorsqu'ils reçoivent des spécifications extrêmement claires.
Résultats et économies
Sur un projet TypeScript récent impliquant la modification de 12 fichiers :
- L'utilisation de Claude a été limitée à la phase de planification initiale uniquement
- Les modèles locaux ont géré tout le reste : écriture des 12 fichiers, linting et révision
- Économies totales : réduction d'environ 85 % des tokens par rapport à tout faire dans l'interface CLI de Claude Code
Le développeur a rendu les scripts disponibles dans un dépôt nommé ai-orchestrator sur GitHub (nom d'utilisateur : Mybono) pour ceux qui s'intéressent aux détails de mise en œuvre.
📖 Read the full source: r/LocalLLaMA
👀 See Also

Superposition en temps réel sur le bureau pour surveiller les limites d'utilisation du code Claude
La superposition de bureau open source affiche les limites d'utilisation de Claude Code en temps réel, éliminant le besoin de taper '/usage' à plusieurs reprises.

Système de mémoire persistante open-source pour Claude Code résolvant la perte de contexte entre les sessions
Un développeur a créé un système de mémoire basé sur des fichiers pour Claude Code qui capture automatiquement le contexte du projet sans plugins ni clés API. Il utilise des transcriptions de conversation, un fichier de réception et des tâches cron nocturnes pour maintenir une mémoire persistante entre les sessions.

Agent MCP Studio: Construisez des systèmes multi-agents MCP entièrement dans un navigateur via WASM
Agent MCP Studio vous permet de concevoir, orchestrer et exporter des systèmes d'agents MCP à partir d'un seul fichier HTML statique utilisant WebAssembly – sans backend, sans Docker, sans serveur.

Hubcap Bridge : Messagerie Bidirectionnelle Persistante entre CLI et JavaScript Navigateur via CDP
Hubcap Bridge est une nouvelle fonctionnalité de l'outil CLI Hubcap qui crée un canal de communication bidirectionnel persistant entre les processus locaux et le JavaScript exécuté dans les pages du navigateur via le Chrome DevTools Protocol. Il permet aux compétences Claude Code d'interagir avec les applications web via leurs API JavaScript internes sans nécessiter d'accès à une API publique.