Manifesto GVibeDev

L'IA è leva, non pilota automatico.

Il senso di strumenti migliori non è sparire dal lavoro. È tentare lavori più ambiziosi mantenendo umani intenzione, giudizio, test e responsabilità.

GVibeDev viene costruito pubblicamente come un laboratorio: le idee diventano sistemi, pagine, giochi, strumenti e documenti attraverso l'iterazione, non attraverso le dichiarazioni.

01 · Costruisci prima di predicare

Le cose che funzionano sono più forti delle dichiarazioni.

Le idee contano, ma il laboratorio si giudica da ciò che sopravvive al contatto con la realtà. Una build giocabile, uno strumento utilizzabile, una pagina funzionante o un workflow ripetibile insegnano più di una descrizione sicura di ciò che dovrebbe funzionare.

Costruisci prima. Poi documenta ciò che la build ti ha realmente insegnato.

02 · Amplifica il giudizio

L'IA estende le capacità. Non eredita il giudizio.

I modelli possono accelerare scrittura, programmazione, confronto, analisi e prototipazione. Quella velocità è utile solo finché qualcuno decide a cosa serve il lavoro, cosa conta come corretto e quando un output merita di sopravvivere.

La direzione umana non è un controllo finale decorativo. Fa parte dell'architettura.
03 · Testa

Se conta, portalo a contatto con la realtà.

Il codice generato deve funzionare. Le interfacce devono essere usate. I sistemi di gioco devono essere giocati. Le affermazioni vanno confrontate con le prove. Un output convincente non è la stessa cosa di un output corretto.

Il test è il punto in cui la sicurezza diventa informazione.

04 · I fallimenti sono evidenza

Rendi utili anche i tentativi rotti.

Una build fallita, una generazione scadente o un'assunzione sbagliata non sono sprecate se cambiano la decisione successiva. L'iterazione funziona quando il fallimento viene diagnosticato, non nascosto.

Lo scopo di una storia di sviluppo non è fingere che il percorso sia stato pulito. È conservare ciò che il percorso accidentato ha rivelato.

05 · Impara mentre costruisci

Le capacità possono essere acquisite dentro il progetto.

Non ogni progetto inizia con tutte le competenze necessarie già padroneggiate. Strumenti migliori abbassano la barriera d'ingresso, ma non eliminano il bisogno di capire ciò che si sta facendo.

Usa il progetto come motivo per imparare il prossimo pezzo mancante, poi rendi quella conoscenza parte del workflow.

06 · Mantieni visibili le decisioni

Non nascondere la parte umana dietro la macchina.

Requisiti, esclusioni, criteri di accettazione, correzioni, compromessi e scelte finali fanno parte del lavoro. Mostrarli rende lo sviluppo assistito dall'IA più comprensibile e più onesto.

La macchina può produrre candidati. Il progetto ha ancora bisogno di un autore delle decisioni.

07 · Prompt ≠ processo

Un buon prompting è architettura, non un'incantazione.

Un prompt può avviare un compito. Un processo mantiene contesto, vincoli, checkpoint, revisione e continuità tra molti compiti. I progetti complessi hanno bisogno del secondo.

Per questo il metodo conta di più man mano che gli strumenti diventano più potenti, non di meno.

08 · Accesso alle capacità

Una persona può oggi tentare lavori che un tempo richiedevano una struttura più grande.

Questo non rende obsoleta la competenza. Cambia chi può raggiungere la linea di partenza. Uno scrittore può prototipare strumenti. Un designer può testare sistemi. Un piccolo laboratorio può esplorare software, immagini, giochi e pubblicazione senza fingere che ogni disciplina sia diventata banale.

L'opportunità non è creare senza sforzo. È un accesso più ampio alla creazione seria.
Metodo nella pratica

Manuale LLM

La trattazione più ampia di prompting, struttura e responsabilità vive nel progetto pubblico Manuale LLM.

Apri Manuale LLM →

Il laboratorio

Guarda cosa producono questi principi.

Il portfolio è il lato pratico del manifesto: progetti a diversi livelli di completamento, con i loro vincoli reali ancora visibili.

Esplora i progetti →