Guida

AI e sviluppo AL per Business Central

Oggi l'AI può scrivere buona parte di un'extension per Business Central. Che questo faccia risparmiare tempo o crei lavoro dipende meno dal modello che da ciò che gli sta intorno. Questa guida spiega cosa comporta lo sviluppo AL, dove l'AI aiuta, dove sbaglia e quali garanzie rendono il suo codice sicuro da installare.

Aggiornata a ottobre 2026

Cosa comporta lo sviluppo AL

Business Central si personalizza con extension scritte in AL, il suo linguaggio di programmazione. Un'extension non modifica mai l'applicazione base di Microsoft: aggiunge tabelle e pagine, estende quelle esistenti con table extension e page extension, e reagisce a ciò che fa l'applicazione sottoscrivendo i suoi eventi. Gli sviluppatori scrivono AL in Visual Studio Code con l'estensione AL Language e lo compilano sui simboli della versione di Business Central su cui girerà.

Il risultato è un file .app. Un'extension per-tenant è costruita per una sola azienda e installata nel suo ambiente; un'app AppSource è pubblicata per tutti i clienti e deve superare la validazione di Microsoft. In entrambi i casi l'extension deve compilare sulla versione giusta, rispettare il suo intervallo di ID oggetto e le regole di denominazione, ed essere provata in una sandbox prima di arrivare in produzione.

Dove l'AI aiuta

La parte ripetitiva dello sviluppo AL è ampia, ed è lì che un modello è più veloce:

  • Trasformare un requisito scritto in linguaggio di business in una specifica strutturata, chiedendo ciò che manca.
  • Scrivere gli oggetti che servono a una funzione: tabelle, table e page extension, pagine, report, codeunit e sottoscrizioni a eventi.
  • Applicare la stessa denominazione, la stessa struttura e gli stessi pattern a ogni oggetto, ogni volta.
  • Produrre i file di traduzione (XLIFF) per le lingue in cui lavorano i tuoi utenti.
  • Controllare il codice rispetto a un elenco scritto di regole di sviluppo, spiegando ogni rilievo.

Dove l'AI sbaglia

Un modello linguistico scrive AL plausibile, e plausibile non vuol dire corretto. Gli errori tipici sono propri di Business Central: un evento che nella tua versione non esiste, un campo che è stato rinominato, un ID oggetto fuori dal tuo intervallo, un permission set mai aggiornato, un layout di report che usa una colonna che il dataset non ha.

Nessuno di questi errori si vede leggendo il codice. Emergono quando l'extension viene compilata sui simboli reali o, peggio, quando un utente la usa. Per questo l'AL scritto dall'AI richiede gli stessi controlli del codice di uno sviluppatore appena arrivato, applicati ogni volta e senza eccezioni.

Le garanzie che lo fanno funzionare

Ciò che trasforma l'AL scritto dall'AI in codice installabile è il processo che gli sta intorno:

  • Compilare sui simboli della versione di destinazione, e ripetere finché non passa: il codice che non compila non arriva mai a un revisore.
  • Scrivere una volta le proprie regole di sviluppo e controllare ogni modifica rispetto a quelle.
  • Far approvare il piano a una persona prima di iniziare, e un rilascio in produzione a due persone diverse.
  • Anonimizzare i documenti dei clienti prima che un modello li legga: nomi, cifre e indirizzi diventano segnaposto.
  • Tenere un registro di ogni decisione che non si possa riscrivere dopo, per mostrare al cliente cosa è stato fatto e chi lo ha approvato.

Dalla richiesta all'.app: un flusso supervisionato

In Agentic Company il lavoro segue la strada che segue un buon team. Un agente analista legge la richiesta anonimizzata e chiede ciò che non è chiaro. Un pianificatore divide il lavoro in unità con le loro dipendenze, e una persona approva il piano. Gli agenti sviluppatori costruiscono in parallelo le unità indipendenti, gli agenti revisori controllano ciascuna rispetto alle tue regole, e il compilatore AL gira finché il codice non compila.

Il risultato è un file .app da provare in sandbox e, se usi Azure DevOps, una pull request con il sorgente. Ogni passo che esce dalla piattaforma, da un branch a un rilascio, passa da un gateway che applica le tue regole e chiede la firma alle persone giuste.

Un assistente nell'editor o un team di agenti supervisionato?

Un assistente di programmazione in Visual Studio Code, come GitHub Copilot, aiuta uno sviluppatore che sta già scrivendo AL: completa il codice e risponde alle domande, e lo sviluppatore resta responsabile di tutto il resto.

Una piattaforma multi-agente supervisionata porta una richiesta dall'analisi all'.app compilato, con approvazioni e un registro di audit intorno. È adatta a un partner Microsoft che vuole più capacità con lo stesso team, e a un'azienda con Business Central che ha bisogno di un'extension senza assumere sviluppatori. Le due cose non si escludono: gli sviluppatori possono tenere il loro assistente mentre la piattaforma gestisce i volumi.

Domande frequenti

L'AI può scrivere un'extension completa per Business Central?

Per molte personalizzazioni comuni sì: report, campi, pagine, validazioni, integrazioni ed elaborazioni batch. Funziona meglio con un requisito chiaro, un compilatore nel ciclo e una persona che approva il piano e il rilascio.

Il codice AL generato dall'AI è sicuro da installare?

Solo dopo che ha compilato sulla tua versione di Business Central, ha superato la revisione rispetto alle tue regole di sviluppo ed è stato provato in una sandbox. Va trattato come qualsiasi altro codice non ancora revisionato.

Il modello AI vede i dati dei miei clienti?

In Agentic Company no: requisiti e linee guida vengono anonimizzati con il tuo dizionario prima che un modello li legga, e il modello lavora su segnaposto.

Devo conoscere AL per usarlo?

No. Un'azienda può descrivere ciò che le serve in termini di business; gli sviluppatori di un partner possono controllare il piano e il codice nel dettaglio che vogliono.

Guardalo lavorare su una richiesta vera

Apri la demo dal vivo, oppure guarda le personalizzazioni che le aziende chiedono più spesso e cosa costruiscono gli agenti per ciascuna.