Come Code, IDE e Wiki di osFoundry rendono revisionabile il lavoro di più agenti AI in parallelo

Sono le 16 e da dopo pranzo tre agenti di coding lavorano sullo stesso repository. Uno ha sistemato l'arrotondamento del totale del carrello, uno ha aggiunto un codice sconto, uno ha scritto i test. Tutti e tre dicono "done". Prima che qualcosa tocchi main, vuoi sapere due cose: due di loro hanno riscritto la stessa funzione? E le tre modifiche passano ancora i test quando le metti insieme?

Tre schermate per una sola codebase

osFoundry è un'app desktop che mette chat, agenti, file e strumenti in un'unica finestra, e per il codice offre tre schermate collegate. Code è dove assegni task a più agenti contemporaneamente: ogni run ha il suo branch Git e la sua cartella di lavoro (un worktree), e tu revisioni, testi e vedi l'anteprima del merge prima di decidere qualsiasi cosa. Niente viene unito da solo. L'IDE è un editor di codice per una cartella locale, con explorer, controllo versione, terminale, pannelli Problems e Tests e una colonna con l'assistente che vede il file in cui ti trovi. Wiki legge un repository sulla tua macchina e scrive pagine di documentazione che citano path:line, poi segnala la pagina quando il codice citato cambia. Code e Wiki stanno come tab accanto a Maestro, Model chat, Multi chat e Research; l'IDE ha una voce tutta sua nella sidebar. Se conosci VS Code con il pannello Git, l'IDE ti sembrerà familiare. Code somiglia più a una inbox di pull request, solo che gli autori sono i tuoi agenti e i branch non hanno mai lasciato il tuo portatile.

Uno sguardo al tab Code

Cosa vedi in questa schermata (i run sono dati di esempio):

• Il banner in cima alla colonna. "3 agents finished · they disagree on 1 file" indica il file, qui src/cart.js, prima ancora che tu apra un diff. Il pulsante Review together avvia una revisione congiunta.
• La colonna dei run. I run sono raggruppati in base a cosa ti chiedono: Ready to review, Needs attention e una History chiusa. Ogni riga mostra il task, le righe aggiunte e rimosse, quanto ha lavorato e il branch.
• La conversazione al centro. Clicchi su un run e leggi cosa è stato chiesto all'agente e cosa ha detto mentre lavorava.
• Il pannello a destra. I tab Changes, Files, Commits, Review e PR mostrano il diff reale di ogni run: prima il lavoro non ancora committato, poi quello che è stato committato sul suo branch.
• La Merge station in basso a destra. Selezioni i run completati e qui li testi e vedi l'anteprima del merge combinato.

Caso d'uso: una tech lead con tre agenti su un repo

Dana guida un piccolo team web e divide uno sprint sul checkout in tre run di agenti: correggere l'arrotondamento nei totali del carrello, aggiungere un codice sconto al checkout, scrivere i test per il formattatore dei prezzi. Ogni run è partito da New run con un task di una riga e un agente scelto apposta, quindi ognuno ha il suo branch e la sua cartella, e nessuno può pestare i file degli altri mentre lavora.

Quando il banner dice che non concordano, seleziona tutti e tre i run e clicca Review together. Il pannello Merge mostra "3 runs · conflicts not checked yet · 3 not yet tested", un onesto "ancora non lo sappiamo" invece di un semaforo verde. Sotto, src/cart.js è segnato come contested e gli hunk di ogni branch sono elencati affiancati: sia la correzione dell'arrotondamento sia il codice sconto hanno riscritto total().

Poi preme test su ogni run. I test girano dentro il worktree di quel run, quindi il suo checkout non viene mai toccato. Di default, "Tests must pass before a branch can merge", e questa regola si può cambiare in Settings. Passano tutti e tre, ma passare da soli non è come passare insieme, quindi preme Preview combined merge. L'app unisce prima i branch in una copia usa e getta e riporta il risultato: due si uniscono senza problemi, uno va in conflitto.

Fa il merge dei due branch puliti nel suo branch corrente. Solo in quel momento il suo branch cambia. Il branch del codice sconto resta lì, così l'agente può rifare la sua modifica sopra la correzione dell'arrotondamento. Se avesse voluto la parte migliore di ogni tentativo invece di branch interi, Combine into a branch le permette di selezionare singoli hunk e creare con quelli un nuovo branch.

Un altro dettaglio che conta nelle giornate lunghe: se l'app si chiude mentre un run sta lavorando, il run ricompare come Interrupted, non come "running", con la nota che il suo branch è conservato.

Caso d'uso: uno sviluppatore solo che fa refactoring con un assistente

