Strumenti semplici, sviluppo a guida autonoma: come Muse costruisce se stesso

TL;DR Muse sostituisce le console di orchestrazione di agenti su misura con quattro strumenti che ogni team di sviluppo software ha già aperti: Slack, Linear, GitHub e Claude Code. Niente dashboard, niente SPA, nessuna riga di codice scritta da un umano. Ogni PR supera sette gate di CI e un panel di revisione IA a tre ruoli, secondo una policy di merge a zero rilievi. 40,000 voti raccolti, valutazione dei modelli di base 80% più veloce.

Muse, abbreviazione di Meshy Universal System for Evaluation, è la nostra piattaforma interna di valutazione dei modelli. I team di Meshy la usano ogni giorno per capire se i nuovi checkpoint di un modello si comportano meglio di quelli precedenti.

Un giorno, un nuovo checkpoint del modello, molto atteso, era appena stato completato. Serviva un confronto in stile arena per decidere la prossima strategia di training. Il team si è reso conto che serviva una nuova funzionalità di Muse per supportarlo.

"@Linear crea un issue di Muse su questo"

ha scritto il Product Manager su Slack.

Un minuto dopo, è stato creato l'issue Linear MES-12345.

Il responsabile della piattaforma Muse — io — ha visto l'issue. Andava rilasciato al più presto per sbloccare il task di valutazione. Poi, è stato inviato questo messaggio a Claude:

"Indaga e risolvi MES-12345"

Claude ha esaminato l'issue, poi ha sollevato due decisioni di design. Le decisioni sono state prese, e io ho lasciato il terminale per lavorare ad altro.

Un'ora e mezza dopo, una nuova versione di Muse era in produzione. Fatto.

L'ingegneria del software autonoma non deve per forza passare da fantasiose console di orchestrazione di agenti o dashboard. E in questo articolo spiegherò come lo abbiamo reso possibile.

Una galleria, un viewer e un pulsante di voto

La domanda a cui Muse risponde è ingannevolmente difficile: il nuovo checkpoint del modello è davvero migliore? Certo, ci sono metriche quantitative da monitorare in ogni run di training, ma sono ben lontane dal rappresentare fedelmente cosa significhi "buono" nella generazione 3D. Quindi Muse fa la cosa semplice ma efficace: il test in doppio cieco. Mette a confronto gli output di due modelli, con la stessa immagine di input, posizione sinistra/destra randomizzata, e lascia che i colleghi votino alla cieca.

Una valutazione è un batch di queste coppie. Qualcuno punta Muse su due set di mesh generate e una cartella di immagini di riferimento, e da lì l'app si occupa di tutto: abbina i modelli, rende cieca l'assegnazione, mostra un confronto alla volta. I voti si accumulano ogni volta che qualcuno ha un minuto libero. L'intera interfaccia è pensata per essere consumata a piccoli morsi, ed è quasi interamente navigabile da tastiera. Chi deve allungare la mano verso il mouse vota di meno.

L'interfaccia di voto di Muse: due mesh generate, stessa immagine di input, posizione sinistra/destra randomizzata.

Questo è il prodotto. Una galleria, un viewer e un pulsante di voto. Niente nella funzione di Muse è complicato, ed è esattamente per questo che diventa un caso di studio pulito. Ciò che è insolito è solo il modo in cui viene costruito.

Un'architettura che gli agenti sanno navigare

Il progetto Muse è iniziato alla fine del 2025, quando il "vibe coding" era diventato da poco l'ultima parola d'ordine. Oltre a supportare gli sforzi di valutazione crescenti di Meshy nei cicli di training e rilascio, Muse aveva anche un obiettivo ambizioso: costruire software per l'intera azienda, con zero righe di codice scritte da un umano.

Oggi, i risultati sono eccezionali:

• Oltre 40,000 voti raccolti dal primo rilascio di Muse, con oltre 30 progetti di valutazione al mese
• Più di 4 team che usano attivamente Muse per il lavoro quotidiano
• Prima codebase interna con contributi attivi di almeno 1 membro del team non tecnico
• Prima codebase interna a raggiungere uno sviluppo completamente autonomo

Nel complesso, stimiamo che Muse abbia velocizzato la valutazione dei nostri modelli di base di almeno l'80% e tagliato almeno 10 persona-giorni di lavoro a ogni rilascio di modello. Senza Muse, mantenere l'attuale ritmo di sviluppo e rilascio della collezione di modelli generativi di Meshy — geometria, texture e smart topology — sarebbe stato quasi impossibile.

