- il ne permet pas de définir à partir de quelle branche un workflow donné va partir (pénible aussi ça)
- il ne permet pas d'afficher la taille de contexte pour un workflow donné
- il ne permet pas de créer plusieurs discussions autours d'un sujet/tache donnée
Posts by Frédéric Camblor
You don't need a cloud subscription to use frontier-class LLMs for coding. A couple of Apple Silicon Macs, a Thunderbolt cable, and Exo give you a private AI cluster that rivals cloud APIs, at the cost of electricity ⚡️🤩
linkedin.com/pulse/local-...
- il ne permet pas d'interrompre la discussion à n'importe quel moment (c'est pénible ça)
- il n'inclut pas de diff viewer sur ce qui a été modifié pdt un workflow
- il ne semble pas exister de système de notification quand une tache est terminée
haha weird but ... fair point :)
Take care 🫂
brew install --cask aqua-voice
Ce qu'Archon ne fait pas (par rapport à d'autres outils):
- il ne permet pas de partager des tâches entre plusieurs teammates (le fonctionnement reste local - c'est une des contraintes qui est requise par Anthropic pour pouvoir utiliser Claude Code)
- il ne facilite pas le lancement de "web preview"
- les workflows st complètement customisables (archon arrive avec un ensemble de workflows d'exemple.. ms rien ne vous empêche de construire le votre sur vos habitudes avec vos commandes et votre contexte)
- les workflows peuvent être persistés project-level dans git (dc partagés avec vos teammates)
Schéma illustrant le fait que 2 steps/noeuds d'un workflow peuvent utiliser une nouvelle session claude, tout en faisant transiter certains fichiers persistés sur le filesystem
Schéma illustrant le parallelisme offert par Archon Il est évidemment plus rapide de paralléliser des tâches que de tout dérouler en séquentiel.
- les workflows disposent d'un espace de travail qui leur est dédié et dans lequel il peuvent construire un contexte persistant (ex: plan.md) pour le faire transiter de noeud en noeud tout en resettant le contexte
- la gestion du parallélisme est géré automatiquement via le DAG
Schéma illustrant le parallélisme d'Archon et le fait que de multiples workflows peuvent s'exécuter en parallèle Dans l'exemple: - un workflow qui fix un bug - un autre qui build une nouvelle feature - un autre qui review une PR - un autre qui procède à un gros refactoring
Ses features:
- chaque workflow s'exécute dans sa sandbox et son worktree
- à chaque étape, on peut pré-définir le modèle utilisé (en fonction de l'ampleur de la tâche à réaliser)
- à chaque étape, on peut décider de repartir d'un "fresh" context (ou conserver celui de l'étape précédente)
Vendredi, j'ai commencé par regarder le full guide (www.youtube.com/watch?v=qMnC...) de 30' par son créateur, puis hier j'ai suivi un (long) livestream (www.youtube.com/watch?v=srx9...)
Je pense avoir trouvé l'outil que j'aurai aimé développer moi-même (how cool is that ?!)
Les problèmes qu'Archon cherche à adresser dans un workflow AI standard : - inconsistency: same prompt, 3 different answers, zero trust - context bloat: long session drift, forget instructions, hallucinations - no parallelism: one agent, one repo, one task at a time - can't delegate: scared to walk away - you don't know what it will do - nothing composes: skills, commands, rules - live side by side, never snap into one flow
Ça n'est pas une méthodo opinionated comme BMAD, Speckit etc.
Archon sert à dérouler des workflows et injecter du déterminisme ds votre manière de travailler avec votre AI Assitant favori (Claude Code pour ma part)
Si vous avez bâti un context eng. sur votre projet, il n'est pas remis en question.
Ce qu'Archon adresse: le fait de pouvoir définir un workflow dans lequel se trouvent des steps déterministes (human in the loop, bash commands, etc.) et des steps non déterministes (AI driven) On y voit un workflow linéaire: Trigger (determinist) -> Plan (non determinist, AI prompt) -> Code (non determinist, AI prompt) -> Test (determinist, bash command) -> Loop in case of failure (determinist, outcome evaluation) -> Approve (determinist, human in the loop) -> Open PR (determinist, bash command)
Tableau affichant les secrets d'un workflow hybride déterministe / non déterministe (AI based) Types de noeuds déterministes : bash, test (validate), condition Types de noeuds AI (non déterministes): prompt, AI command, AI subagent ...
Un exemple visuel de workflow en cours d'exécution pour une tâche donnée. On voit que le process passe par différents steps (nodes) qui ont un objectif et permettent de cadrer le déroulé de comment la tâche est traitée.
Cette après midi, mise en place et test de Archon (archon.diy) sur un projet.
Archon, c'est un "AI harness builder".
Une sorte de N8N mais pour l'AI Software Dev: tu crées des workflow (DAG) avec des noeuds déterministes (commandes shell) ou non déterministes (prompt AI)
Big news for those working in restricted or air-gapped environments:
- GitHub Copilot CLI now supports local models and BYOK.
I’m often asked if Copilot can work offline or in secure zones—now it finally can.
Check out the update:
github.blog/changelog/20...
#GitHubCopilot
J'ai pas un recul de fou dessus, mais après quelques heures d'utilisation je trouve ça vraiment magique !
Il me faudra qq jours d'historique pour voir si la recherche fonctionne bien, mais j'ai l'impression que le pb le plus compliqué est cracké (extraction et synthèse de la data)
Découverte du jour : pieces.app
Sans intervention manuelle, il mémorise tout ce qui se passe sur mon écran (slacks, mails, navigateur, IDE, terminal, etc..) et le synthétise au fur et à mesure dans des notes en markdown
C'est gratuit, et ça reste en local.
Petite découverte du jour, une alternative à meetup européenne et gratuite, pour les organisateurs de confs tech par exemple : the-playground.fr
Mais sinon il avait bien aimé l'expérience
Un collègue l'a fait avec 3 couples/enfants (ils devaient être une bonne dizaine)
De ce que j'avais compris (à vérifier) il fallait faire attention car certains trajets n'étaient pas garantis (qd le train est plein, pas possible de le surbooker) du coup ils avaient parfois du rallonger pour assurer
Sous le capot: je prends une "photo" du workspace entre le dernier run valide (stocké dans un fichier local dans le .claude/) et l'état actuel du workspace.
En fonction, j'exécute les commandes dès qu'un fichier a bougé sur un des glob pattern fournis.
(plus de détails dans le README)
Les commandes s'exécutent :
- en parallèle (1 subagent par commande)
- une seule fois, juste avant de rendre la main (hook "Stop")
- uniquement si des modifs sur les globs visés ont été réalisés depuis le dernier run passant de l'outil
=> si au moins une erreur, Claude revoit sa copie
J'ai créé un petit utilitaire passe-partout qui peut grandement vous simplifier la vie : gitdiff-watcher (github.com/fcamblor/git...)
L'idée: utiliser un hook qui s'exécute juste avant que CC vous rende la main, et qui lance des commandes si le LLM a modifié certains fichiers.
...
- ds un long context, le LLM accorde davantage d'importance au début et à la fin du ctx (dommage si vos infos importantes sont dans le ventre mou)
- des instructions de la discussion peuvent venir contredire vos infos importantes - ex: qd vous itérez avec le LLM et que vous corrigez des éléments
(1) On touche à la notion de "context rot" ici :
- les LLMs sont stateless : c'est à chaque fois toute la discussion qui est envoyée (dilution des infos importantes avec le temps)
- la fenêtre de contexte est limitée, et les /compact font perdre de l'info
...
Claude Code vous rend la main alors que ça ne compile pas ou que des tests sont en erreur... vous aviez pourtant mis cette contrainte dans le CLAUDE.md ! 😤
Le non déterminisme des LLMs fait qu'une instruction dans votre contexte n'est pas une garantie (1)
Pour du déterminisme: utilisez les hooks !
⚡️ Vite 8.0 is here!
The most significant architectural change since Vite 2.
⏬ Powered by @rolldown.rs bringing faster production builds and more consistency
🛤️ New features such as tsconfig paths and emitDecoratorMetadata support
vite.dev/blog/announc...
Code example showing the usage of Temporal.ZoneddateTime ```js // London DST starts: 2026-03-29 01:00 -> 02:00 const zdt = Temporal.ZonedDateTime.from( "2026-03-29T00:30:00+00:00[Europe/London]", ); console.log(zdt.toString()); // → "2026-03-29T00:30:00+00:00[Europe/London]" const plus1h = zdt.add({ hours: 1 }); console.log(plus1h.toString()); // "2026-03-29T02:30:00+01:00[Europe/London]" (01:30 doesn't exist) ```
Temporal is now Stage 4 at TC39 🎂🎂🎂
Thanks to all the other champions of JavaScript's new date-time API. It has been a wild ride over many years!
I wrote a blog post explaining how we got here 📜
bloomberg.github.io/js-blog/post...
Edit level is too granular to me : a refactoring has to edit multiple files and that's pointless to run linter/compiler at each step
I prefer to trigger them either :
- when AI decides to commit (pre-commit hook)
- or (better) at the moment AI Assistant hands over control ("Stop" cc hook)
simply, more OSS projects should DO THIS.
OSS is a long playing game, if not forever. but we are people behind those projects, and we need good rest and balance to keep things sustainable. I am super happy to see this move and looking forward to see how it could change how OSS works for all of us.
I realized this only today
For weeks now, I used vibe-kanban which :
- asks for a "variant" (model + prompt) whenever I start a new workspace/attempt/worktree
- allow to change this variant on every new message on the workspace's discussion
It made me realize cc design is flawed on this matter
TIL Claude Code's /model command is global, and not scoped to your cc session
That's broken
When I switch to opus temporarily for a long running task in cc session #2, I don't want my other claude code session #1 used for very targetted tasks (based on Haiku) to be impacted