Com’è fatto RiftSeed: lo stack, il metodo, il lavoro con l’AI
· 10 min · riftseed, agentic-coding, supabase, cloudflare
Una base condivisa e app vere, costruite con agenti AI sotto revisione umana. Cosa c’è sotto, e come si lavora davvero.
RiftSeed è un laboratorio di software: un posto dove le app vanno da idea a produzione con l’AI che scrive il grosso del codice e una persona nel punto in cui si decide. È nato per capire una cosa sola: quanto in là può arrivare oggi una persona da sola, con questi strumenti, se accetta la disciplina che serve a non farsi male. Questo articolo è cosa c’è sotto il cofano.
Lo stack, in breve
Frontend Vite + React + TypeScript, servito statico da Cloudflare Pages. Backend Supabase: Postgres con row-level security dappertutto, Edge Functions in Deno per la logica sensibile, pg_cron per i lavori periodici, Auth per anonimi e registrati, Storage. Nessun server proprio da tenere in piedi. Le funzioni AI passano da OpenRouter, così il modello si cambia senza toccare il prodotto.
La scelta che vale più di tutte è meno visibile: le app non nascono da zero, nascono dentro la stessa architettura e ereditano ciò che c’è già: account e accessi, notifiche, telemetria, temi, limiti di spesa AI, sicurezza a livello di riga. Il primo prototipo di una nuova app parte già con metà delle fondamenta in piedi. È il motivo per cui una persona sola riesce a stare dietro a più cose.
Come si lavora con gli agenti (il metodo)
Il codice lo scrivono in gran parte agenti AI, con una persona che fa da comparatore. Il metodo esclude il “dai un prompt e speri”. Un lavoro serio parte da un inquadramento: cosa deve fare, quali sono i vincoli veri, cosa non deve rompere. Poi l’agente implementa contro quella specifica, i test girano accanto, e una persona legge il risultato: non ogni riga, il comportamento. Due uscite possibili: avanti, oppure indietro all’agente con delle note. L’errore torna come istruzione, non come rammendo a mano.
Sui compiti grossi non si usa un agente solo. Il lavoro si divide: chi pianifica, chi implementa, chi verifica; oppure un panel di prospettive diverse che si criticano prima della decisione. È più lento di un singolo colpo, ma prende i buchi che un singolo colpo non vede. Sui prompt la ricerca della formula magica è finita presto: quello che conta è la struttura intorno: la specifica, i test come cancello, il fatto che ogni modifica sia estraibile e reversibile. La padronanza degli strumenti conta più della frase perfetta.
RLS ovunque, e il bug che ha insegnato a rispettarla
Tutto il dato è protetto da row-level security a livello di database, e le scritture sensibili passano solo da funzioni edge che si difendono da sole: rate limit, whitelist, controlli prima del modello. Un giorno una funzione tornava dati vuoti in modo intermittente, senza una causa visibile. Era auth.uid() che restituiva NULL sotto sessione anonima in un punto dove si dava per scontato ci fosse un utente. Nessun crash, solo un silenzio. Da lì la regola rimasta: sotto RLS, “nessun errore” è un invito a controllare cosa vede davvero questo ruolo, mai la garanzia che vada tutto bene.
L’AI dentro il prodotto, non solo nell’officina
C’è l’AI nel modo in cui si costruisce, e c’è l’AI dentro le cose costruite. Ogni funzione AI ha il suo slot di modello, con una catena di fallback: se il modello preferito è giù o troppo caro, si scende a uno più economico invece di rompersi in faccia all’utente. Ogni app ha un budget di spesa AI: un tetto giornaliero e un rate limit contati prima di chiamare il modello, così una richiesta respinta non brucia budget. Il chatbot del sito è l’esperimento più visibile: risponde da una base di conoscenza curata, dentro regole precise su cosa può e non può dire.
Un dettaglio che ha morso forte: un tool-call che ordinava dei risultati leggeva un dato congelato al momento del fetch invece che all’ora corrente. Rispondeva con classifiche leggermente sbagliate senza mai sbagliare in modo evidente. La lezione: diffidare degli errori che non gridano.
Feedback, telemetria, e il rispetto per chi guarda
Il ciclo non si chiude al rilascio. I commenti di chi usa le app vengono raccolti e classificati dall’AI in change request con una prima analisi d’impatto; poi l’AI propone cosa conta di più e una persona decide cosa entra nel giro successivo. Per capire cosa viene usato c’è una telemetria propria, senza strumenti di terze parti: eventi essenziali, un identificatore di sessione casuale, il paese dedotto dall’infrastruttura di rete senza salvare l’IP, conservazione novanta giorni. Nessuna profilazione, niente tracciatori esterni. È il sistema più rispettoso che il lab sapesse fare, ed è anche il più semplice da spiegare.
Cosa viene dopo
Niente proclami: quello che interessa misurare è come la distanza tra idea e cosa provabile continua ad accorciarsi a ogni generazione di modelli, e dove smette di accorciarsi. La base condivisa cresce per sedimentazione (un modulo, un test, un pezzo di framework alla volta) e ogni progetto nuovo dovrebbe partire più avanti del precedente. Se un giorno una di queste app se lo guadagna davvero (un utente vero che ci tiene), il passo dopo è la graduazione: dominio suo, progetto separato, e la parte noiosa ma seria che oggi non c’è. Per ora resta un “se”, non un piano.
Perché in pubblico
Tutto resta qui dentro, con lo stato onesto di ogni cosa, per un motivo pratico: è l’unico modo di misurare come reggono gli agenti su un problema vero, dove si spezzano, quanto costa davvero un prototipo oggi rispetto a un anno fa. La distanza tra idea e cosa provabile si è accorciata parecchio. L’AI da sola non fa tutto: sono un metodo e una base condivisa a portare una persona dove prima serviva un piccolo team. Il resto si scopre costruendo, e quando qualcosa si rompe viene scritto.