Kenji mantiene da solo il front end di un negozio online. Stamattina deve modificare formatPrice e non è sicuro di chi la chiami. Apre la cartella del progetto nell'IDE dalla sidebar. Il layout dell'editor è quello solito: Explorer e Source Control a sinistra, tab al centro, Terminal, Output, Problems e Tests in basso e l'Assistant a destra, dove può avviare una chat sincronizzata o una chat locale che resta sul dispositivo.

Fa clic destro su formatPrice e sceglie Show Code Graph. Il pannello elenca Callers e Calls. Un pallino pieno significa che la chiamata è stata letta dal codice stesso; un pallino vuoto significa che è stata dedotta, quindi conviene controllarla a mano. Impact of change segue anche i chiamanti dei chiamanti e, in questo esempio, mostra "15 symbols · 14 files · 3 tests". Cliccando su una riga si salta a quella riga, e Send to chat passa l'intero grafo all'assistente come contesto.

Più tardi l'assistente gli modifica un file di configurazione. In Source Control il file risulta modificato e, quando lo apre, una piccola icona a forma di robot e la barra di stato dicono che l'ultima scrittura è stata dell'AI, con il modello e il motivo indicato. Review apre un diff affiancato rispetto alla copia salvata subito prima di quella scrittura, così vede solo quella modifica. Qui mostra un timeout ridotto da 30 secondi a 3, proprio sotto un commento che dice che gli upload grandi richiedono 20 secondi o più. Se ne accorge prima del commit.

Se un agente scrive in un file mentre lui ha ancora modifiche non salvate, l'editor avvisa che il file è cambiato su disco durante la modifica e propone Keep mine o Use the disk version, invece di sceglierne uno in silenzio.

Caso d'uso: un'ingegnera del supporto che deve capire il codice, non cambiarlo

Priya lavora nell'assistenza clienti e spesso le chiedono come si comporta una parte del prodotto. Sa leggere il codice, ma non vuole mettersi a fare grep in un repository che non è suo. In Wiki usa Open a folder (o Clone a public repository con un URL https o git@) e l'app legge la struttura del progetto sulla sua macchina.

Prima di scrivere qualsiasi cosa nel progetto, Wiki chiede. Una finestra di dialogo indica la cartella esatta che creerà dentro il repo e, se clicca Not now, non viene scritto nulla. Quando accetta, usa Generate pages oppure Write a page per un singolo argomento. Le impostazioni decidono da quanto codice sorgente viene scritta ogni pagina (Depth: Quick, Standard o Deep) e quante affermazioni vengono verificate (Verification: Off, Sample o Full, dove Full circa raddoppia il costo). Il costo viene mostrato prima di generare una pagina.

Ogni pagina cita path:line e cliccando su una citazione si apre quella riga nell'IDE. Un mese dopo, una pagina nella colonna è segnalata perché "a file this page cites has changed since it was written", e questo le dice di rigenerarla prima di fidarsi. Per una domanda veloce usa la chat accanto alle pagine, le cui risposte citano anch'esse path:line di quel progetto, e dove può anche chiedere una nuova pagina a parole semplici, per esempio "write a page about the retry policy". Le pagine sono file markdown nel repository, quindi il team può revisionarle nelle stesse pull request del codice.

Dove Code, IDE e Wiki si passano il lavoro

Queste tre schermate si passano il lavoro tra loro e con il resto dell'app. Una citazione di Wiki apre l'IDE alla riga citata, e l'IDE ha un pulsante Wiki for this folder per il percorso inverso. L'Assistant dell'IDE e la chat accanto alle pagine di Wiki sono costruiti su Maestro, lo stesso assistente che usi nel resto di osFoundry, quindi fare domande lì funziona come in qualsiasi chat di Maestro. Per cercare in una codebase per significato e non per parole esatte, Indexes crea un indice di ricerca locale che Maestro può usare. E quando un run di Code è pronto a lasciare il tuo portatile, Open PR apre una pull request per il suo branch.

Le pagine prodotto mostrano demo interattive di entrambi: Code e l'IDE.

Le prime domande che fanno tutti

Mi serve l'app desktop?
Sì. Code, l'IDE e Wiki lavorano su cartelle locali, worktree Git, una shell e language server, quindi girano nell'app desktop di osFoundry.

Un agente può fare merge nel mio branch da solo?
No. I run lavorano sui propri branch, nelle proprie cartelle. Il tuo branch corrente cambia solo quando premi merge e, di default, solo per i branch i cui test sono passati.

Wiki è una wiki di team come Notion?
No. Scrive documentazione a partire da un repository di codice, citando file e riga, e segnala le pagine quando quel codice cambia. Serve per la documentazione della codebase, come una panoramica dell'architettura o note di onboarding.

Che fine fa un branch in conflitto?
Resta dov'è. Puoi fare subito il merge dei branch puliti e lasciare che l'agente rifaccia quello in conflitto sopra di essi, oppure scegliere singoli hunk con Combine into a branch.

L'app desktop si scarica gratis da osfoundry.io/it/download.