L'AI che costruisce la vostra applicazione senza scrivere codice
Scrivere codice è diventato economico. Mantenerlo no.
Oggi un'AI scrive in pochi minuti il codice che prima richiedeva una settimana. Noi la usiamo ogni giorno e non torneremmo indietro. Ma un'applicazione gestionale non si scrive una volta sola: viene modificata per dieci o quindici anni, da persone che non c'erano quando è stata scritta. Ogni riga generata per una nuova funzione è una riga che qualcuno dovrà capire prima di poterla toccare in sicurezza. E quando ogni funzione è risolta in modo un po' diverso, i programmi si allontanano l'uno dall'altro e ogni modifica costa più della precedente.
La velocità di scrittura non è mai stata il vero costo del software gestionale. Il vero costo è ciò che serve per modificarlo in sicurezza più avanti.
Un sistema di gestione per le applicazioni
Nessuno terrebbe la contabilità di un'azienda a mano, con ogni registrazione scritta in modo un po' diverso da chi si trovava alla scrivania. La contabilità vive in un sistema che sa che cos'è una registrazione, la controlla rispetto a delle regole, e sa dirvi che cosa tocca una modifica.
La definizione di un'applicazione non è poi così diversa dai dati contabili. Sono regole, e l'applicazione di regole: quali dati mostra una pagina e chi può vederli, che cosa fa un pulsante e a quali condizioni, quali cifre riporta una stampa. Nella maggior parte del software queste regole sono sparse nel codice. In GTmeta sono dati, e la Suite li conserva come un sistema di gestione conserva la contabilità: li registra, li controlla e vi dice che cosa dipende da che cosa. La Suite è, in pratica, il sistema di gestione delle vostre applicazioni.
Un solo motore disegna ogni applicazione
Pagine, schede e griglie, l'SQL che eseguono, le azioni dietro ogni pulsante, i menu e le stampe: tutto è una descrizione, e un solo motore legge quella descrizione e disegna l'applicazione. Il motore è lo stesso per ogni progetto; ciò che cambia da un'applicazione all'altra è soltanto la descrizione.
È anche per questo che un'AI può costruire un'applicazione GTmeta senza scrivere codice. Scrive la stessa descrizione che una persona scrive nel Designer, con gli stessi elementi di base. Una pagina costruita dall'AI si apre, si legge e si modifica nel Designer esattamente come una pagina costruita a mano.
Nota tecnica: il vocabolario è chiuso. L'AI compone le pagine con gli elementi di base che la piattaforma ha già; non aggiunge nuovi meccanismi al motore. È questo confine che rende il suo lavoro verificabile.
Tre punti in cui il software gestionale di solito fa male
La maggior parte delle modifiche che un'applicazione gestionale riceve durante la sua vita cade negli stessi tre punti. GTmeta tiene ciascuno di essi in un solo posto, in piena vista.
Il legame tra programmi e dati
Ogni istruzione SQL di un'applicazione vive in un unico repository, con un identificativo, la connessione su cui viene eseguita e i suoi parametri dichiarati. Pagine e stampe non scrivono SQL al loro interno: puntano a un'istruzione tramite il suo identificativo. Quando una tabella cambia, alla domanda «che cosa tocca?» si risponde cercando quali istruzioni la usano e quali pagine e stampe puntano a quelle istruzioni, non frugando nel codice.
Il repository è anche il punto in cui viene fatto rispettare l'accesso ai dati. Un parametro che limita ciò che un utente può vedere viene compilato dal server a partire dal profilo di quell'utente, mai dalla pagina, quindi nessuna schermata può chiedere più di quanto il suo utente sia autorizzato a leggere.
Le stampe e i dati che ci stanno dietro
Le stampe prendono i dati da istruzioni dello stesso repository, e i parametri che una stampa riceve sono quelli dichiarati su quelle istruzioni. Cambiare ciò che una stampa mostra, o ciò che deve passare la pagina da cui si stampa, è una modifica a definizioni che chiunque può leggere. Le stesse restrizioni utente valgono per le query di una stampa come per la pagina.
Che cosa succede quando cliccate un pulsante
Dietro ogni pulsante c'è un elenco ordinato di azioni: carica questi dati, controlla queste condizioni, salva, richiama questa procedura, apri quest'altra pagina. Ogni passo ha un tipo, e le condizioni decidono se viene eseguito. Per sapere che cosa fa un pulsante si legge il suo elenco nel Designer, dall'alto in basso. Niente è nascosto in un gestore di eventi scritto anni fa da qualcun altro.
Dove entra l'AI
È il principio alla base della progettazione assistita dall'AI che stiamo costruendo per il Designer (si veda la roadmap). Voi descrivete una pagina; l'assistente la costruisce in un'area di preparazione del Designer, e un validatore controlla che ogni riferimento si risolva: ogni dataset punta a un'istruzione che esiste, ogni pulsante ad azioni che esistono. Voi rivedete il risultato e lo confermate, oppure lo scartate. L'AI non tocca il vostro progetto finché non lo fate voi, e ciò che lascia dietro di sé è una descrizione che il vostro team sa leggere, non codice che qualcuno deve decifrare.
Gli impegni che ci prendiamo
- Un solo motore per ogni applicazione. Una modifica al motore viene messa alla prova da ogni pagina di ogni progetto.
- Un vocabolario ridotto. Ogni nuovo meccanismo deve guadagnarsi il suo posto, perché chiunque mantenga un'applicazione deve impararlo.
- Prima la descrizione, il codice per ultimo. Quando una cosa si può fare con gli elementi di base che la piattaforma ha già, si fa così, che a farla sia una persona o un'AI.
- Ogni modifica leggibile dalla persona che viene dopo. Un'applicazione deve poter essere compresa da qualcuno che non c'era quando è stata costruita.