Fin dal primo giorno, Muse è stato progettato per essere il più leggibile possibile per gli agenti. Già nel 2025 avevamo notato che, per implementare lo stesso caso d'uso, gli agenti faticavano in alcuni casi e riuscivano al primo colpo in altri. Molte di queste iterazioni hanno infine portato allo stack tecnologico volutamente noioso di oggi. Il backend è in Python: FastAPI, Postgres per i record, S3 per mesh e immagini. Il frontend è renderizzato lato server: template Jinja2, HTMX per gli aggiornamenti parziali delle pagine, Tailwind per lo stile, e un solo vero componente lato client, il viewer 3D WebGL che renderizza le mesh. Non c'è nessuna SPA né un modulo frontend separato. L'accoppiamento tra i due stack è il più antico del web: il backend renderizza HTML, il browser lo mostra. Quando una pagina deve cambiare, HTMX richiede un frammento e il server renderizza anche quello.

Ecco l'architettura dell'app di valutazione principale di Muse:

L'architettura a livelli dell'app di valutazione principale di Muse. Le dipendenze puntano solo verso il basso.

Due proprietà di questa struttura contano per gli agenti. Primo, lo stato del frontend vive sul server. L'HTML che l'utente vede è l'HTML prodotto dal backend, quindi un test (o un agente) può fare asserzioni direttamente su di esso senza dover pilotare un framework lato client per ricostruire ciò che l'utente ha visto. Secondo, ogni dipendenza è imposta a livello di build e punta solo verso il basso. Una cartella di feature non può importare la sua "sorella"; se due feature hanno bisogno l'una dell'altra, la composition root inietta una capability nell'altra, così la dipendenza è visibile in un unico file. Ogni livello ha un solo compito, e questi compiti sono scritti proprio dove un agente ci inciamperà:

Le dipendenze puntano sempre e solo verso il basso in questo elenco, e la direzione è imposta da un controllo di build, non da una convenzione.

Altre tre proprietà rendono la codebase deliberatamente leggibile per gli agenti:

• Ogni directory ha la propria documentazione (cosa fa il servizio, le sue regole di livello, i comandi esatti che bloccano un merge), così un agente che arriva "a freddo" può orientarsi senza dover chiedere o inventarsi le cose da solo.
• I moduli non banali hanno docstring con link ai documenti di design, così il perché sopravvive accanto al cosa.
• Nessun file può superare le 500 righe, con un vincolo a senso unico per i pochi casi di eccezione. Per le eccezioni, i file possono solo restringersi, mai ricrescere. Le finestre di contesto sono finite; l'architettura ne tiene conto.

Il progresso non deve vivere in una stanza chiusa

Oggi, dato che gli agenti LLM sono molto più potenti rispetto al 2025, vogliamo che lo sviluppo di Muse sia completamente autonomo. Cioè, l'umano si limita a indicare il task all'agente. L'agente si orienta da solo nella codebase e nel contesto del task, procede attraverso implementazione, CI e code review, e infine porta da solo la pull request fino al merge. L'umano si limita a stabilire la priorità degli issue e a prendere le decisioni di design chiave.

I primi pensieri su uno sviluppo completamente autonomo vanno di solito verso piattaforme su misura: console di orchestrazione, workspace nativi per agenti, un'app dopo l'altra che promette di gestire la tua flotta. Le abbiamo guardate, e abbiamo detto di no. Non perché non siano ottimi prodotti, ma per una questione di leggibilità, di nuovo.

Vogliamo che il lavoro degli agenti sia leggibile dagli umani, così come la codebase deve essere leggibile dagli agenti. Siamo un'azienda di dimensioni non piccole. Se metti lo sviluppo autonomo dentro una console personalizzata, il suo progresso diventa visibile solo alle poche persone che vivono in quella console.

Di conseguenza, ancora una volta, lo stack di strumenti di collaborazione e sviluppo è volutamente noioso. Tutto ciò che raccontiamo qui gira su quattro strumenti che ogni azienda software ha già aperti: Slack, Linear, GitHub e Claude Code. Questo rende il progresso dell'agente osservabile e ricercabile esattamente come quello di qualsiasi membro del team. Un product manager apre gli issue su Linear e controlla lo stato delle feature come ha sempre fatto. Il bug bot di GitHub o la security review leggono i thread delle PR come hanno sempre fatto. Chiunque segnali un bug incolla uno screenshot nello stesso canale Slack di sempre, e la fix compare come una normale pull request. Nessuno deve imparare nulla per supervisionare la "macchina".

