La documentazione, organizzata per come la userai davvero.

Non partite da qui. Le pagine di questa sezione spiegano come funzionano i componenti, che è una domanda diversa da cosa cambia per la mia azienda.

Il percorso più breve è: una pagina settoriale vicina al vostro contesto, che racconta uno scenario completo in linguaggio non tecnico; poi la pagina della soluzione corrispondente al tipo di problema; e solo dopo, se serve il dettaglio, tornate qui.

Chi salta questo ordine finisce per valutare una tecnologia invece di valutare una risposta a un problema, e sono due esercizi diversi che portano a decisioni diverse.

L'ordine che ha più senso è: backend interpretato per primo, perché è lì che si capisce cosa significa descrivere un dominio invece di scriverlo; poi interfacce generate, che è la conseguenza più visibile; poi orchestrazione, che è dove sta la parte interessante per chi deve valutare l'uso dell'AI.

Gli strumenti dell'ecosistema — gestione dei progetti, microservizi, generazione di configurazione — hanno senso dopo, perché rispondono a esigenze che emergono quando il modello di base è chiaro.

Le guide su deploy e architetture sono utili a chi deve rispondere alle domande dell'area sistemi informativi, che arrivano sempre nei primi dieci minuti di ogni valutazione seria.

Queste pagine descrivono cosa fa ogni componente e quali capacità mette a disposizione, non come si scrive riga per riga una configurazione. È una scelta: la documentazione operativa cambia con le versioni e viene condivisa con chi avvia un progetto o entra nel programma partner, insieme all'affiancamento iniziale.

Il motivo non è tenere informazioni chiuse, ma che il modo più veloce per imparare a lavorare in modo dichiarativo è farlo su un caso reale con qualcuno accanto. Chi prova a impararlo da solo tende ad applicare abitudini dello sviluppo tradizionale e a costruire configurazioni che funzionano ma non si mantengono.