La tua prossima funzionalità software aziendale non sarà spedita. Sarà generata.

      TL;DRIl software aziendale sta per affrontare un cambiamento in cui gli assistenti AI generano funzionalità su richiesta anziché spedirle attraverso i backlog di prodotto. Invece di presentare una richiesta e aspettare mesi, un utente descrive ciò di cui ha bisogno e il sistema genera un piccolo programma per farlo. L'articolo esplora cosa significa questo per i team di prodotto, la sicurezza, la governance e la definizione stessa di 'funzionalità'.

      Il backlog delle funzionalità aziendali è dove le buone richieste degli utenti vanno ad aspettare. Quella attesa sta per diventare molto più breve, non perché i team di prodotto siano diventati più veloci, ma perché la funzionalità mancante può ora essere generata al momento della richiesta e scartata trenta secondi dopo.

      Un responsabile del supporto apre la sua applicazione di helpdesk e chiede:

      “Mostrami ogni ticket di questo mese che è stato risolto e poi riaperto entro 48 ore, raggruppato per l'agente che lo ha chiuso per primo.”

      Nessun report fa questo. Nessuna combinazione di filtri può esprimerlo. Nessun tile del dashboard esiste.

      Qualche anno fa, questo sarebbe diventato un ticket per il team di prodotto, registrato, prioritizzato e spesso consegnato in ritardo o non consegnato affatto. Più recentemente, un assistente AI potrebbe aver recuperato un articolo di conoscenza che spiegava come esportare i dati dei ticket e analizzarli in un foglio di calcolo.

      Ora c'è una terza possibilità. L'assistente genera un piccolo programma per esattamente questa richiesta. Il programma scansiona i registri dei ticket, incrocia ogni evento di risoluzione con le successive riaperture, verifica se il gap era inferiore a 48 ore e restituisce un riepilogo raggruppato. Il modello riceve quella tabella e spiega il modello.

      Il team di prodotto non ha mai costruito il report. L'utente non ha mai scritto codice. Per un compito, la funzionalità mancante esisteva esattamente dove era necessaria.

      Questo non è un recupero migliore. È l'inizio del contesto programmabile.

      Il recupero seleziona prove. Il codice calcola nuove prove.

      RAG ha risolto un problema genuino: gli utenti potevano porre domande in linguaggio naturale e ottenere risposte basate su fonti che l'interfaccia non aveva mai mostrato. Ma il recupero seleziona da prove che già esistono, un documento, un passaggio, una riga.

      Molte domande aziendali non sono risposte da alcun artefatto esistente. Sono risposte da una procedura: filtrare, unire, calcolare e riassumere attraverso le fonti.

      Quali ticket sono stati riaperti solo dopo essere stati trasferiti a un team diverso? Quali report di spesa superano la media del dipartimento di oltre la metà? Quali distribuzioni sono fallite questa settimana che hanno anche fallito la settimana scorsa, e cosa è cambiato nel mezzo?

      Un team di prodotto può pre-costruire le procedure comuni. Non può anticiparle tutte.

      Questo è il divario che il contesto programmabile chiude. Il modello traduce l'intento di un utente in un programma temporaneo. L'applicazione lo esegue contro capacità approvate e inserisce solo il risultato calcolato nella finestra di contesto. Questo non è un interprete di codice di uso generale con accesso all'intero linguaggio, l'applicazione definisce esattamente quali operazioni il codice generato può chiamare. Il codice può vivere per una singola richiesta, generato, eseguito, registrato, scartato.

      Gli utenti decideranno cosa vede effettivamente l'AI.

      Ogni modello AI ha una memoria di lavoro limitata, la finestra di contesto, che determina su cosa può ragionare per ogni richiesta. Gestire quella finestra è stato un lavoro invisibile di proprietà dei team di piattaforma. Questo rimane critico. Ma un cambiamento più ampio sta diventando possibile: gli utenti definiscono cosa entra nel contesto descrivendo il calcolo di cui hanno bisogno.

      “Mostrami i ticket risolti in cui il cliente ha risposto entro un giorno, quali sono gli argomenti comuni?” “Confronta il tempo di prima risposta per agente questo mese rispetto al mese scorso e segnala chi è diventato più lento.” “Trova i report di spesa inviati nell'ultimo giorno del trimestre, raggruppati per approvatore.”

      Ogni richiesta è una funzionalità temporanea. Il programma generato calcola un artefatto a forma di risposta, e solo quell'artefatto entra nel contesto. Questa è personalizzazione del contesto per intento, non per tuning del prompt.

      Dove viene effettivamente eseguito il codice generato?

      Se un modello può generare un programma affidabile, qualcosa deve comunque eseguirlo. Le sandbox lato server sono la scelta ovvia per calcoli pesanti e unioni tra sistemi. Ma c'è un runtime che la maggior parte degli utenti aziendali ha già aperto: il browser.

      Ogni applicazione web aziendale fornisce un motore JavaScript a ogni utente che effettua il login. Quel motore può eseguire codice generato senza un servizio backend separato, un passaggio di distribuzione o una richiesta di infrastruttura. L'utente non installa nulla né cambia strumenti, il calcolo avviene all'interno del prodotto che sta già utilizzando.

      L'esecuzione lato client porta anche un importante vantaggio architettonico: la sessione del browser rappresenta già l'utente connesso.

      Supponiamo che l'applicazione di helpdesk dia a JavaScript generato un'interfaccia ristretta, listTickets, getTicketTimeline, getAgentStats. Ogni chiamata viaggia verso il backend utilizzando l'identità delegata dell'utente corrente. Le stesse regole basate su ruolo e livello di registrazione che governano gli schermi dell'applicazione governano il calcolo generato. Non è necessario alcun account di servizio separato con accesso più ampio.

      Questo evita un problema ricorrente dell'architettura degli agenti: un'identità centrale che può vedere più della persona che pone la domanda. Il programma recupera solo i registri a cui l'utente corrente ha diritto di accesso, li elabora localmente e invia un risultato compatto al modello, riducendo sia l'uso del contesto che il movimento di dati non necessario.

      L'esecuzione lato client diventa una strategia di ingegneria del contesto: calcolare vicino all'utente, sotto l'identità dell'utente, e fornire al modello prove a forma di risposta piuttosto che registri grezzi.

      L'identità è necessaria ma non sufficiente.

      Esiste una versione pericolosa di questa idea: generare JavaScript ed eseguirlo con eval() all'interno della pagina principale dell'applicazione, dandogli accesso completo al DOM, allo storage del browser, ai punti di scrittura e alla rete in uscita.

      Esiste un percorso più sicuro nel linguaggio. Il nuovo costruttore Function() compila una stringa in una funzione che non può catturare le variabili locali dello scope chiamante, ma viene comunque eseguita nello scope globale a meno che non venga ulteriormente contenuta. Combinato con un iframe o un worker sandboxed, diventa un confine di esecuzione pratico in cui l'applicazione fornisce alla funzione generata solo le capacità che sceglie.

      Eseguire sul client non rende l'autorizzazione automatica. Il browser fornisce l'identità; il server deve comunque autorizzare ogni richiesta API.

      Un design credibile fornisce capacità al codice generato, non credenziali. Viene eseguito in un worker isolato, in un frame sandboxed o in un runtime vincolato, senza accesso illimitato al documento, ai cookie, alla rete o al filesystem. L'applicazione espone un piccolo insieme di operazioni tipizzate e auditabili. Le letture sono predefinite. Le scritture richiedono una concessione separata e, per azioni consequenziali, una conferma esplicita.

      Il runtime ha bisogno di limiti sul tempo di esecuzione, sulla memoria, sulla dimensione del risultato e sul conteggio delle chiamate API. Ogni esecuzione dovrebbe registrare il programma generato, l'identità richiedente, le capacità invocate e la provenienza dei dati.

      Un altro confine è importante e facile da perdere: il permesso di visualizzare un record non implica il permesso di inviarlo a qualsiasi endpoint del modello. Prima che un risultato calcolato entri nella finestra di contesto, l'applicazione deve applicare le proprie politiche di gestione dei dati e idoneità al modello.

      Il principio è semplice: lascia che il codice generato calcoli. Non lasciarlo mai scappare.

      Dai cataloghi delle funzionalità agli ambienti di calcolo.

      JavaScript lato client e compet