Ecco com'è fatto un singolo issue autonomo, dall'inizio alla fine:

Un issue autonomo, dall'inizio alla fine. L'umano tocca il ciclo in esattamente due punti.

L'umano tocca questo ciclo in esattamente due punti: indicare all'agente l'issue su Linear, e la manciata di decisioni che l'agente solleva prima di scrivere codice. Tutto il resto — implementazione, controlli, conversazione di review, merge e deploy — gira senza nessuno al volante. Quando un controllo fallisce o un reviewer obietta qualcosa, l'agente legge l'errore, lo risolve e fa di nuovo push, e il ciclo semplicemente fa un altro giro. Esce solo quando il branch è verde, ogni rilievo è risolto, e la coda lo ha fatto entrare nel merge.

Ciò che rende tutto questo possibile non è un'integrazione su misura. È il fatto che i tre strumenti espongono già superfici di comando che un agente può pilotare direttamente, le stesse che usa una persona:

• GitHub, tramite la sua CLI. L'agente apre la pull request, legge lo stato e i log di ogni job di CI, risponde nei thread di review e li segna come risolti, e mette in coda il branch per il merge, tutto attraverso normali comandi gh.
• Linear, tramite il suo server MCP. L'agente legge l'issue che gli è stato indicato, segue i link agli issue correlati per il contesto, cambia lo stato, e apre issue di follow-up per il lavoro che scopre lungo il percorso, tutto come chiamate di tool di prima classe.
• Il monitor loop proprio di Claude Code. La CI richiede minuti e la coda di merge richiede ancora di più, e nessun umano sta osservando. È l'agente a osservare al suo posto, e il modo in cui lo fa è ciò che trasforma un'esecuzione incustodita in qualcosa di pratico invece che in un falò di token.

Quando l'agente apre una pull request non se ne resta lì ad aggiornare una pagina; registra ciò che sta aspettando — l'esecuzione della CI, i thread di review, la voce in coda di merge — e poi conclude il turno. La funzionalità Monitor di Claude Code lo richiama solo quando quello stato osservato cambia: un job diventa rosso, il panel di review pubblica un rilievo, la coda mergia il branch. Poiché l'agente viene risvegliato dai messaggi del Monitor su ogni aggiornamento di stato, prenderà di conseguenza l'azione successiva, come recuperare il log di un job fallito e fare push di una fix, rispondere a un thread di review e segnarlo come risolto, oppure mettere in coda il branch una volta che ogni gate è verde.

Nessuna di queste caratteristiche è specifica di Muse. Qualsiasi repository raggiungibile da questi tre strumenti può essere pilotato allo stesso modo, ed è esattamente per questo che li abbiamo scelti.

La fiducia è un artefatto di build

Non ci fidiamo dell'LLM in sé. Ci fidiamo dell'agente LLM dentro un harness, e l'harness può essere progettato come guardiano dell'affidabilità. Concretamente, l'harness è la nostra pipeline di CI/CD più il livello di review sopra di essa. Questo è ciò che ogni pull request attraversa, senza eccezioni:

Ogni pull request passa attraverso lo stesso harness: prima i controlli automatizzati, poi il panel di revisione IA.

I singoli job, con i tempi tipici misurati su esecuzioni reali e recenti di PR:

I guardrail sono l'architettura che abbiamo descritto trasformata in macchine. Un import tra "sorelle" qui non è un commento di review; è una build rossa. I golden visivi sono catturati nell'ambiente di rendering proprio della CI, così "funziona sulla mia macchina" non può mai essere un argomento per mergiare un bug in main.

È nel livello di revisione IA che le cose si fanno interessanti. Ogni PR viene letta dal nostro panel di tre agenti di coding che fanno da reviewer, che leggono lo stesso diff confrontandolo con i principi di design scritti del repo, ciascuno con una persona assegnata diversa. Qui mostriamo una traccia dei prompt dati a ciascun reviewer.

Il Principal Engineer:

Persona: Principal Engineer, revisione di design, ampio respiro

Rivedi a livello di sistema: se questa modifica ha senso in questo contesto, se si integra con l'architettura, se riusa ciò che già esiste e resta additiva — non se una riga è in ordine.

