Negli ultimi mesi i coding agent sono passati dalla sperimentazione all’uso quotidiano in molti team di sviluppo. Strumenti come Claude Code, Codex, Cursor e Copilot CLI si sono dimostrati affidabili su un numero crescente di attività: refactoring, scrittura di test, correzione di bug. Superata la fase iniziale di adozione ed entusiasmo, emerge però un problema diverso. Quando gli agenti diventano più di uno e lavorano in parallelo sullo stesso repository, la difficoltà non è più ottenere codice dall’AI, ma governare la produzione: isolare i task, mantenere pulito il branch principale e sapere in ogni momento quale agente sta intervenendo su quale parte della codebase.
Questo articolo è il risultato di una serie di test condotti da alcuni membri del team Frontend di Bitrock, che hanno introdotto Orca nel proprio flusso di lavoro quotidiano per valutarne punti di forza, limiti e margini di estensione. Di seguito riassumiamo quanto emerso: come funziona lo strumento, in cosa si distingue dalle principali alternative e come il team lo ha adattato alle proprie esigenze sviluppando un fork interno.
L’isolamento dei task con i Git Worktree
La differenza sostanziale tra un classico plugin per IDE e uno strumento come Orca sta nell’architettura sottostante.
Se si chiede a due agenti diversi di lavorare sullo stesso repository nella stessa cartella, si accavalleranno perdendo entrambi di efficienza. Orca risolve la questione alla radice sfruttando i Git Worktree: ogni volta che si assegna un task o si invia un prompt, il sistema crea un albero di directory isolato in background.
# Typical workflow with the Orca CLI
orca worktree create --branch fix/session-leak --agent claude-code
orca worktree create --branch fix/session-leak-codex --agent codex
# Run the same prompt in parallel on two different models
orca fanout "Find and fix the memory leak in the auth middleware"
L’impatto sul lavoro di tutti i giorni è immediato:
- Zero conflitti locali: è possibile far lavorare tre agenti in parallelo senza rischiare che sovrascrivano i file su cui si sta lavorando vengano sovrascritti.
- Confronto side-by-side: lo stesso compito può essere inviato a modelli differenti (es. Claude vs Codex), i diff possono essere confrontati e l’utente può valutare l’approccio migliore ed eseguire solamente il merge della soluzione valida.
- Integrazione con i task di team: è prevista la capacità di aprire una Issue da GitHub o Linear e creare il worktree dedicato con un click.
Anche ClaudeCode utilizza i git worktree, ma l’uso è limitato all’interno con lo scopo di isolare l’esecuzione dei comandi nella sua singola sessione di terminale. Orca, un Agent Development Environment (ADE) open source, pensato per coordinare più coding agent direttamente all’interno del flusso di lavoro dello sviluppatore, agisce invece come un orchestratore a livello superiore: crea e gestisce visivamente i worktree in automatico per far girare più agenti in parallelo su rami diversi. In questo modo, Orca permette di confrontare affiancati i diff prodotti da ciascun modello prima di fare il merge sul branch principale.le to compare the diffs produced by each model side by side before merging into the main branch.
Monitoraggio da remoto: l’app mobile companion
L’app mobile companion (disponibile per iOS e Android) estende l’esperienza fuori dal terminale: si sincronizza in tempo reale con le sessioni locali o su server remoti (via SSH), inviando notifiche push quando un agente termina un task o richiede una conferma (Human-in-the-loop), permettendo di monitorare l’avanzamento dei lavori e inviare feedback anche da remoto.
Orca e le alternative sul mercato
Orca si inserisce in un mercato che sta esplodendo proprio in questi mesi, ma con un approccio ben preciso. Se stiamo valutando come strutturare la nostra Developer Experience, le opzioni principali si dividono in due categorie:
1. T3 Code vs Orca
T3 Code è un altro orchestratore visivo molto valido. La differenza principale sta nell’impostazione: T3 Code si focalizza sulla centralizzazione delle sessioni di chat e dei thread multi-provider in un’unica interfaccia; Orca (e di conseguenza Forca) spinge invece molto di più sull’isolamento sistemistico tramite Git Worktree, il controllo via mobile e il supporto ad agenti eseguiti su macchine remote via SSH.
2. OpenHands
OpenHands adotta un approccio end-to-end: fornisce l’agente, la pianificazione, la sandbox e l’ambiente di esecuzione. Orca segue la logica opposta e si posiziona come livello di coordinamento esterno. Non sostituisce le CLI né gli abbonamenti già in uso (Claude Code, Codex e altri), ma aggiunge sopra di essi uno strato di gestione e orchestrazione.
3. Orchestratori di Workflow (Temporal, LangGraph)
Qui parliamo di cose diverse: strumenti come Temporal o LangGraph servono a scrivere ed eseguire workflow di AI dentro le applicazioni in produzione. Orca serve invece a noi sviluppatori per scrivere codice più velocemente durante la fase di dev.
Riepilogando:
Orca
- Punto di forza: Gestione flotte via Git Worktrees, UI semplice e intuitiva, app mobile
- Modello di utilizzo: BYOA (Porti i tuoi agenti CLI)
- Punto debole: Curva di apprendimento su Git avanzato
T3 Code
- Punto di forza: Interfaccia unica per thread e prompt
- Modello di utilizzo: Freemium / BYO-Key
- Punto debole: Meno focalizzato su Worktrees remoti
OpenHands
- Punto di forza: Sistema autonomo end-to-end
- Modello di utilizzo: Open source con sandbox
- Punto debole: Più pesante da far girare in locale
Forca: una fork di Orca
Trattandosi di un progetto rilasciato con licenza MIT, il vero vantaggio di Orca è che non si è vincolati alle scelte di design del team originale. Se manca qualcosa che serve al proprio workflow, lo si sviluppa.
È esattamente quello che hanno fatto Davide Ghiotto, Senior Front-end Engineer, con l’aiuto di Elhosain Halili, Front-end Engineer. Usando Orca quotidianamente per la programmazione automatica, sentivano la mancanza di una gestione snella e visiva dei branch e degli stash in stile VS Code.
Anziché adattarsi o aprire una feature request e attendere, è possibile lavorare avvalendosi dell’AI sul codice sorgente e creare un proprio fork personalizzato: “Forca“.
In poco tempo ha aggiunto:
- Un branch switcher nativo nel Source Control, completo di comandi rapidi e indicatori di sync (pull/push counters).
- Gestione degli Stash avanzata, con sottomenu dedicati per apply, pop e drop, oltre alla funzione di “Stash & Switch” automatico quando il cambio di ramo è bloccato.
- Build macOS firmate, così da permettere a chiunque nel team di installare e usare subito la versione modificata.
Questo è un ottimo esempio di come l’AI stia cambiando il modo di approcciare l’open source: non ci si limita più a usare i tool così come vengono forniti, ma li si modella sulle reali esigenze del team con uno sforzo minimo.
Conclusioni
Orca does not make agents smarter: if a model produces wrong solutions or hallucinations, it will keep doing so. Its value lies elsewhere, namely in reducing the cognitive load of context-switching and in making it possible to treat coding agents for what they are today: a group of assistants to whom well-defined tasks can be delegated, to be checked and reviewed with the right tools before changes reach the main codebase.
Our Front-end team’s experience suggests that maturity in adopting coding agents is not measured by the number of agents in use, but by the quality of the process that governs them. Task isolation, structured comparison between alternative solutions and a human checkpoint before merging are practices that go beyond any single tool, and that every team should consider when integrating AI into its development cycle.
Conclusioni
Orca non rende gli agenti più intelligenti: se un modello produce soluzioni errate o allucinazioni, continuerà a farlo. Il suo valore sta altrove, cioè nella riduzione del carico cognitivo legato al context-switching e nella possibilità di trattare i coding agent per ciò che sono oggi: un gruppo di assistenti a cui delegare attività ben delimitate, da verificare e revisionare con strumenti adeguati prima che le modifiche raggiungano la codebase principale.
L’esperienza del nostro team Front-end suggerisce che la maturità nell’adozione dei coding agent non si misura dal numero di agenti in uso, ma dalla qualità del processo che li governa. Isolamento dei task, confronto strutturato tra soluzioni alternative e un punto di controllo umano prima del merge sono pratiche che vanno oltre il singolo strumento e che ogni team dovrebbe considerare quando integra l’AI nel proprio ciclo di sviluppo.
Link utili
- Orca: https://www.onorca.dev
- LinkedIn post about Forca: https://www.linkedin.com/posts/davide-ghiotto_altro-modo-di-usare-lai-personalizzatevi-ugcPost-7518252438294831104-39YY
- Forca GitHub repo: https://github.com/davide97g/orca
Autore: Daniel Zotti, Team Leader & Tech Leader Frontend @ Bitrock