Confronti e approccio

Approfondimenti

Tre confronti con altri modi di costruire software con l’AI, poi come si costruisce una piattaforma, dal brief all’app.

01 · Confronto

Codice o no-code

Per chi valuta come costruire un’app con l’AI: che cosa cambia fra generarla da un prompt su una piattaforma e costruirla con un processo controllato, e quando conviene la prima strada.

Qui «piattaforma no-code» indica le piattaforme che generano un’app da un prompt, per esempio Base44. Il confronto riguarda la categoria, non un prodotto.

Due flussi, fianco a fianco

Piattaforma da prompt

Idea
Prompt: un messaggio in chat
Il modello genera: interfaccia e backend
App nella piattaforma: anteprima, ospitata lì
Pubblicazione: sull’hosting della piattaforma

Il metodo

Richiesta: brief o richiesta
Requisito: confermato da una persona
Impatto: file e test toccati
Agenti: costruiscono dentro i test
Cancello: cricchetto e CI
Persona: verdetto sul rilascio
Rilascio: va in produzione
Sonde: rigiocano la produzione

Cinque assi

Asse	Piattaforma da prompt	Il metodo
Impostazione	Un prompt descrive l’app, un modello genera interfaccia e backend dentro la piattaforma. La complessità resta dietro la chat.	Un sistema di controllo: il brief scritto fissa il problema, gli agenti eseguono, una persona fa da controllore. Niente esce senza la verifica del comportamento. Il metodo adatta alcune pratiche del software safety-critical (requisiti numerati, ogni requisito provato da un test, analisi d’impatto prima di ogni modifica) senza le loro garanzie formali.
Qualità fra un giro e l’altro	Ogni richiesta rigenera parti dell’app. Senza test, una modifica può rompere logica che funzionava, e il contesto delle richieste precedenti può perdersi.	Il cricchetto: test che si stringono soltanto, vettori golden eseguiti in due runtime, cancelli in CI che fermano il rilascio a ogni regressione.
Tracciabilità	La storia dell’app sta nella chat: quale richiesta ha cambiato cosa, e perché, si ricostruisce rileggendo i messaggi.	Cockpit tiene il filo: ogni richiesta con le parole di chi l’ha fatta, il requisito che una persona ha confermato, i commit e i test che lo citano, il verdetto sul rilascio. Si risale da un file al requisito che l’ha chiesto.
Stack e proprietà	Hosting, database e strumenti sono quelli della piattaforma. Esportazione del codice e limiti dipendono dal fornitore e dal piano.	Uno stack standard: React, TypeScript, Postgres su Supabase con Row-Level Security, edge function Deno. Il codice sta in un repository git, leggibile e portabile.
Ciclo di vita	Ogni app parte dal suo prompt: quello che un progetto ha imparato non passa da solo al successivo.	Ogni progetto lascia moduli provati (accesso, telemetria, tetto di spesa AI, sicurezza), test e lezioni da cui parte il successivo.

Quando una piattaforma no-code è la scelta migliore

Un mock visivo veloce, per mostrare un’idea o provare un flusso in un pomeriggio.
Uno strumento interno usa e getta, che serve qualche settimana e poi si butta.
Nessuno che possa mantenere il codice: hosting e aggiornamenti restano alla piattaforma.
Bisogni standard, come moduli, elenchi o un cruscotto semplice, che la piattaforma copre già.

Cosa resta uguale

Entrambe le strade usano modelli linguistici per scrivere software.
Entrambe partono da una descrizione in linguaggio naturale.
In entrambi i casi il risultato dipende da quanto è chiaro il problema descritto.

Per leggere tutto: Il metodo

02 · Confronto

Il metodo accanto agli strumenti di specifica

Strumenti come Spec Kit e Kiro lavorano sulla prima metà del giro: trasformano una richiesta in una specifica, poi in un piano e in compiti per l’agente, prima che si scriva codice.

Asse	Strumenti di specifica	Il metodo
Dove lavorano	Prima del codice: richiesta, specifica, piano.	Dopo il codice: test che si stringono, un test di guardia per ogni incidente, sonde in produzione, il verdetto di una persona.
Cosa resta	Una specifica che descrive cosa costruire.	Requisiti numerati legati ai test che li provano e ai rilasci che li contengono, in Cockpit.
Chi decide	Chi scrive la specifica la approva prima che l’agente parta.	Una persona conferma i requisiti e decide ogni rilascio, con le prove davanti.

Si usano insieme: una specifica scritta con uno di questi strumenti può essere la richiesta da cui parte il giro, e il metodo aggiunge quello che succede dopo.