Vedi il diff + le Guides, non l'intero repo. Valuta il riuso e la coerenza con i pattern ...; non affermare di aver fatto una ricerca sull'intero repo che non puoi eseguire.

La tua lente: valuta il diff rispetto a queste parti delle Guides fornite ...

Test decisivo: "Se fossi il principal engineer di questa codebase, rimanderei indietro questa modifica perché si trova nel posto sbagliato, duplica una capability già esistente, o aggiunge un secondo modo di fare una cosa già risolta?" Se no, restituisci [].

Il Senior Engineer:

Persona: Senior Engineer, logica / implementazione / qualità

Rivedi dentro la modifica: se la logica è corretta, pulita, testabile e sicura. Questa è la revisione più ponderata, segui i percorsi del codice, non scorrere in superficie. Concentrati sul diff e sui file che tocca (leggili per intero).

La tua lente: valuta il diff rispetto a queste parti delle Guides fornite ...

Test decisivo: "Approverei questa logica, oppure troverei un bug, un punto non testabile, o un errore di sicurezza con una lettura attenta?" Sii specifico sull'input o sul percorso di codice che fallisce. Se la logica è solida, restituisci [].

Il QA Engineer:

Persona: QA Engineer, funziona, è testato, si romperà

Rivedi il comportamento e il rischio: se questa modifica fa ciò che dichiara, se è coperta da test, e se potrebbe rompere qualcosa in produzione o in live. Leggi il titolo e la descrizione della PR, poi verifica che il diff mantenga la promessa.

La tua lente: corrispondenza con l'intento ...; copertura dei test ...; rischio di regressione ...; trappole di produzione ...

Test decisivo: "Se fossi il QA che deve dare l'ok, bloccherei questa modifica perché non fa quello che dichiara, perché rilascia un comportamento non testato, o perché rompe la produzione?" Se è sicura e coperta, restituisci [].

Oltre a guardare lo stesso diff di codice da angolazioni diverse, i 3 reviewer condividono anche un insieme comune di regole che governano lo sviluppo dell'intera codebase, ovvero le Guides:

• Le cose che cambiano insieme vivono insieme; le cose non correlate restano separabili. Cambiare o eliminare una responsabilità tocca un solo punto.
• La logica di business non dipende dai dettagli del mondo esterno. Una funzione di logica di business gira in un test con dei fake passati come parametro, senza I/O reale. Sostituire un backend non tocca alcuna logica di business. L'app non chiama mai i propri endpoint HTTP.
• Riusa, non reinventare. Ogni capability ha una sola implementazione; un nuovo consumer chiama l'interfaccia esistente invece di copiarla.
• Aggiungi feature aggiungendo, non modificando. Aggiungere una feature significa "nuovi file + una riga di registrazione", ed eliminarla non tocca nessun'altra feature.
• Un solo modo consolidato per fare ogni cosa. Chi arriva nuovo copia il pattern esistente invece di doverne scegliere uno, e i test non hanno bisogno né di server né di DB.
• Elimina il codice nel momento in cui smette di essere usato. Non si rilascia nulla che nessuno chiama; "teniamolo per sicurezza" non è un motivo valido, perché git se lo ricorda.
• Preferisci la cosa più semplice che funziona; aggiungi complessità solo se costretto. Ogni astrazione si guadagna il suo posto con un bisogno concreto e attuale. La modifica è la più piccola che risolve il problema.

Il panel pubblica ogni rilievo bloccante come commento inline ancorato alla riga esatta, e questi commenti bloccano il merge finché non vengono risolti.

Una review presa da una recente PR di feature ha questo aspetto:

[medium] Rischio di regressione. Questa funzione è il collo di bottiglia condiviso di create-and-sync; ora comprime i file con suffisso "view" in un'unica riga raggruppata. Qualsiasi dataset preesistente ingerito secondo il vecchio schema verrà, al prossimo sync, raggruppato silenziosamente, eliminando le vecchie identità dei sample a cui le valutazioni live fanno ancora riferimento. Nessun test copre il re-sync di un dataset esistente attraverso il nuovo raggruppamento.

Quel rilievo era corretto. Il codice aveva superato l'intera suite di test e un primo giro di CI verde. I test erano giusti per il codice così com'era scritto. Il reviewer ha visto che il codice, così com'era scritto, era sbagliato per i dati che abbiamo realmente. Claude lo ha corretto, ha aggiunto il test di regressione mancante, ha risposto nel thread e ha risolto il rilievo. L'intero scambio è pubblico nella PR, esattamente come faresti nel guidare un ingegnere junior attraverso una code review.

