Cicero, JIC e agenti AI: l’infrastruttura produttiva alla base di un nuovo modo di progettare, sviluppare e far evolvere applicazioni.
Approfondimento di ingegneria — Avanguardia Digitale
La domanda da cui è cominciato tutto
Nel 2016 i boilerplate e i generatori di codice promettevano di accelerare l’avvio di un’applicazione. Predisponevano progetti, modelli e strutture ripetitive; poi, però, la loro utilità spesso finiva proprio dove cominciava il lavoro vero.
Bastava aggiungere un campo a un’entità, cambiarne una relazione o modificare il comportamento di un form perché lo sviluppatore dovesse scegliere: rigenerare tutto, rischiando di perdere personalizzazioni, oppure aggiornare manualmente backend, database, API e frontend.
Il problema non era soltanto il tempo che separava un’idea dal primo software utilizzabile. Era il costo di continuare a evolverlo.
Da questa osservazione nacque Where The Magic Happens, un primo programma CLI capace di trasformare schemi JSON in codice applicativo. Aveva un perimetro ristretto, ma un principio ambizioso: la generazione non doveva essere un evento iniziale; doveva restare parte del ciclo di vita del software.
Negli anni successivi arrivarono la generazione delle interfacce, l’esperienza con grandi piattaforme applicative come ServiceNow e SAP, e infine gli agenti AI. Quel progetto si è evoluto in Cicero. Accanto a esso è nato JIC, il sistema che organizza il lavoro operativo necessario a costruire, verificare e distribuire ciò che Cicero genera.
Il punto di partenza non è una schermata. È il dominio.
Un’applicazione non è soltanto un insieme di tabelle e pulsanti. È una rappresentazione parziale di un’attività reale: persone, informazioni, relazioni, regole, eccezioni, autorizzazioni e operazioni.
Cicero parte da questa rappresentazione. Il suo modello comprende entità, Business Rule, controlli di accesso, UI Policies, Client Scripts, handler backend, composable frontend, query GraphQL nominate, viste, pagine, migrazioni e seed.
Il framework utilizza DSL, schemi e package per trasformare il modello in componenti applicativi: backend, API, tipi, interfacce e infrastruttura. Le definizioni di pagine e viste possono anche essere memorizzate nel database e modificate a runtime, attraverso renderer e layout dichiarativi distribuiti dai package.
Non tutto deve rientrare nel percorso standard. Handler, composable, query nominate e meccanismi di injection permettono di intervenire sulle parti specifiche di un’applicazione e di integrarle con ciò che viene generato.
Lo scopo non è eliminare le scelte progettuali, ma ridurre il costo di implementarle.
Pensa a una biblioteca. È facile rappresentare un libro con un campo isbn. È più lungimirante modellare gli standard di identificazione come dati amministrabili, con regole di verifica che possano evolvere senza richiedere un rilascio per ogni nuova variante. Quest’ultima soluzione è più ricca, ma nello sviluppo tradizionale comporta molto più lavoro. Se il telaio applicativo viene generato, diventa possibile investire più attenzione nella profondità del modello anziché ripetere continuamente le stesse implementazioni.
- 1. Modello e packageDati, regole, accessi, operazioni e comportamenti riutilizzabili.
- 2. Generazione con CiceroIl modello diventa un telaio applicativo estensibile.
- 3. Backend, interfacce e toolingComponenti generati e logiche specifiche, da integrare e verificare.
Le estensioni previste e le verifiche accompagnano la rigenerazione. Migrazioni semantiche e compatibilità richiedono decisioni esplicite.
Cicero stampa il telaio. I package costruiscono l’applicazione.
L’analogia è quella di una fabbrica: un sistema produttivo complesso viene progettato una volta per rendere meno onerosa la produzione delle singole unità.
Cicero genera il telaio di un’applicazione a partire da un modello. Il telaio, da solo, non basta. I package aggiungono capacità e comportamenti, dalle funzioni di sistema alle interfacce specifiche, consentendo di comporre prodotti differenti su fondamenta comuni.
Il package core costituisce il nucleo di servizi e concetti riutilizzabili. L’esperienza di adozione desiderata è semplice: installare Cicero in locale, avviare un’applicazione essenziale, esplorare utenti, ruoli, gruppi, file e audit log; poi aggiungere package esistenti o crearne di nuovi. Questa è la direzione dell’onboarding che vogliamo rendere accessibile a sviluppatori esterni, non una promessa che ogni passaggio sia già disponibile in una distribuzione pubblica.
La conseguenza più importante è architetturale: il codice risultante resta nelle mani di chi sviluppa. Cicero non pretende che ogni personalizzazione passi per un unico editor chiuso.
Generare, modificare, rigenerare
Un’applicazione reale non rimane uguale a se stessa. Per questo Cicero mantiene le sorgenti dichiarative come parte del processo anche dopo la prima versione.
Quando cambia un modello, il framework può rigenerare entità, DTO, resolver, tipi, descriptor e componenti frontend. Ma qui c’è un compromesso dichiarato: i file generati possono essere riscritti. Le modifiche manuali fatte dentro quei file non godono di una protezione universale.
La personalizzazione durevole deve quindi risiedere nelle superfici previste — override, sorgenti inject/, asset e moduli specifici — oppure essere governata mediante integrazione Git. Il processo adotta anche un modello vendor-branch: gli aggiornamenti del framework passano da un ramo dist, quelli dei package da rami dedicati, mentre le modifiche al codice distribuito vengono riconciliate attraverso merge e verifiche.
Migrazioni database e modifiche al modello sono operazioni distinte. Aggiungere una regola non corregge da solo i dati storici; cambiare una relazione può richiedere una migrazione semantica. I conflitti che dipendono dal significato dei dati non vengono risolti automaticamente da Cicero.
La generazione continua è una capacità reale. La compatibilità universale automatica, oggi, non è una sua garanzia.
JIC: la fabbrica ha bisogno anche di un sistema operativo
Quando più agenti e più progetti lavorano contemporaneamente, generare codice non è sufficiente. Occorre sapere quali sorgenti si stanno modificando, con quali risorse, quale versione è stata testata, quali effetti sono autorizzati e che cosa rimane da fare dopo un errore.
È qui che entra JIC.
JIC è uno strumento CLI che fornisce il substrato operativo, non il coordinatore degli agenti: gestisce sessioni, repository e worktree isolati, profili e capability, ambienti, build, test, deploy, risorse e stato persistente delle operazioni.
Una sessione può partire dalle sole sorgenti e acquisire progressivamente ciò che serve: target Cicero generato, runtime locale, componenti necessari ai test. I profili risolvono le dipendenze tra capability; gli hook collegano i passaggi del lifecycle alle procedure specifiche del progetto.
Il sistema conserva informazioni su ownership, risorse, revisioni, stato e risultati. Può rilevare che una capability è diventata STALE perché le sorgenti sono cambiate dopo la sua preparazione. Può distinguere un risultato integrato da un cleanup ancora pendente. Può organizzare recuperi e rimozioni senza trattare ogni risorsa come se fosse liberamente cancellabile.
Questo non dimostra che il software funzioni correttamente. Dimostra qualcosa di diverso, ma indispensabile: che il processo sappia conservare e verificare le proprie precondizioni operative.
Chi dirige gli agenti?
Non JIC.
Gli obiettivi e le autorizzazioni appartengono alle persone responsabili del prodotto. Un coordinatore — umano e/o supportato da agenti — interpreta la richiesta, stabilisce contratti condivisi, scompone il lavoro, definisce dipendenze e valuta le evidenze. Gli strumenti di gestione degli agenti ne governano avvio, messaggi e risultati. Gli specialisti affrontano incarichi delimitati.
JIC mette a disposizione ambienti ed esecuzioni tracciabili. Cicero mette a disposizione il linguaggio applicativo e i generatori. Gli agenti lavorano attraverso questi strumenti, usando documentazione strutturata, runbook, recipe e caveat per preservare conoscenza e ridurre le decisioni improvvisate.
L’autonomia non nasce dall’assenza di vincoli. Nasce dal sapere entro quali vincoli è possibile agire.
Le istruzioni scritte non sostituiscono controlli eseguibili; una verifica automatica non sostituisce una valutazione del comportamento. Quando un problema supera le autorizzazioni o richiede una decisione di prodotto, il processo deve renderlo visibile invece di forzare.
- 1. Persone ownerDefiniscono obiettivi, autorizzazioni e criteri di accettazione.
- 2. Coordinatore e strumenti di gestione agentiIl coordinatore definisce contratti e incarichi; gli strumenti gestiscono avvio, messaggi e risultati degli agenti.
- 3. SpecialistiImplementano incarichi delimitati e restituiscono evidenze da integrare e valutare.
Cicero: modello applicativo, generatori, package ed estensioni.
JIC: ambienti isolati, risorse, esecuzioni e stato operativo. Non sceglie né avvia autonomamente gli agenti.
La prova: applicazioni vere, non una demo di laboratorio
Cicero è già stato utilizzato per realizzare cinque applicazioni in produzione, in domini diversi: JoyInCloud (Hair & Beauty), StayFit (personal trainer), EatFresh (dietisti), InnovaSemplice (processi HR) e Recoserv (urban mining e RAEE).
Le applicazioni appartengono a contesti con committenti e diritti distinti; la loro presenza in questo racconto non attribuisce al marchio Avanguardia Digitale tutti gli incarichi originari.
JoyInCloud è il caso più documentato: per il committente Media Marketing S.r.l., il professionista oggi alla guida di Avanguardia Digitale ha curato la reingegnerizzazione completa di una piattaforma già ideata dal cliente. La prima release utilizzabile in produzione è arrivata dopo 4,5 mesi dall’avvio dei lavori; i saloni hanno cominciato a utilizzarla dopo 7 mesi. La migrazione dei dati storici si è conclusa senza perdita di dati. Oggi il prodotto serve oltre 60 saloni e censisce circa 15.000 clienti finali unici.
La revisione architetturale ha inoltre permesso una riduzione del 92,8% dei canoni infrastrutturali confrontati, dato confermato con il committente. Non è una riduzione certificata dell’intero costo operativo e non misura, da sola, la capacità futura di scalare.
La visione del prodotto apparteneva a Media Marketing. Il contributo ingegneristico è consistito nel renderla utilizzabile, manutenibile ed economicamente più sostenibile.
Quando un pezzo della fabbrica si rompe
Il 15 ottobre 2026, un intervento sulla lista d’attesa della prenotazione online di JoyInCloud ha attraversato modello di dominio, backend generato, webapp consumer, sincronizzazione e sistemi legacy.
Tre specialisti AI hanno lavorato inizialmente su backend/package, integrazione e frontend, sotto il coordinamento di contratti comuni. Dopo il crash dell’applicazione di chat, il lavoro persistito nei worktree è stato recuperato e tre nuove istanze hanno ripreso gli stessi ambiti: non sei agenti contemporanei, ma due fasi successive.
Sono emersi un problema di accesso Git, un difetto nel lifecycle di JIC e un problema del daemon Docker. Alcune correzioni sono state automatiche o circoscritte; altre hanno richiesto intervento umano e nuove autorizzazioni. Il lavoro è stato comunque integrato, con 398 test superati e uno saltato, oltre alle build, e con il deployment documentato di quattro componenti del nuovo sistema.
La delivery ha verificato migrazioni, rollout e corrispondenza degli artifact distribuiti. Non equivaleva però a un collaudo end-to-end completo del percorso tra nuovo sistema e legacy: alcune verifiche integrate e il rilascio del sistema precedente erano ancora distinti alla chiusura documentata dell’intervento.
Il punto non è che nulla si sia rotto. È che lo stato del lavoro, le verifiche e i limiti della consegna sono rimasti distinguibili e recuperabili.
Leggi l’approfondimento tecnico sulla delivery AI-native.
Dalla fabbrica personale a un ecosistema aperto
L’ambizione di Cicero non si esaurisce nella produttività di chi lo ha progettato.
Vogliamo che altri sviluppatori possano installarlo, studiarlo, creare package, estenderli e condividerli. Nel lungo periodo immaginiamo un ecosistema in cui persone e aziende possano anche distribuire e commercializzare package e applicazioni complete, mantenendo libertà di intervento sul codice.
Esiste inoltre l’idea di “Cicero in cloud”: un servizio nel quale avviare un’istanza applicativa e disporre di strumenti per modificarla e distribuirla. È un progetto futuro, non ancora iniziato: non è un prodotto disponibile o una beta attiva, e non ha una data di rilascio garantita.
Anche licenze, regole di distribuzione e governance dell’ecosistema richiederanno decisioni esplicite prima di promettere un modello open source o commerciale già definito.
Una fabbrica che deve poter andare oltre il suo fondatore
La direzione è più grande di due strumenti.
L’obiettivo di Avanguardia Digitale è costruire un’organizzazione nella quale comprendere un problema, progettare un sistema, guidarne l’implementazione e verificarne il risultato diventi un patrimonio condiviso, non una competenza impossibile da trasferire.
Cicero rende più economica la produzione del telaio applicativo. JIC rende osservabili e ripetibili le operazioni. Gli agenti possono svolgere una parte sostanziale dell’esecuzione. Le persone continuano a definire il valore da creare, le responsabilità e i criteri con cui giudicare il risultato.
Non vogliamo semplicemente costruire più software. Vogliamo rendere possibile costruire software migliore, con un processo che possa crescere oltre chi l’ha inventato.
Avanguardia Digitale — Esploriamo il futuro. Costruiamo ciò che serve oggi.