Per leggere tutto: Cosa copre la specifica

03 · Confronto

Revisione a mano o cancelli

Il modo più diffuso di tenere sotto controllo un agente è leggere ogni pull request che apre. Funziona finché il codice da leggere sta nel tempo di una persona.

Asse	Revisione a mano	Il metodo
Cosa legge la persona	Ogni riga cambiata.	Le prove: quali requisiti tocca la modifica, quali test sono passati, quali tetti si sono stretti, quali incidenti restano aperti.
Cosa resta dopo	Un commento nella pull request.	Un test: ogni errore trovato diventa un controllo che gira a ogni push.
Quando non basta	Quando gli agenti scrivono più codice di quanto una persona possa leggere con attenzione.	Il controllo passa dalle righe alle regole; la persona decide sul rilascio.

Leggere tutto resta la scelta giusta per un codice piccolo, per una modifica che tocca la sicurezza e quando si sta imparando un codice nuovo.

Per leggere tutto: Le prove e il verdetto, in Cockpit by RiftSeed

04 · Approccio

Una piattaforma con l’AI dentro, passo per passo

Per il laboratorio una piattaforma su misura è software in cloud modellato sul lavoro di chi lo usa, con l’AI dentro il prodotto e una persona sulle decisioni che contano.

Modellate sul lavoro. Le schermate seguono i passi di chi lavora, nell’ordine in cui li fa. I requisiti si scrivono con le parole di chi li chiede e portano una chiave, così ogni modifica al codice risale a una richiesta.
L’AI dentro. L’AI lavora dentro le schermate, con un tetto di spesa e un modello di riserva scritti nella configurazione. Si può spegnere, e il lavoro va avanti senza. Le decisioni che contano restano a una persona.
In cloud, condivise. Una sola installazione serve più organizzazioni. Il database tiene separati i loro dati riga per riga, e ognuna vede soltanto i propri. Un aggiornamento arriva a tutte nello stesso momento.
Tenute con il metodo. Requisiti, test, sonde e verdetti, come ogni progetto del laboratorio. Un incidente si chiude solo con un test che lo riproduce, e quel test resta.

La base comune

Le parti che ogni piattaforma ripete si scrivono una volta sola. Le app del laboratorio ci girano già sopra, e i loro test le tengono ferme.

Accessi
Notifiche
Telemetria
Tetti di spesa AI
Sicurezza a livello di riga
Rilascio

Per leggere tutto: Piattaforme

05 · Approccio

Dal brief ai requisiti

Prima di scrivere una riga di codice serve sapere cosa si sta costruendo. Un’intervista guidata dall’AI trasforma un’idea o un processo di lavoro in requisiti confermati.

Una chat guidata raccoglie il problema, una domanda alla volta.
Ogni requisito si conferma prima di andare avanti: il brief contiene solo requisiti confermati.
Il brief arriva con requisiti, roadmap e le sfide principali.

L’AI propone i requisiti e li riformula a ogni correzione; se ne possono aggiungere, togliere o dividere in due, e la decisione resta a chi scrive il brief.

Quando la lista è ferma, i requisiti si congelano e restano quelli approvati, copiati parola per parola.

Il brief è il documento contro cui l’agente implementa e contro cui si legge il risultato. Se il comportamento non torna, il confronto si fa con il brief scritto.

Per leggere tutto: Il generatore di brief

06 · Approccio

Com’è fatta un’app costruita col metodo

Uno stack standard e, intorno al codice, le regole del metodo: un cancello prima di ogni rilascio, tetti che scendono soltanto, sonde sul sito pubblicato, un test di guardia per ogni incidente.

Lo stack

Interfaccia: React e TypeScript
Dati: Postgres su Supabase, con la sicurezza a livello di riga
Server: Edge function Deno
Codice: Un repository git, leggibile e portabile

Intorno al codice

Cancello prima del rilascio. Il rilascio è un push su main: typecheck e test girano prima, e il deploy dipende da loro. Un cancello rosso ferma tutto, e nessun agente approva un rilascio.
Tetti che scendono soltanto. Ogni misura che deve solo migliorare ha un tetto: gli avvisi di accessibilità, le forme e le misure di testo dell’interfaccia. Il tetto scende con ogni correzione, e il commit che lo supera fallisce.
Sonde sul sito pubblicato. Script Playwright rigiocano scenari veri sul sito in produzione, da computer e da telefono. Contano errori, pagine bianche e schermate di guasto.
Un test di guardia per ogni incidente. Un guasto trovato diventa un incidente, che si chiude solo con il test di guardia che lo riproduce.

Per leggere tutto: Le regole del metodo