Quella era una sola PR. Facendo girare l'agente nel tempo, riusciamo a scoprire anche altri pattern tipici:

• Una fix che causa un nuovo problema. Uno strumento diagnostico che avevamo rilasciato misurava la velocità di download. La review ha scoperto che il calcolo usava i MB (1,000,000 byte) mentre il server inviava i MiB (1,048,576 byte), quindi ogni velocità sarebbe risultata inferiore del 5%. Qualche push dopo, la review ha segnalato che la fix aveva lasciato due costanti sincronizzate a mano. Ha quindi richiesto di calcolare la velocità a partire dai byte effettivamente ricevuti. Il reviewer ha scoperto un bug creato proprio nel soddisfare la sua richiesta precedente.
• Casi d'uso a vicolo cieco. La stessa pagina è stata rilasciata con il suo link visibile a ogni utente autenticato, anche se la pagina stessa richiedeva un permesso specifico. Chiunque non avesse quel permesso avrebbe cliccato e ottenuto un errore 403. Nessun test falliva, dato che il link compariva e il gate dei permessi funzionava. Il reviewer QA ha confrontato le due cose e ha bloccato il merge finché il link non è stato mostrato solo a chi poteva davvero aprire la pagina.
• Trucchi per far passare i test. Il test di una fix costruiva a tavolino esattamente l'eccezione che avrebbe dovuto catturare, quindi passava anche se la gestione reale degli errori era rotta, perché il test riceveva il messaggio di eccezione "corretto". Il panel lo ha segnalato, e il test riscritto fa passare errori reali attraverso il codice reale. La stessa PR aveva anche un test che passava sulla macchina dello sviluppatore ma falliva in CI, perché si appoggiava silenziosamente a un file di credenziali che esiste solo sulla nostra macchina di sviluppo. Entrambi erano bug nei test stessi, catturati dal livello sopra di loro.

La nostra policy di merge è 0 rilievi dalla review IA. Ogni rilievo viene corretto, oppure confutato con prove, prima che la coda prenda in carico la PR. Abbiamo reso la confutazione un'opzione praticabile perché il panel di review segnala falsi positivi a un tasso tollerabile. Scrivere perché un rilievo è sbagliato può, a sua volta, ogni tanto scovare un errore nel ragionamento stesso del panel di review.

Superati i controlli, la coda di merge rivalida ogni branch rispetto alla punta in movimento di main, e un merge esegue il deploy in produzione automaticamente, senza nessun umano nel ciclo.

Superato ogni gate, la coda di merge rivalida il branch e un merge esegue il deploy in produzione.

Le righe di codice sono solo una piccola parte della storia

Nel corso di molte PR a guida autonoma, abbiamo notato un pattern sorprendente ma ragionevole: il tempo impiegato per iterare su controlli e review è molto più lungo del tempo impiegato per scrivere la prima implementazione, e anche il rapporto tra i due varia molto a seconda del tipo di task. Qui confrontiamo due tipi di task di sviluppo nella stessa settimana.

Caso A: dismettere una feature morta. Una piccola feature legacy è stata messa offline; il suo link, la finestra di conferma, la traduzione, i test e la baseline degli screenshot dovevano sparire tutti. Dall'apertura dell'issue su Linear al merge della PR su main sono passati solo 16 minuti, di cui i primi 2 minuti spesi a scrivere codice. Le review erano solo consultive.

Caso B: un miglioramento importante alla feature di diagnostica di rete. Era una modifica di dimensioni simili per numero di righe, con la prima versione completata in 5 minuti, mentre il tempo totale fino al merge è stato di circa 3 ore. Nel corso del lavoro, l'agente ha risolto 5 round di review e 7 rilievi bloccanti per il merge.

Anche le tempistiche sono piuttosto diverse:

Due task con un numero di righe comparabile, a cui è stato dedicato uno sforzo di verifica proporzionale al rischio.

Il secondo caso richiede undici volte più tempo non perché il codice fosse più difficile da scrivere, ma perché il rischio era diverso, e lo sforzo di verifica è stato speso in proporzione. Il Caso A era una cancellazione: lo scenario peggiore era un link rotto che comunque non si sarebbe dovuto visitare. Il Caso B era uno strumento di misurazione: lo scenario peggiore era che ogni utente si fidasse di un numero sbagliato. Il panel di review ha trovato gli errori, e ha poi passato altri tre round a rifiutare fix parziali finché la gestione degli errori non è stata tipizzata, completa e testata a fondo. Ogni round ha reso l'implementazione strettamente più solida. Nessuno di quei difetti ha fatto fallire un test, e tutti sarebbero stati rilasciati.

