Micro-framework nella console di amministrazione
Ogni distribuzione di Asana ha una Console di amministrazione. È il luogo in cui gli amministratori IT configurano il modo in cui la loro azienda utilizza Asana, ad esempio modificando i requisiti delle password, i ruoli e le autorizzazioni, stabilendo se i file possono essere allegati da Dropbox e chi può vedere un nuovo progetto per impostazione predefinita.
Con la crescita di Asana, la Console di amministrazione ha accumulato anni di logica personalizzata e soluzioni temporanee, rendendo i controlli amministrativi sempre più costosi da creare e gestire. Prendiamo un'impostazione amministrativa: la privacy predefinita per i nuovi progetti. Un amministratore sceglie se un nuovo progetto sia inizialmente visibile all'intera organizzazione, visibile al suo team o privato per i membri invitati. Semplice da descrivere, ma c'è molta complessità nascosta:
Questa funzionalità è inclusa nel piano del cliente?
In passato pagava per questa funzionalità, poi ha smesso e ora è bloccato su un'impostazione che non può più modificare?
È un cliente HIPAA o FedRAMP, dove solo i ruoli con privilegi elevati possono modificarla?
Una delle opzioni è resa non disponibile da qualche altra impostazione?
È necessario mostrare un banner informativo per descrivere le limitazioni attuali?
Qualsiasi team che volesse aggiungere un controllo di amministrazione doveva fare tutto nel modo giusto. La maggior parte ha deciso che non ne valeva la pena e, col tempo, il divario tra ciò che Asana poteva fare e ciò che un amministratore poteva gestire si è ampliato. Ciò è dimostrato dal fatto che alcuni controlli possono essere configurati solo a livello di tutta l'azienda, rendendo difficile per gli amministratori IT applicare il controllo solo a un sottoinsieme dei loro utenti.
Ecco un frammento di codice per la finestra di dialogo delle impostazioni di privacy del progetto, utilizzata per determinare se dovrebbe essere disabilitata e se dovrebbe essere visualizzato un banner:
C'è molta logica da analizzare: licenze delle funzionalità, governance, eccezioni dovute alla struttura di distribuzione e ruoli degli utenti, in particolare per i revisori. Per essere scrupolosi, bisognerebbe ricostruire mentalmente la matrice di test per stabilire se è corretta.
E questa è solo la finestra di dialogo. Il fatto che la riga venga visualizzata nella pagina delle impostazioni è stato deciso altrove, e anche in modo incoerente:
Tre righe, tre meccanismi e il controllo non è sempre nello stesso file. Quindi, per rispondere alla domanda "Quali impostazioni vede effettivamente questo cliente?", non solo si doveva leggere ogni riga, ma anche esaminare ogni componente. Questa domanda sorge abbastanza spesso: l'assistenza clienti che cerca di spiegare perché un'impostazione è scomparsa per un cliente, un PM che vuole una risposta chiara sul fatto che una nuova opzione di controllo comporti una modifica rapida o una che richiede due settimane, un neoassunto che cerca di trovare l'unico punto in cui si decide cosa può vedere un utente specifico.
In generale, quattro aspetti rendevano oneroso lavorare nella Console di amministrazione:
Difficile da controllare. La logica risiedeva ovunque l'autore la inserisse, quindi una PR poteva introdurre un comportamento speciale senza che ciò fosse evidente a un revisore, e la correttezza non era qualcosa che si potesse verificare facilmente solo leggendo.
La mancanza di standardizzazione nascondeva i bug. Avevamo bug di vecchia data che erano difficili da individuare. Molti erano dovuti alla divergenza tra le specifiche del prodotto e l'implementazione, causata da una grande quantità di implementazioni personalizzate. I team prendevano decisioni arbitrarie, per cui ogni controllo aveva le sue peculiarità.
Costoso da modificare. Per apportare una modifica per l'utente finale, era necessario individuare ogni punto in cui una regola era stata codificata, e raramente esisteva un unico punto di definizione.
Testare era costoso. L'impostazione dei test richiedeva una profonda conoscenza degli stati di backend, e un test manuale completo delle distribuzioni finali era impraticabile a causa del numero di dimensioni che interagivano tra loro.
Scopri i framework
Abbiamo creato un framework dichiarativo per i controlli amministrativi che fungesse da fonte di verità nel codebase. Ora un controllo indica di cosa si tratta:
Ogni campo qui corrisponde a un ramo della finestra di dialogo precedente: requiredAdminRole è il controllo HIPAA/super-admin, upsellBehavior sono i due rami di upsell e churnBehavior è il caso del cliente che ha interrotto il rapporto, consentendogli di ripristinare le impostazioni predefinite e nient'altro.
In questo contesto, il framework espone gli hook che i progettisti utilizzano per derivare lo stato calcolato del controllo. Dai un'occhiata a come si presenta ora la stessa finestra di dialogo sulla privacy del progetto:
La catena di istruzioni if del banner si è ridotta a un unico componente condiviso gestito da un hook centralizzato. Il framework gestisce la logica combinatoria di tutti i diversi scenari e gli SME responsabili della sua manutenzione, che conoscono a fondo il prodotto di amministrazione, possono apportare modifiche radicali con sicurezza. Ora utilizziamo una tipizzazione rigorosa per guidare gli implementatori nell'inserimento delle informazioni obbligatorie necessarie per visualizzare correttamente le loro impostazioni in tutti gli scenari possibili. È fondamentale sottolineare che non è necessario che comprendano le complessità di tali scenari o le modalità di interazione tra di essi.
Queste impostazioni sono accessibili tramite le righe nell'interfaccia utente della Console di amministrazione. La visibilità di queste righe ha ricevuto lo stesso trattamento, ed è qui che entra in gioco il secondo framework. Una riga nel registro delle impostazioni non descrive le proprie regole di visibilità, ma le collega ai controlli che la rappresentano:
L'array dei controlli è il valore aggiunto. Contiene lo stesso oggetto ProjectDefaultPrivacy che la finestra di dialogo passa a useAdminConsoleControl, e il registro lo esegue attraverso la stessa fonte di riferimento, in modo che la pagina e la finestra di dialogo non possano essere in disaccordo. In precedenza veniva calcolato separatamente, per cui le discrepanze potevano portare a due modalità di errore: una riga visibile ma che apriva una finestra di dialogo inutilizzabile e un'impostazione per cui un cliente pagava senza avere una riga da cui accedervi. La centralizzazione ha eliminato questa categoria di bug.
I test che hanno adottato i framework centralizzati hanno notevolmente migliorato l'esperienza dei revisori delle richieste pull. Ad esempio, prendiamo il test di visibilità delle righe, che risponde alla domanda “Quali impostazioni vede effettivamente questo cliente?” domanda posta in precedenza. Invece del codice di test, uno scenario è costituito semplicemente da dati: una persona, uno stato del dominio e le pagine su cui viene visualizzato.
E una riga elenca semplicemente gli scenari denominati in cui deve apparire:
Non c'è alcuna chiamata di rendering né alcuna asserzione da scrivere. Una suite di test dinamica legge il catalogo e confronta ogni riga con ogni scenario in cui è menzionata. Il catalogo è ora l'unico luogo che indica ciò che un cliente vede, verificato dalla macchina. Non c'è più bisogno di fare affidamento su un revisore del codice scrupoloso o sull'autore per identificare e scrivere correttamente i propri casi di test.
Nel mondo dell'IA
Abbiamo avviato questo lavoro alla fine del 2025 perché avevamo previsto la necessità di consentire agli ingegneri non esperti di creare con sicurezza nella Console di amministrazione. All'epoca, l'obiettivo non era quello di ottimizzare le prestazioni degli LLM, ma, come si è scoperto, standardizzare e semplificare l'esperienza per gli ingegneri fa lo stesso per gli agenti di IA.
Prima di creare questi framework, abbiamo affidato all'IA il problema della migrazione, e tecnicamente ha funzionato. Il problema era che né l'agente né il revisore riuscivano a stabilire se i test fossero effettivamente corretti, il che comportava una falsa sicurezza e lacune nascoste. L'IA non risolve la mancanza di struttura, ma si limita a produrre più codice, più velocemente, sulla base di qualsiasi struttura già esistente. Google ha presentato un caso analogo per il sistema di tipi di Go nello sviluppo assistito dall'IA: i tipi statici fungono da rete di sicurezza automatizzata, poiché gli LLM sono inclini a generare proprietà inesistenti e tipi non corrispondenti tra i file. TypeScript non è staticamente rigoroso come Go, ma un framework può offrire la stessa garanzia: definire il tipo del controllo una sola volta a livello di framework, in modo che ogni implementazione debba adattarvisi al momento dell'utilizzo.
Una volta che i framework erano pronti, abbiamo iniziato a prepararci a delegare e a parallelizzare. Ho utilizzato il nostro nuovo strumento di sviluppo basato su specifiche [link placeholder: eng blog post on spec driven development: Asana Eng Blog - Spec-driven development: The Good Parts per creare una skill in grado di svolgere il lavoro dall'inizio alla fine. Codifica l'intera conversione: definisce il controllo, richiama l'hook, sostituisce i banner, aggiorna i frammenti, aggiunge i nuovi test dichiarativi, oltre a una checklist che si aggiorna automaticamente e a un registro dei casi limite delle conversioni precedenti. Su circa 150 migrazioni, il 91% non ha necessitato di alcuna revisione dopo la verifica.
Avviare un agente per scrivere una PR non richiede molto impegno, e nemmeno rivedere tale PR. Poiché tutto è dichiarato in modo prevedibile, i revisori non devono essere esperti in amministrazione per verificare se l'implementazione corrisponde alle specifiche del prodotto. È fondamentale sottolineare che questo apre il pool di revisori idonei a un gruppo molto più ampio di ingegneri, il che aumenta la velocità più di un semplice imbuto più ampio nella parte superiore che crea PR. Non siamo gli unici a ripensare il processo di revisione per questa epoca: GitHub ha ricostruito l'agente di revisione di Copilot basandolo su prove strutturate relative alle PR per aiutare i revisori umani a porre le domande giuste più rapidamente, riducendo i costi di revisione di circa il 20%.
La migrazione originale di circa 150 elementi che si estendevano su più framework è stata definita come un lavoro di ingegneria manuale e una tantum dall'inizio alla fine. Creando prima i framework e delegando poi la migrazione agli ingegneri che successivamente monitorano gli agenti, siamo riusciti a completare l'intero impegno con oltre un mese di anticipo rispetto a quanto previsto dal piano originale.
E adesso cosa succederà?
La creazione di questi framework non è mai stata un progetto di per sé. È nata per necessità, da una roadmap che doveva essere parallelizzata e scalata, con un personale limitato e variabile nel corso del tempo, e senza richiedere che ogni collaboratore fosse prima un esperto del settore. Abbiamo già visto che funziona anche al di fuori del team che l'ha creato: 18 dei 66 controlli attualmente presenti nel framework sono stati sviluppati da ingegneri di 8 team diversi.
Ora stiamo cercando il prossimo ambito in cui effettuare questo tipo di investimento. Semmai, le motivazioni sono più valide ora di quanto non fossero prima di iniziare: un framework dichiarativo ben progettato non solo semplifica la revisione, ma determina anche se un agente produce qualcosa di affidabile o semplicemente qualcosa di veloce. È anche ciò che potrebbe rendere plausibile la revisione autonoma: Cloudflare ha creato un sistema in cui un revisore basato sull'intelligenza artificiale approva il codice pulito e blocca autonomamente i problemi reali, e questo funziona solo perché i loro input sono strutturati in modo sufficiente da consentire al revisore di fidarsi. Se i nostri siano sufficientemente strutturati per provare a fare lo stesso è una buona domanda da porsi in futuro.
Informazioni sull'autore
Leo Zhang è un software engineer del team Admin Foundations, che aiuta gli amministratori IT a gestire le loro organizzazioni. Attualmente, sta migliorando l’esperienza di sviluppo di altri ingegneri di prodotto nella console di amministrazione, investendo nei framework tecnici che supportano il nostro prodotto.
Ringraziamenti al team
La progettazione, l'implementazione, il collaudo e la condivisione di queste modifiche sono stati il risultato di un enorme impegno da parte del team. Ciò è stato reso possibile grazie ai contributi di altri ingegneri del team Admin Foundations: Yunus Rahbar, Maryam Booshehrian, Saverio Castelli, Bronwyn Damm, Cindy Yu, Calvin Norton e Jaxsun McCarthy Huggan. Walter Li, del team Tiger per il successo degli agenti, ha contribuito moltissimo alla configurazione degli strumenti di IA giusti per queste migrazioni.
Riferimenti
Lan Cheng, Emerson Murphy-Hill, Mark Canning, Ciera Jaspan, Collin Green, Andrea Knight, Nan Zhang ed Elizabeth Kammer, "What Improves Developer Productivity at Google? Code Quality", ESEC/FSE '22, novembre 2022. https://doi.org/10.1145/3540250.3558940
"Orchestrating AI Code Review at Scale", Cloudflare Blog, aprile 2026. https://blog.cloudflare.com/ai-code-review/
Napalys Klicius, "Better tools made Copilot code review worse. Ecco come l'abbiamo effettivamente migliorata", The GitHub Blog, luglio 2026. https://github.blog/ai-and-ml/github-copilot/better-tools-made-copilot-code-review-worse-heres-how-we-actually-improved-it/
"Why Go is an Ideal Language for AI-Assisted Software Engineering", Blog di Google Developers, agosto 2026. https://developers.googleblog.com/why-go-is-an-ideal-language-for-ai-assisted-software-engineering/
