Negli ultimi due mesi abbiamo avuto l'opportunità di parlare con molti tecnici, ingegneri e manager di diverse grandi aziende tecnologiche grazie a Disrupt e ad altri eventi tecnologici su Bay Area. Molte persone del grande pubblico hanno familiarità con il termine generazione del codice sorgente e con il modo in cui il software viene solitamente costruito. Ma quando parliamo con i tecnici, in particolare con quelli che seguono lo sviluppo del software moderno, ci viene chiesto in che modo AppMaster differisce da GitHub Copilot. È una domanda piuttosto interessante.
Se state leggendo il mio post, probabilmente avrete sentito parlare di Copilot, uno strumento di intelligenza artificiale per il completamento e la generazione di codice sorgente avanzato. Copilot è già un ottimo strumento per la programmazione assistita quando lo sviluppatore scrive solo una parte del codice sorgente, mentre l'intelligenza artificiale offre il completamento del codice, anche di intere funzioni. Copilot è particolarmente bravo a completare schemi e dizionari: si scrivono un paio di elementi e il resto viene generato automaticamente. Secondo il feedback della comunità e i recenti messaggi del CEO di GitHub, Copilot sta crescendo a un buon ritmo.
A differenza di Copilot, AppMaster si concentra sulla generazione del progetto software completo, anziché dei singoli pezzi. AppMaster accumula i requisiti per l'intero progetto: applicazioni server (backend), applicazioni web, applicazioni mobili e tutto il resto. In generale, gli ingegneri raccolgono i modelli di dati, la logica dell'applicazione, gli endpoint, gli elementi dell'interfaccia utente e tutti i requisiti standard per la futura applicazione nel formato visuale drag-and-drop. L'approccio all-in-one consente agli ingegneri del software di fare meno cose per ottenere di più.
Per capire meglio, vi fornirò un piccolo esempio.
Effettuare una chiamata API dall'applicazione web o mobile al server/backend è uno dei compiti più comuni. Di solito, il tecnico deve consultare la documentazione dell'API del server e creare la struttura della richiesta/risposta e tutto il codice corrispondente. Lo stesso compito può essere svolto con un'azione di dran&drop in AppMaster. Poiché la piattaforma sa tutto sui modelli di dati e sugli endpoint, pre-genera automaticamente i blocchi visivi per effettuare richieste API indolori, compresa la struttura degli oggetti corrispondenti. E ancora di più: dopo ogni modifica dei modelli di dati, la logica di business o la piattaforma degli endpoint aggiornano automaticamente gli elementi dell'interfaccia utente dipendenti, senza l'intervento dell'ingegnere.
A prima vista sembra che AppMaster e Copilot stiano cercando di risolvere problemi diversi: stiamo lavorando allo stesso problema di ingegneria del software, ma i nostri approcci sono molto diversi. Mentre Copilot ha deciso di aiutare gli ingegneri del software a scrivere più codice in modo più semplice e veloce, noi ci siamo concentrati sullo spostamento del paradigma di sviluppo del software dalla creazione del software attraverso la scrittura del codice del programma alla semplice definizione dei requisiti di alto livello. Avere i requisiti ci offre l'enorme vantaggio di poter rigenerare da zero l'intera base di codice del progetto. Possiamo farlo per qualsiasi motivo: quando i requisiti vengono modificati, quando sono disponibili algoritmi di generazione del codice migliori, per aggiornare le versioni del linguaggio di programmazione o delle librerie, o anche per cambiare l'intero stack tecnologico!
Crediamo nel futuro con l'approccio"Non toccare il codice sorgente" e con requisiti di alto livello per l'ingegneria del software.
Cosa ne pensate? Troppo bello per essere vero? Utopia?
P.S. Se siete interessati al settore, date un'occhiata all'ultimo podcast di Lex Fridman con Andrei Karpathy, ex-direttore dell'IA di Tesla, sul Software 2.0 e la generazione di codice.