Questa è la parte che la generazione di codice one-shot sbaglia per costruzione. La generazione one-shot ottimizza la metrica più facile da vedere: il tempo dal prompt al codice che compila e gira. Entrambi i nostri casi raggiungono quella metrica in pochi minuti, e se ci fossimo fermati lì, il Caso B sarebbe stato "finito" pochi minuti dopo essere iniziato, e sbagliato per mesi.

La stessa pipeline che ha lasciato passare una cancellazione in 16 minuti ha trattenuto uno strumento di misurazione per 3 ore, senza che nessun umano decidesse quale trattamento ciascuno meritasse. Quando la gente chiede se il codice scritto dall'IA sia affidabile in produzione, questa è la risposta: il codice è affidabile esattamente quanto la verifica che lo avvolge, e la profondità della verifica è ormai qualcosa che si acquista in ore di agente invece che in giorni-ingegnere. Un report di velocità sbagliato costa più di tre ore, la prima volta che qualcuno lo usa per gestire un reclamo sulla rete.

Cosa abbiamo imparato e cosa viene dopo

Oggi, l'autonomia è più una proprietà dell'harness che una proprietà del modello. Ogni aggiornamento del modello ha reso i nostri agenti migliori; tuttavia, la capacità del modello in sé non arriva con una garanzia che tu possa fidarti dell'agente per far mergiare liberamente le sue pull request. Invece di investire più attenzione umana o usare ciecamente il modello frontier più costoso, abbiamo scelto di costruire le "mani" e gli "occhi", in modo che gli agenti siano dotati di tutto ciò di cui hanno bisogno per produrre codice di produzione corretto. E con l'evolversi della capacità dei modelli, questo ci permette anche di cavalcare l'onda invece di ricostruire l'impalcatura per compensare i limiti dei modelli.

Il ruolo umano si concentra, non scompare. Ciò che resta è il nucleo irriducibile: decidere cosa vale la pena costruire, metterlo per iscritto in modo abbastanza chiaro, ed esercitare il proprio giudizio nei momenti che le macchine segnalano come ambigui. Il gusto per il design e la qualità delle specifiche sono ormai la competenza ingegneristica a più alta leva in questo team.

E la conclusione più interessante sui team di agenti è che il valore del team nasce dal conflitto, non dalla collaborazione. Può avere senso dividere un task full-stack tra un agente frontend e uno backend. Ha meno senso far parlare tra loro un agente frontend e un agente backend solo per completare il task. Il beneficio del team emerge quando i membri hanno obiettivi in conflitto. Il nostro agente di sviluppo di Muse vuole rilasciare il codice. I nostri agenti di revisione IA vogliono trovare dove il codice è sbagliato o progettato male. È la loro tensione a rendere il risultato affidabile, e a rivelare fedelmente la vera quantità di lavoro di un task di sviluppo.

Ancora più importante, ci accorgiamo che le nostre esplorazioni ci portano verso un modo emergente di sviluppare software: un'organizzazione ingegneristica autonoma. Anche se abbiamo dimostrato che gli agenti possono completare autonomamente singoli task con gli strumenti esistenti, alcuni tasselli mancanti e domande aperte invitano a esplorazioni future:

• Fino a che punto siamo in grado di far scalare tali sistemi? Man mano che le organizzazioni autonome lavorano su task e progetti sempre più grandi con più agenti in parallelo, quali nuovi problemi emergeranno?
• Come possono gli output dell'harness stesso, come il tasso di successo della CI al primo tentativo e i rilievi della review IA, diventare segnali di valutazione? Come misuriamo le prestazioni di un agente nell'organizzazione, e come le rendiamo auto-evolutive?
• Come si può incorporare il gusto umano per il design e il prodotto in questi sistemi? Se l'ingegneria può essere resa autonoma con giudizi umani rarefatti, fino a dove possiamo spingerci per risolvere il problema di per chi dovremmo costruire il software, e di che aspetto dovrebbe avere?

Infine, grazie per aver letto fino in fondo. La to-do list per trovare le risposte a queste domande vive, appropriatamente, su Linear, dove il nostro prossimo agente — o tu — potrebbe raccoglierla.