Oltre il “Vibe Coding”: la consapevolezza

Non sono uno sviluppatore frontend “pixel-perfect” né un guru del backend che vive nel terminale. Sono un Consulente Cloud e AI. Il mio lavoro è progettare sistemi, non necessariamente digitare ogni singola parentesi graffa. Quando ho deciso di costruire Zone14, un SaaS per la gestione delle società calcistiche dilettantistiche, ho visto nel “Vibe Coding” non una scorciatoia magica, ma una necessità operativa.

Oggi si parla molto di Vibe Coding — termine reso celebre da Andrej Karpathy — come se fosse un abbandono totale alla “magia” dell’IA. Ma c’è un problema sociale e tecnico fondamentale che spesso viene ignorato: la fiducia. Per decenni ci siamo fidati dei compilatori. Se scriviamo codice sintatticamente corretto in C o Java, il compilatore produce un output deterministico. È una fiducia binaria: funziona o non funziona.
Con l’Intelligenza Artificiale Generativa, siamo entrati in un’era probabilistica.

I modelli attuali, anche i più avanzati come ChatGPT 5.2, Gemini 3 o Claude 4.5, sono come adolescenti prodigio: velocissimi, enciclopedici, ma spesso troppo sicuri di sé anche quando sbagliano clamorosamente. Siamo ancora agli inizi di questa tecnologia. Le IA devono maturare e, a differenza dei compilatori, il loro output deve essere costantemente verificato. Non possiamo permetterci il lusso di “fidarci e basta”, specialmente quando gestiamo dati sensibili di minori in un club sportivo.

La Competenza Umana: Il Vero Framework

L’errore più grande che si possa fare oggi è pensare che l’IA renda obsoleta la competenza informatica. Al contrario, la rende ancora più cruciale.
Per tirare fuori un prodotto valido come Zone14, non basta chiedere “fammi un gestionale”. Serve una competenza trasversale per:
Analizzare lo Stack Tecnologico: La scelta delle tecnologie non è stata casuale, ma frutto di un lungo studio sulle moderne architetture web.
Engineering Prompting: Saper parlare alla macchina. Non con frasi vaghe, ma con istruzioni strutturate (spesso in XML o contesti rigidi) per limitare le “allucinazioni”.

Containerizzazione: Capire che senza Docker, il software è solo un codice che gira sulla “mia macchina”. La containerizzazione è obbligatoria per garantire scalabilità e portabilità reale.

Zone14: Scelte Tecniche e Architettura (Open Source)

Per onestà intellettuale e per contribuire alla comunità, ho deciso di rilasciare il cuore di Zone14 su GitHub con licenza BSD 3-Clause. Credo che la trasparenza sia l’unico modo per mitigare la natura “scatola nera” dell’IA.

Lo Stack: Concretezza “Bleeding Edge”

Dopo un’analisi approfondita, ho scartato la complessità dei microservizi (spesso eccessiva per un team piccolo) a favore di un Modern Monolith robusto:

• Backend: Laravel 12.41 su PHP 8.4 su Frankenphp. La scelta è ricaduta su PHP per la sua maturità e per le nuove feature (Property Hooks, Strict Types) che lo rendono eccellente per il business logic. Inoltre frankenphp garantisce ottime velocita grazie ai sui worker che tengono la sessione attiva.
• Frontend: React 19 + Inertia.js 2.0. Un approccio “No-API” che riduce drasticamente la complessità di gestione dello stato, permettendo di sviluppare interfacce reattive senza la fatica di mantenere API REST separate.
• Database: PostgreSQL 18. Scelto per la sua affidabilità e le estensioni moderne come pgvector.

Il Cuore dei Dati: Schema-per-Tenant

Qui l’IA tendeva a suggerire soluzioni semplici (tutti in una tabella) o complesse (un database per cliente). Grazie alla mia esperienza cloud e un po’ di studi e ricerche, ho optato per una via di mezzo architetturale: Schema-per-Tenant.

• Isolamento: Ogni società sportiva (Tenant) ha il suo schema PostgreSQL dedicato. I dati sono logicamente separati e sicuri.
• Routing: Non usiamo sottodomini complessi (gestione DNS da incubo). La risoluzione del tenant è basata tassativamente sull’utente autenticato (1 User : 1 Tenant). Semplice, sicuro, lineare.
• Identificatori: Uso massivo di UUIDv7. A differenza dei classici UUID, sono ordinabili temporalmente, risolvendo i problemi di performance degli indici nei database relazionali.

Il Metodo di Lavoro: Disciplina sopra le Vibrazioni

Come si gestisce un progetto così complesso con l’IA senza perdere il controllo? Con regole ferree.

Regole Rigide e “Context Files”

Nella root del progetto non c’è anarchia. Esiste una cartella ./agent/rules che contiene file di istruzioni dettagliate per gli agenti (usando Google Antigravity e Cursor). Queste regole impongono stili di codifica, pattern di sicurezza e limiti che l’IA non deve valicare. È come dare un binario preciso a un treno velocissimo.

Testing e il “Contrattacco”

Il Vibe Coding richiede un approccio difensivo.

• Testing Step-by-Step: Ogni modulo viene testato isolatamente.
• L’Architetto Ostile: Uso l’IA contro se stessa. Dopo aver generato una funzionalità, apro una nuova sessione con un modello diverso (es. Claude Opus contro Gemini) e gli chiedo: “Smonta questo codice. Trova vulnerabilità, falle logiche e problemi di performance”. Questo “contrattacco” è fondamentale per pulire il codice dall’eccessiva sicurezza tipica degli LLM.

Linting e Pulizia Incrementale

Il codice generato è spesso sporco. Usiamo strumenti di linting (Pint per PHP, ESLint per JS) eseguiti in step successivi. Non si committa mai “raw output” dell’IA. La pulizia è parte integrante del processo di “messa a terra” del codice.

Funzionalità e Impatto Sociale

Il prodotto non è solo codice, è una soluzione a problemi reali.

• Science Worker (Python): Un servizio separato containerizzato che usa PaddleOCR e Pandas per calcoli complessi (come il carico di lavoro degli atleti o la digitalizzazione delle firme). Qui l’IA aiuta a scrivere la logica matematica, ma la validazione è umana.
• Containerizzazione Obbligatoria: Tutto gira su Docker. Non esiste “funziona sul mio PC”. Docker garantisce che l’ambiente di sviluppo sia identico a quello di produzione, eliminando una classe intera di problemi tipici dei junior developer.
• Redis: Usato per code e cache, essenziale per mantenere l’interfaccia utente reattiva mentre il backend macina dati pesanti.

Conclusione: Un Nuovo Umanesimo Tecnologico

Zone14 è la dimostrazione che è possibile costruire software di livello enterprise da soli, o quasi. Ma il “quasi” è gigantesco.

Richiede un’umiltà di fondo: accettare che l’IA farà errori e che la nostra responsabilità sociale e tecnica è intercettarli.

Non stiamo sostituendo i programmatori con le macchine; stiamo evolvendo verso figure ibride che devono avere una cultura sistemistica ancora più profonda per orchestrare questi nuovi strumenti potenti e caotici.

Il codice sarà disponibile su GitHub. Non è perfetto, è umano. E forse, proprio per questo, è affidabile.