Ricostruire Manus con Manus: cosa è cambiato, cosa si è rotto e come lavoriamo ora
Di Tao Zhang, Co-fondatore e Chief Product Officer, Manus
A fine settembre, durante lo sprint finale su Manus 2.0, ho inviato a uno dei nostri ingegneri alcune richieste di funzionalità e segnalazioni di bug su Slack. Più tardi sono andato a vedere come stava procedendo. Il suo schermo mostrava una fila di sessioni agent aperte, alcune in Manus e altre in Codex. Ne ho aperta una. Il prompt era il mio messaggio Slack, incollato parola per parola.
Un anno fa, avrebbe letto il mio messaggio, capito cosa intendevo e poi scritto il codice. Ora un agent legge la richiesta, trova il codice pertinente e propone una modifica. Il compito dell'ingegnere è dirigere il lavoro, verificarlo e assumersi la responsabilità del risultato. La maggior parte del tempo una richiesta è in esecuzione, non in attesa di lui. Oggi, da noi è comune che un singolo ingegnere abbia dalle 10 alle 20 richieste in corso contemporaneamente.
Sono orgoglioso di quanto rapidamente il nostro team si sia adattato. Sono anche inquieto. Questo ritmo è giusto? Cosa non abbiamo ancora notato?
Noi di Manus costruiamo agent, quindi ci atteniamo a due regole. Usiamo il nostro prodotto per il lavoro reale. E continuiamo a cercare i punti in cui l'AI smette di funzionare.
Vorrei documentare cosa succede all'interno di un'azienda quando persone e agent lavorano fianco a fianco per impostazione predefinita. Questo articolo copre tre team — ingegneria, prodotto e marketing — e include ciò che non ha funzionato. È il resoconto di un esperimento in corso, non la definizione di un'"organizzazione AI-native".
Cosa abbiamo imparato finora:
•Non esiste una via di mezzo. Aggiungere l'AI ai vecchi modi di lavorare a volte ha aggiunto rumore. Le cose sono cambiate solo quando il ciclo si è chiuso.
•Gli agent hanno bisogno del quadro completo. Un contesto migliore ha fatto per noi più di prompt migliori.
•La fiducia nasce da test e contesto, non dalla sola qualità del modello.
•L'autonomia ha bisogno di un traguardo. Gli agent possono operare da soli solo quando il successo è verificabile. Ovunque altro, decide una persona.
•Il collo di bottiglia si sposta. Quando l'ingegneria è diventata più veloce, decidere cosa costruire è diventato il vincolo.
•Il ruolo delle persone non è diminuito. Si è concentrato maggiormente su cose a maggiore impatto.
1. Non esiste una via di mezzo
Prima del 2026, facevamo ciò che facevano la maggior parte delle aziende: aggiungevamo l'AI al modo in cui già lavoravamo. Questo significava che il supporto segnalava i problemi con un riepilogo AI, gli ingegneri usavano assistenti di codifica e i bot pubblicavano analisi nei canali. Ogni pezzo era utile di per sé, ma non molti dei pezzi erano collegati tra loro. Finché il ciclo non si è davvero chiuso, stavamo semplicemente lavorando nel solito vecchio modo ma con molta AI che si sovrapponeva.
C'è una frase a cui torniamo spesso: l'ingegneria del software è programmazione integrata nel tempo. Scrivere codice è facile da misurare; mantenere sano un prodotto complesso per anni non lo è. Un'alta percentuale di codice scritto dall'AI può significare progresso reale, oppure può significare accumulare pattume che qualcuno dovrà ripulire in seguito.
Il test che ci interessa è più difficile. Manus è un prodotto complesso che è live da più di un anno. Può continuare a migliorare con nuovi modi di lavorare senza crollare, mentre ogni persona riesce a fare di più? Finora la risposta è sì.
2. Dai all'agent il quadro completo
Come la maggior parte delle aziende tecnologiche, perdevamo più tempo nei passaggi di consegne. Un ingegnere frontend e uno backend interpretavano ciascuno una richiesta, concordavano un'interfaccia e poi passavano giorni a correggere i disallineamenti. Due persone raramente comprendono un requisito allo stesso modo.
Se l'AI può scrivere codice attraverso tutto lo stack, una sola persona potrebbe gestire una richiesta end-to-end? L'ostacolo era il contesto. Il nostro codice viveva in repository separati, quindi nessun agent poteva vedere l'intero sistema contemporaneamente.
La nostra risposta a questa domanda è iniziata con un esperimento interno. Volevamo vedere fino a che punto l'AI potesse spingersi nella costruzione di un prodotto con il minor input umano possibile e quasi nessun codice scritto a mano. Il metodo che abbiamo sviluppato lungo il percorso è diventato lo strumento interno che ora chiamiamo Manus-mono, o Mono.
Mono non unisce i nostri repository. È un singolo punto di ingresso più un manuale scritto per l'agent: cosa fa ciascun repository, come si incastrano tra loro e come lavoriamo. L'agent attinge a tutto ciò di cui ha bisogno. Manteniamo anche una libreria di registri delle decisioni architetturali, in modo che ogni sessione dell'agent inizi con il ragionamento dietro le decisioni passate, non solo con il codice. Quando qualcuno lavora con un agent, quell'agent ha il contesto di tutti coloro che sono venuti prima.
Mono è cresciuto a tappe, e ogni tappa ha risolto il collo di bottiglia esposto dalla precedente:
1.Vedere l'intero sistema. Abbiamo aggiunto il contesto di business che nessun singolo repository contiene, e abbiamo utilizzato i Git worktree per il lavoro in parallelo.
2.Verificare localmente. Un push all'ambiente di test richiedeva dai 5 ai 10 minuti. Ora l'intero stack di Manus gira su un laptop e i controlli richiedono pochi secondi.
3.Debuggare i problemi in produzione. Con permessi limitati, Mono può leggere i log, la configurazione e i report di errore necessari per diagnosticare i bug in produzione.
4.Gestire i rilasci end-to-end. Mono ora gestisce i passaggi di rilascio in cui il lavoro si bloccava. Le persone prendono comunque le decisioni di approvazione.
5.Testare end-to-end. Quando la verifica è diventata la parte lenta, Mono ha iniziato a eseguire flussi utente reali con account di test, in un browser e in un simulatore mobile.
(Come funziona Mono e come si è evoluto. Realizzato da un compagno di squadra con Manus.)
Le persone a volte chiedono se Mono sia una wiki del codice. La documentazione ne è una parte, ma il resto è tutto ciò che circonda il codice: come testiamo, come rilasciamo, cosa decidiamo e perché, e cosa all'agent è e non è permesso toccare.
Nel tempo, Mono è diventato una base di conoscenza condivisa che migliora man mano che le persone vi contribuiscono. Ad esempio, il nostro ingegnere delle operations si era stancato di essere interpellato per aiutare con i rilasci, quindi ha scritto il processo di rilascio in Mono. Ora chiunque può eseguire un rilascio, e anche l'agent può farlo, ma l'approvazione spetta ancora alle persone che hanno i diritti di rilascio. Adoro il modo in cui il team lavora: una persona ha risolto la propria frustrazione, il che ha portato l'intera azienda a diventare un po' più veloce.
Il team ora dà per scontato che una sola persona possa rilasciare una richiesta su ogni piattaforma. Il nostro team mobile è stato di sette persone per tutto questo tempo. Mantengono quattro app su due prodotti e tengono il passo con il web.
Mono si è diffuso nell'azienda senza un mandato dall'alto. Penso che la cultura lo spieghi tanto quanto lo strumento stesso. Testare i limiti dell'AI è parte del motivo per cui esistiamo, e la nostra organizzazione è piatta. Uno strumento arriva solo fin dove l'organizzazione gli permette di arrivare.
3. Chiudere il cerchio: dalla segnalazione di un bug di un utente a una correzione verificata
Mono ha permesso a chiunque di lavorare su qualsiasi parte del prodotto. Questa era metà della storia. L'altra metà era permettere agli agent di trovare i problemi da soli.
Nella maggior parte delle aziende internet, la segnalazione di un bug di un utente passa attraverso il supporto, il prodotto e il triage prima di raggiungere un ingegnere che possa risolverlo.
Per noi, un agent interno ora indaga per primo sulla segnalazione e risale all'origine del problema fino alla modifica che l'ha causato. Poi pubblica su Slack e tagga l'ingegnere a cui appartiene quella modifica. L'ingegnere decide se è di sua competenza risolverla e la passa al proprio agent. Un agent separato verifica la correzione eseguendo i test e i flussi che contano.
Tre agent, tre ruoli: uno fa il triage, uno fa il lavoro, uno lo verifica. La persona nel mezzo prende le decisioni. Una quota crescente del nostro lavoro di ingegneria ora inizia in questo modo, con un agent che porta un problema a una persona.
Questo ciclo ha limiti chiari. L'agent che legge le segnalazioni degli utenti non può modificare il codice. Può solo indagare e riferire a noi. Le modifiche provengono dall'agent dell'ingegnere, dopo che l'ingegnere ha deciso. Nulla viene rilasciato senza l'approvazione di una persona con i diritti di rilascio.
4. Come abbiamo imparato a fidarci del codice scritto dagli agent
Per molto tempo, ogni modifica che entrava nel nostro branch principale richiedeva l'approvazione di uno dei due ingegneri senior. Non ci fidavamo abbastanza dell'AI per saltare quel passaggio. Man mano che gli agent producevano più codice, quella fase di revisione è diventata il collo di bottiglia.
Sulle pure capacità di programmazione, i modelli erano già forti. Abbiamo capito che la differenza si riduceva a due cose. Primo, le persone sanno come testare il proprio lavoro. Secondo, le persone sono state parte delle discussioni a monte e a valle, quindi sanno cosa significa "giusto" per il business. Codice corretto non è la stessa cosa di prodotto corretto.
Abbiamo affrontato entrambi gli aspetti:
•Lasciare che gli agent partecipino alla discussione. L'agent di ciascun ingegnere ora è presente nei thread di Slack a cui è stato aggiunto e segue il contesto. Quando qualcuno dice finalmente "Via", l'agent sa già cosa ha deciso il team e perché.
•Lasciare che gli agent testino end-to-end. Lavorando con il nostro team backend, abbiamo dato agli agent la capacità di eseguire flussi reali e test di regressione in Manus dopo ogni modifica. Man mano che la copertura dei test cresceva, cresceva anche la nostra fiducia.
Oggi, ogni modifica passa attraverso quella verifica e attraverso un bot di code review che esegue il modello più potente disponibile, con regole extra per aree sensibili come i pagamenti. Il bot ha sostituito la coda, non la decisione umana. Un agent può aprire una pull request, ma non può fare merge nel nostro branch principale senza approvazione esplicita di una persona. Sono ancora le persone a decidere cosa viene costruito e chi può rilasciare.
5. L'autonomia ha bisogno di un obiettivo finale
La fiducia ha dei limiti, e lo abbiamo scoperto a nostre spese.
A un certo punto, tutti erano entusiasti dei loop di agent completamente autonomi, quindi ne abbiamo provato uno. Un agent raccoglieva feedback dai nostri canali di feedback interni e avviava un progetto per ogni elemento. Un collega lo ha lasciato girare per un weekend. Lunedì mattina, più di 200 elementi aspettavano la sua decisione.
Perché non lasciare che l'agent prenda anche quelle decisioni? I loop autonomi funzionano quando il sistema può verificare se l'obiettivo è stato raggiunto. I test passano o falliscono; una pagina si carica o no. La maggior parte del lavoro reale non ha un tale controllo. Una persona deve giudicare se è fatto e se valeva la pena farlo.
Abbiamo tratto due lezioni da quel weekend. Primo, le persone non possono prendere decisioni alla stessa velocità con cui un loop non controllato le crea. Secondo, se nessuno decide se qualcosa debba essere fatto, nessuno possiede il risultato. Il loop di correzione dei bug nella sezione 3 funziona perché i test definiscono il successo. Le decisioni di prodotto non hanno test, quindi ogni modifica di prodotto in Manus inizia ancora con una persona che decide se vale la pena farla.
6. Quando l'engineering è diventato più veloce, il prodotto è diventato il collo di bottiglia
Un processo di prodotto tradizionale ha molti passaggi di consegna, e le priorità si spostano un po' a ciascuno di essi. Man mano che gli agent di coding rendevano gli ingegneri più veloci, è emerso un nuovo problema: non c'erano abbastanza product manager per scrivere buoni requisiti. Per la prima volta, l'engineering non era il vincolo.
In Manus, la nostra prima soluzione è stata chiedere ad alcuni ingegneri di diventare "builder" che possiedono un problema dalla scoperta al lancio. Poche persone avevano sia il giudizio tecnico che quello di prodotto. Poi abbiamo lasciato che i PM modificassero il codice. Anche quello si è bloccato. I passaggi di consegna erano ancora lì, e senza l'istinto di un ingegnere, i PM potevano cambiare testi e interazioni ma non la logica sottostante.
Mono ha risolto entrambi i problemi perché porta le regole con sé:
•Qualsiasi modifica che tocca le chiamate ai modelli o i costi richiede l'approvazione del proprietario prima che venga scritto il codice.
•Ogni modifica passa attraverso la stessa revisione e gli stessi test di una modifica di un ingegnere.
•Mono può percorrere la registrazione e il pagamento con account di test e registrare ogni passaggio, così un PM può indicare il momento esatto in cui qualcosa si rompe.
Ecco come appare nella pratica. Una PM che lavorava sullo speech-to-text ha fatto fare a Manus il benchmark di più di 10 modelli, poi ne ha scelto uno. Ha estratto il codice frontend tramite Mono, ha costruito una demo nel nostro design system, e ha fatto renderizzare da Manus ogni scenario utente come immagine da revisionare. Ha trasformato la demo in un video. Il piano era abbastanza chiaro che ha costruito la funzionalità da sola, inclusa la UI web e desktop.
Lungo il percorso, le persone hanno preso tre decisioni. Lei ha scelto il modello. Il team di prodotto e design ha esaminato la demo. Un ingegnere con diritti di rilascio ha esaminato il codice. Un anno fa, nulla di tutto questo sarebbe stato possibile.
Descriviamo questo passaggio come il movimento da human in the loop a human on the loop. L'AI svolgeva il 70-80% di un'attività e le persone completavano il resto. Ora le persone stabiliscono le regole, supervisionano diversi agent, verificano metodi e risultati nei punti chiave, intervengono quando necessario e si assumono la responsabilità del risultato.
Alcuni PM ora consegnano un breve video invece di una specifica scritta o di mockup. In pochi minuti, mostra il caso d'uso, ogni schermata, cosa fa ogni click, come si comportano i casi limite e come tutto funziona internamente. Per noi, design, ingegneria e QA si accordano più rapidamente su cosa significhi "fatto", e il PM lo spiega una sola volta.
(Video dei requisiti di prodotto per l'input vocale)
Oggi circa la metà dei nostri PM rilascia funzionalità in autonomia, e ogni PM ha scritto codice. Anche i designer hanno iniziato. Un PM ha scritto gran parte dell'interfaccia di Manus Studio in Manus 2.0. Un altro ha scritto il Video Editor. Dietro a ciascuno di loro c'è qualcuno che ha passato mesi spingendosi oltre ciò che il proprio ruolo copriva. È ciò di cui sono più orgoglioso.
Questo non significa che tutti debbano essere costruttori. Quando chiunque in un'azienda può costruire, le persone potrebbero rilasciare cose che non dovrebbero esistere. Il nostro team di prodotto spesso pone una domanda: "Se richiedesse un secondo e non costasse nulla, lo rilasceresti?" A volte la risposta è no. Abbiamo ancora bisogno di responsabili di modulo che decidano cosa viene costruito, cosa no e cosa gli utenti vedono alla fine. Abbiamo anche bisogno di persone che mantengano l'infrastruttura come Mono. Quando costruire diventa facile, decidere cosa costruire conta di più.
7. Un compagno di squadra AI all'interno del flusso di lavoro di marketing
Una partnership di marketing passa attraverso revisione dello script, prezzi, contratti, approvazioni, pagamento, lancio e revisione dei risultati. Questi passaggi avvengono nelle email, negli strumenti per i contratti, nei sistemi di approvazione, nei fogli di calcolo e nelle piattaforme pubblicitarie. Gran parte del lavoro consisteva nello spostare informazioni tra di essi, lasciando poco tempo per il lavoro creativo che richiede giudizio.
Siamo partiti da un piccolo problema: quando il contenuto di un partner o un annuncio veniva pubblicato, spesso lo scoprivamo in ritardo. Così abbiamo chiesto all'AI di scrivere uno script che rilevi quando un contenuto viene pubblicato. Poi volevamo i dati sulle performance. Poi una revisione delle partnership passate. Poi è stato collegato l'intero flusso di lavoro interno: quando un contratto viene firmato o un'approvazione viene completata, l'agent aggiorna lo stato e notifica chi è responsabile del passaggio successivo.
Manus ha integrato tutto questo in un sito interno. Per le persone, sono dashboard e un calendario. Per l'agent, è un insieme di strumenti. L'agent che utilizza quegli strumenti all'interno del nostro flusso di lavoro è ciò che chiamiamo un compagno di squadra AI. Lavora solo nei canali e nei sistemi a cui il team l'ha collegato, con un accesso limitato a questo flusso di lavoro.
Ecco cosa fa:
•Gestisce la propria coda. Molte persone gli scrivono contemporaneamente, quindi parla con tutti in un'unica sessione "front desk" e assegna le attività a sessioni parallele. Decide se un messaggio è rilevante per lui, poi se interrompere il lavoro in corso o aspettare. Ha proposto lui stesso queste regole durante lo sviluppo, e noi le abbiamo riviste prima di mantenerle.
•Impara dal contesto inoltrato. Un cambio di strategia significava una riunione e un brief scritto. Ora il nostro responsabile marketing inoltra la discussione e dice: "Impara questo."
•Tiene in vista gli obiettivi a lungo termine. In un'occasione, i compagni di squadra in un thread Slack a cui era stato aggiunto non riuscivano a ricordare lo stato di un progetto. Senza essere taggato, ha risposto: "B è ancora in test. Dovremmo aspettare i risultati di A prima di esaminare B?"
•Verifica i fatti con altri team. Dopo che abbiamo lanciato il rigging dei modelli 3D, ha chiesto al team di prodotto cosa fosse supportato. Ha appreso che il rigging copre sette categorie, inclusi pesci, serpenti e quadrupedi, così le nostre descrizioni sono rimaste accurate.
I compagni di squadra ora lo coinvolgono nelle revisioni degli script e dei prezzi, perché ha letto i nostri registri di partnership passate. Sono ancora le persone a prendere la decisione.
Il sito interno può anche migliorare grazie ai propri utenti, incluso l'agent. Quando l'agent incontra difficoltà, invia una richiesta tramite un endpoint di feedback. Ciò apre un'attività di sviluppo in Manus tramite Automations in Manus 2.0, e un ingegnere rivede la modifica prima che venga rilasciata. È in funzione da circa una settimana. Abbiamo bisogno di molti altri casi prima di poterci affidare ad esso.
Quindi cosa fanno le persone del team? Tre cose restano a loro. Prendono e sono responsabili di ogni decisione importante. Gestiscono i casi che l'agent non ha mai visto e gli insegnano cosa fare o a chi rivolgersi. E lo reindirizzano ogni volta che la sua analisi punta a una nuova prospettiva.
8. Interrompersi meno a vicenda
In tutti questi team, molte domande non richiedono più di interrompere qualcuno.
Chiedi prima all'agent. Un collega ha creato un bot Slack su Mono che gira su un computer in cloud e risponde nel thread. Lo usano soprattutto i non ingegneri. Come funziona questa feature? Dov'è questa stringa? È stata rilasciata? Non devono più trovare prima il responsabile.
Apri la sessione invece di chiedere un aggiornamento di stato. I progressi di un ingegnere vivevano nelle sue chat AI personali, invisibili una volta uscito. Così abbiamo creato una funzionalità interna che permette ai membri di un progetto di vedere le sessioni degli altri e di chiedere di partecipare. Un ingegnere potrebbe costruire gran parte di una feature con l'agent, e poi un PM si unisce alla stessa sessione per regolare spaziatura, stili e testi. Pubblicare nella sessione di qualcun altro richiede la sua approvazione, e stiamo ancora definendo i permessi.
(Esempio illustrativo: come un ingegnere, un PM e un designer lavorano in un'unica sessione. Non è una vera modifica di prezzo.)
L'obiettivo non è parlarci meno. È interromperci meno.
Decidi solo ciò che serve decidere. Il nostro utente AI più intenso mantiene una sessione principale con un unico compito: elencare ciò che richiede la sua decisione, con una raccomandazione per ciascuna voce. Quando Slack si fa affollato, se ne tiene fuori e chiede: "Cosa devo decidere adesso?"
Faccio qualcosa di simile. Ho più di 20 to-do al giorno e, come ho condiviso pubblicamente, ho l'ADHD. Iniziare è la parte più difficile per me. Ora ogni to-do finisce in un progetto Manus dedicato che trasforma ciascuno in un proprio task. Avvia ciò che può. Quando è incerto, mi chiede il contesto e quale PM dovrebbe prenderlo in carico. Poi, usando l'accesso che gli ho dato ai miei Slack, Gmail e Notion, raccoglie il contesto e consegna al PM una richiesta completa invece di una nota di una riga. Per me il cambiamento non riguarda solo l'efficienza. Ora passo molto meno tempo della mia giornata in ansia su dove iniziare, il che è enorme a livello personale.
9. Ne vale il costo?
Spendiamo molto in AI e monitoriamo questa spesa da vicino. Non la usiamo per giudicare le prestazioni di nessuno. La usiamo per giudicare la spesa stessa: sta ripagando ora, o ci sta preparando per dopo?
Ecco cosa pensiamo ci porti, e dove ci aspettiamo che vada il costo:
•Compra tempo e attenzione. Man mano che un team cresce, il coordinamento erode l'attenzione di tutti. L'AI protegge l'attenzione di ciascuno e dà loro una piena ownership del proprio lavoro. E stiamo ancora assumendo.
•Usare i migliori modelli è il modo in cui scopriamo i limiti dell'AI. L'impostazione di verifica e code review descritta nella sezione 4 gira sui modelli più potenti che possiamo ottenere. Il collega che guida la produttività degli sviluppatori la definisce la nostra spesa dal miglior rapporto qualità-prezzo.
•Il costo dovrebbe scendere grazie al prodotto. Sempre più sviluppo avviene ora in Manus Studio, il nostro stesso prodotto, quindi i nostri dati di utilizzo ci mostrano dove si sprecano tokens. Le correzioni finiscono nel prodotto, quindi dovrebbero rendere Manus più efficiente anche per gli utenti. Ci aspettiamo che i costi odierni calino sostanzialmente man mano che i modelli diventano più economici e noi eliminiamo gli sprechi. È una convinzione, non una promessa!
10. Cosa non funziona ancora
Le interruzioni sono meno, ma l'attenzione è più frammentata. Chi prima gestiva quattro o cinque cose al giorno ora potrebbe portare avanti 20 o 30 contemporaneamente. Ogni passaggio significa ricaricare il contesto. L'AI espande ciò che le persone possono fare, e le spinge anche a fare di più. Una PM mi ha detto che ogni volta che un task è in esecuzione, non riesce a resistere ad avviare un altro agent. Fare più cose non è l'obiettivo. Lo trattiamo come un problema da risolvere, non un ritmo da celebrare.
Le informazioni sono più sparse. Il nostro head of product conosceva ogni modifica e il motivo per cui era stata fatta. Ora a volte fa uno screenshot di un problema e chiede a Mono: "Chi ha cambiato questo?" È divertente, ma la domanda è reale. Quando tutti hanno il potere di cambiare il prodotto, chi è responsabile dell'insieme?
I permessi di condivisione hanno bisogno di una riprogettazione. Quando il lavoro può essere condiviso e trasferito, e gli agent sono presenti in più delle nostre conversazioni, dobbiamo decidere cosa è aperto e cosa richiede approvazione.
Le nostre soluzioni sono ancora basilari. Per ora, un agent supervisiona gli altri e segnala solo ciò che è bloccato e ciò che richiede una decisione umana. Sappiamo che si può fare di meglio.
11. Cosa stiamo costruendo dopo
Questi problemi indicano un lavoro sul prodotto di cui probabilmente avranno bisogno anche altri team. Non abbiamo pianificato queste funzionalità in anticipo. Sono nate dai problemi in cui ci siamo imbattuti noi stessi.
•Sessioni come spazi di lavoro condivisi. Una persona solleva un problema, un designer propone una soluzione, un ingegnere la realizza e un PM la gestisce, tutto nello stesso luogo.
•Lavoro che si sposta tra dispositivi e persone. Le macchine locali e cloud rimangono connesse, così il lavoro può continuare anche quando le persone si allontanano.
•Agent che trovano opzioni a cui le persone non avevano pensato. Un agent che opera all'interno dei sistemi di un'azienda, con le giuste autorizzazioni, dovrebbe essere in grado di suggerire soluzioni, non solo eseguire istruzioni.
Proveremo prima queste cose su noi stessi, poi le porteremo agli utenti.
12. Cosa fanno le persone ora
L'ingegnere con una fila di sessioni di agent aperte non è solo una storia di efficienza. È un cambiamento in ciò su cui si basa un'organizzazione. Le aziende erano solite far circolare le informazioni attraverso ruoli e gerarchie. Ciò che una persona poteva fare dipendeva da quante persone e risorse poteva sfruttare. Ora dedichiamo un po' di tempo a fornire contesto e strumenti all'AI, e più tempo a esprimere giudizi e prendere decisioni. Sempre più spesso, è un agent a portarci un problema. Decidere cosa farne resta compito nostro.
Ci abbiamo scherzato su: se Manus può fare così tanto, perché venire in ufficio? Lasciamo che siano gli agent a risolvere la questione. Ma le domande importanti hanno ancora bisogno delle persone che le sollevino, le discutano e le decidano. Per esempio, cosa conta come un buon prodotto? Oppure, esagerando un po': costruire un ottimo prodotto con entrate reali che continui a spingere i limiti dell'AI, o puntare al margine? L'AI non sa quale vogliamo. Noi sì. La cultura e la fiducia nascono dall'affrontare le cose insieme, giorno dopo giorno e nei momenti che contano. Questa è la base su cui poggia il lavoro in ogni sessione.
Quindi, per ora, ecco la nostra risposta. Nel nostro esperimento come organizzazione AI-native, il ruolo delle persone non si è ridotto. Si è concentrato maggiormente sulle aree in cui possono avere il maggiore impatto: definire il problema, giudicare la qualità, decidere cosa vale la pena fare, assumersi la responsabilità del risultato.
Ecco anche perché continuiamo ad assumere. Le competenze e il giudizio delle persone sono al centro di questo modo di lavorare — e questo non cambierà a breve.
Mentre scrivo, sono curioso di sapere cosa direbbe questo post tra un anno. Ogni azienda ha obiettivi, strutture e cultura diversi, quindi potrebbe non esserci una risposta standard né una forma definitiva. Ma per un'azienda che costruisce agent, capire come persone e AI lavorano insieme non è facoltativo. Fa parte del lavoro. Continueremo a impegnarci, e continueremo a condividere ciò che impariamo.
Una nota sui numeri. Le cifre in questo post provengono da registri interni. Le dimensioni dei team e le cifre di consegna dei PM si riferiscono a fine ottobre. Alcuni punti sono stime o esperienze di una singola persona piuttosto che misurazioni.
