VIBE APP: tenere il filo mentre l'AI accelera
Un esperimento aperto su contesto, perimetro, memoria e verifica nel lavoro quotidiano con coding agent.
VIBE APP non vuole essere un altro coding agent. È uno strumento sperimentale posto tra l'intenzione umana e l'esecuzione dell'agente: per rendere visibili decisioni, limiti, risultati e apprendimenti. Funzionalità e ipotesi possono cambiare; gli errori fanno parte dell'esperimento.
Nove tappe per orientarsi
La velocità può diventare un boomerang?
I coding agent rendono possibile produrre modifiche molto rapidamente. Il rischio non è che ogni cambiamento sia sbagliato: è che la velocità con cui il progetto cambia superi quella con cui si riesce a capirlo, verificarlo e ricordarlo.
Rendere esplicite poche cose importanti
L'ipotesi è modesta: un'attività gestita con AI può essere più controllabile se, prima dell'esecuzione, rende espliciti obiettivo, contesto, perimetro, vincoli e criteri per giudicare il risultato.
Non significa appesantire ogni richiesta. Significa capire quale sia il minimo di struttura che evita di dover ricostruire tutto dopo.
Uno spazio fra intenzione ed esecuzione
Intento
Che cosa si vuole ottenere e perché vale la pena farlo ora.
Perimetro
Quali parti può toccare l'agente, quali deve lasciare fuori.
Traccia
Che cosa è stato chiesto, deciso e realizzato davvero.
Verifica
Come distinguere un risultato completato da uno soltanto plausibile.
VIBE APP tenta di raccogliere questi elementi senza sostituire gli strumenti che scrivono codice. L'agente resta l'esecutore; la direzione e il giudizio restano umani.
Non misura “quanto ha lavorato l'AI”: prova a rendere visibili i punti che richiedono una decisione.
Mockup, non roadmap. Alcune funzioni potrebbero entrare in VIBE APP, altre restare esperimenti separati, altre ancora essere abbandonate.
Un passaggio alla volta
Il ciclo non è prescritto come metodo universale: è la sequenza che sto verificando nel lavoro reale. L'idea è osservare dove nasce una deviazione prima che diventi difficile ricostruirla.
«Voglio migrare il calcolo IVA al nuovo motore.»
Prima del codice provo a rendere esplicito il risultato cercato. È ancora una richiesta incompleta, ma almeno dichiara la direzione.
Quattro file coinvolti, una dipendenza, un rischio alto.
L'agente espone ciò che pensa di dover toccare prima di farlo. È il momento in cui posso accorgermi che ha interpretato la richiesta in modo diverso dal previsto.
Il lavoro resta dentro billing/.
Il perimetro non serve a impedire all'agente di ragionare. Serve a rendere evidente quando l'esecuzione chiede di oltrepassare ciò che avevo approvato.
Diff, test e deviazioni prima dell'accettazione.
Il risultato non è “finito” perché il codice compila o perché l'agente dichiara di aver concluso. Provo a vedere che cosa è realmente cambiato e rispetto a quale intenzione.
Indipendente non significa innocuo
Due attività possono essere indipendenti dal punto di vista funzionale, ma interferire se modificano gli stessi file, moduli o decisioni architetturali. È la ragione per cui VIBE APP distingue dipendenze e interferenze.
La regola prudente oggi è evitare più writer contemporanei sullo stesso perimetro. Non è una soluzione definitiva: è una protezione temporanea finché non ci sono segnali più affidabili per governare il lavoro parallelo.
core/logging/format.py e billing/invoice.py non erano nel perimetro autorizzato.
python-dateutil 2.9.0 è stata introdotta senza richiesta preventiva: prima di accettarla serve una decisione.
billing/tax/engine.py supera la soglia che avevo scelto come segnale di attenzione.
Il punto non è impedire all'agente di deviare. È rendere visibile la deviazione prima che diventi una decisione implicita.
Non conservare tutto: conservare ciò che cambia le scelte
Chat, prompt, codice, note e documenti producono più memoria di quanta se ne possa usare. Una memoria utile deve separare stato attuale, decisioni che cambiano il progetto, regole ricorrenti e storia necessaria per non ripetere un errore.
Dove siamo
Che cosa esiste oggi, con quali limiti e dipendenze.
Perché
Le scelte che sarebbe costoso o rischioso perdere.
Come lavoriamo
Vincoli che ricorrono fra attività e sessioni.
Che cosa è cambiato
Errori e verifiche che hanno modificato il metodo.
Osservazioni, non verdetti
Task più delimitati rendono più facile verificare la modifica e ricostruire il motivo di una decisione.
Chiedere assessment e piano prima della patch riduce le sorprese sul perimetro.
Quanta struttura migliora il risultato prima di diventare un costo eccessivo.
Qual è il minimo di memoria utile per riprendere un progetto con un nuovo agente.
Le osservazioni non dimostrano ancora una metodologia. Servono soprattutto a formulare il prossimo esperimento.
Lo stesso problema visto da punti diversi
VIBE APP non nasce isolata. Alcune domande che sto affrontando qui sono già emerse in altri esperimenti del LAB, e altre stanno aprendo nuovi rami. Non so ancora se convergeranno in un unico sistema: per ora mi interessa capire che cosa ciascun pezzo aggiunge davvero.
Prompt Builder
Prova a rendere espliciti obiettivo, contesto, perimetro, vincoli e criteri di verifica prima che una richiesta venga consegnata all'AI. La domanda resta aperta: quanta struttura aiuta, e quando diventa burocrazia?
Apri Prompt Builder →AI locale
Sto esplorando se alcuni compiti circoscritti possano essere affidati a un modello locale. Non è uno switch: selezione del modello, contesto, dataset, eventuale fine-tuning e validazione possono rendere questa strada molto meno immediata di quanto sembri.
VIBE APP
Prova a mantenere visibili intenzione, perimetro, decisioni, verifiche e memoria mentre strumenti diversi eseguono il lavoro.
La domanda non è soltanto “posso far girare un modello in locale?”, ma “quanto lavoro serve perché quel modello diventi sufficientemente competente sul mio progetto?”
In alcuni casi potrebbe bastare fornire il contesto giusto al momento giusto; in altri potrebbe servire una specializzazione più profonda, fino al fine-tuning. Anche capire quando il fine-tuning aggiunge valore, e quando invece introduce solo costo e complessità, fa parte dell'esperimento.
Quello che ancora non so
- Quanto deve conoscere un agente prima di modificare un progetto?
- Quanto deve essere strutturato un prompt?
- Quando il contesto aiuta e quando diventa rumore?
- Quanto piccolo deve essere un task per restare verificabile senza perdere la visione d'insieme?
- Quando una regola riduce davvero gli errori e quando rallenta inutilmente?
- Che cosa accade quando gli agenti non sono più uno, ma molti?
Questo esperimento ti è stato utile per capire il funzionamento?
Hai un'esperienza diversa da raccontare, un errore, un'obiezione o un'idea da aggiungere?
Invia un contributo →