Vincoli: tempo, dati, piattaforma, budget, competenze

Un vincolo non dichiarato non sparisce: viene riempito dal modello con un’assunzione di default. “Funziona ovunque, dura per sempre, costa zero, lo manterrà chiunque, gestisce tutto” è la combinazione di assunzioni che produce sistemi sovradimensionati e fragili. I vincoli espliciti non limitano il design: lo rendono adatto al tuo caso.

Perché questa lezione conta

Senza vincoli, l’AI propone soluzioni “complete” che includono Kubernetes, microservizi, Redis, monitoring, queue. Per una landing page con 100 visite al giorno. Risultato: sovraingegnerizzazione, costo di manutenzione altissimo, time-to-launch raddoppiato. Vincoli espliciti producono risposte calibrate sulla scala reale.

Obiettivo operativo

Alla fine devi saper:

1. distinguere vincoli rigidi, negoziabili e sconosciuti;
2. coprire le cinque categorie principali (tecnici, pratici, dati, regolamentari, umani);
3. trasformare i vincoli in input al prompt e regole di progetto.

Nucleo della lezione

1. Cinque categorie di vincoli

Tecnici:

• piattaforma target: web (browser min supportati), iOS (versioni), Android (API level), desktop (OS), CLI;
• dispositivi: dimensione schermo minima, supporto offline, GPU, fotocamera;
• linguaggi e stack: cosa è disponibile / preferito / vietato per ragioni di team;
• servizi esterni: cosa puoi usare (account già attivi) e cosa è vietato (compliance, costo);
• limiti di hosting: shared/serverless/VPS/Kubernetes; durata cold start; limiti memoria/disco.

Pratici:

• tempo: quanto puoi dedicare prima del lancio (ore reali, non ottimistiche);
• budget: euro al mese sostenibili per hosting+servizi+modelli AI;
• manutenzione: chi e con quale frequenza interviene dopo il lancio;
• capacità del team: solo, in due, in cinque; livelli di esperienza diversi;
• scadenze esterne: evento, lancio commerciale, requisito legale.

Sui dati:

• disponibilità: hai i dati? sono in formato usabile? tempo di importazione?
• qualità: completi, sporchi, mancanti, duplicati;
• privacy: personali, sensibili, sanitari, finanziari, legati a minori;
• aggiornamento: chi ne è responsabile, con quale cadenza;
• esportabilità e cancellazione: GDPR richiede sia esportabilità (portabilità) sia cancellazione (diritto all’oblio).

Regolamentari:

• GDPR/normativa privacy locale;
• normative settoriali (sanità, finanza, sicurezza dati);
• accessibilità (WCAG AA, EAA in EU dal 2025 per molti servizi).

Umani:

• chi userà il prodotto (vedi lezione persona);
• chi lo manterrà;
• competenze disponibili oggi vs da acquisire;
• supporto e on-call previsti.

2. Rigidi, negoziabili, sconosciuti

Tre etichette per ogni vincolo:

• Rigido: non cambia. “Devo lanciare entro il 15 maggio per evento”. “Solo dati on-premise, no cloud”. “Budget infrastruttura zero”.
• Negoziabile: preferenza forte ma con flessibilità. “Vorrei TypeScript ma JavaScript va bene”. “Idealmente entro 1 mese, accetto 6 settimane”.
• Sconosciuto: non hai informazioni. “Non so quanti utenti avremo”.

Etichetta esplicita evita la trappola “tutto è importante = niente è prioritario”. Il modello (e tu) sa cosa proteggere assolutamente vs cosa rinegoziare se serve.

3. Vincoli come input al prompt

I vincoli vivono in due posti:

• Prompt singolo task: i vincoli rilevanti per quel task specifico. “Stack: Next.js + Postgres. Budget: gratis fino a 10K visite/mese. Tempo: 2 settimane”.
• File di regole di progetto (AGENTS.md, CLAUDE.md): i vincoli stabili che valgono per ogni task. Stack, hosting, deploy, vincoli di sicurezza, limiti di costo.

Vincoli volatili (specifici per task) → prompt. Vincoli stabili (durano nel progetto) → file di regole. Non ripetere ovunque, non dimenticare in nessun posto.

Caso guidato

Scenario: vuoi costruire una piccola app per prenotare colloqui con docenti. L’idea iniziale è “fai un calendario semplice”. Sembra chiara, ma senza vincoli l’AI può scegliere qualunque strada: account obbligatori, database cloud, notifiche email, integrazione Google Calendar, dashboard admin, pagamenti, ruoli complessi.

Riscrivi i vincoli prima di chiedere codice:

Piattaforma: web app responsive, usata da smartphone e desktop.
Tempo: MVP dimostrabile in 2 pomeriggi.
Budget: zero servizi a pagamento.
Dati: nomi studenti, email, orario colloquio. Nessun dato sanitario o disciplinare.
Competenze: conosco HTML/CSS base e poco backend.
Hosting: deploy statico o serverless semplice.
Manutenzione: una persona non tecnica deve poter modificare gli slot.

Ora classificali:

• rigidi: zero budget, niente dati sensibili, mobile leggibile;
• negoziabili: integrazione calendario esterno, login, notifiche email;
• sconosciuti: numero reale di utenti, bisogno di ruoli, durata conservazione dati.

Questa classificazione cambia il prompt. Non chiederai “crea app prenotazioni completa”, ma:

Progetta MVP per prenotazione colloqui con vincoli: zero budget, pochi dati, mobile, gestione slot semplice. Prima proponi architettura minima e alternative per salvare dati senza introdurre complessità inutile. Evidenzia cosa resta manuale nella prima versione.

La qualità della risposta migliora perché il modello non deve indovinare i confini.

Procedura pratica

Per un nuovo progetto:

1. Brainstorm vincoli: 15 minuti, butta giù tutto ciò che ti viene in mente per le 5 categorie.
2. Triagia: per ogni vincolo, etichetta rigido/negoziabile/sconosciuto.
3. Sconosciuti → trasforma in domande da rispondere prima di scrivere codice (ricerca, conferma con stakeholder).
4. Rigidi → vanno nel file di regole + ripetuti nel prompt iniziale.
5. Negoziabili → prompt iniziale, con etichetta “preferenza”.
6. Verifica conflitti: due rigidi possono essere incompatibili (es. “gratis + scala enterprise”). Risolvi prima.

Laboratorio guidato

Costruisci tabella vincoli per un mini-progetto reale o ipotetico (es: tool interno per gestione magazzino piccola azienda).

Tabella:

Vincolo	Categoria	Tipo (R/N/S)
Funziona offline	Tecnico	R
Solo desktop	Tecnico	N
Budget mensile €20	Pratico	R
Numero utenti	Pratico	S
Dati restano in azienda	Dati	R
Italiano UI	Pratico	R

Riempila per il tuo scenario. Conta: quanti rigidi? quanti sconosciuti? Sconosciuti > 3 = manca lavoro di scoperta prima di sviluppare.

Output atteso

Una tabella vincoli compatta + una sezione “vincoli” da copiare nel file di regole del progetto. Riferimento da consultare a ogni nuovo prompt: i vincoli rigidi devono essere nella richiesta.

Studio passo passo

Studia questa lezione in tre passaggi, senza correre subito al prompt o al codice.

1. Prima lettura: chiarisci l’obiettivo: imparare a esplicitare i confini del progetto, perché l’AI tende a riempire i vuoti con assunzioni proprie. Se non riesci a riscriverlo in una frase tua, rileggi il nucleo della lezione.
2. Seconda lettura: trasforma i contenuti in domande operative:

• Vincoli tecnici: piattaforma, browser, dispositivi, linguaggi disponibili, servizi esterni, limiti di hosting.
• Vincoli pratici: tempo, budget, manutenzione, capacità del team, scadenze, supporto futuro.
• Vincoli sui dati: disponibilità, qualità, privacy, aggiornamento, esportabilità e cancellazione.

3. Applicazione: svolgi il laboratorio: costruire una lista di vincoli per un prototipo e segnare quali sono rigidi, negoziabili o sconosciuti. L’output da ottenere è: una tabella dei vincoli da includere nei prompt principali e nei file di regole del progetto.

Prima di passare alla lezione successiva, controlla di avere un artefatto concreto: una tabella, un prompt, una checklist, un mini report, un diff commentato o una decisione scritta. Nel vibe coding la comprensione resta astratta finché non produce una traccia verificabile.

Checklist di verifica

• ho coperto tutte e 5 le categorie nel mio brainstorm;
• ho etichettato ogni vincolo rigido/negoziabile/sconosciuto;
• ho almeno un piano per risolvere ogni “sconosciuto” rilevante prima del codice;
• vincoli rigidi sono nel file di regole del progetto, non solo nella mia testa.

Errori comuni

“Lo deciderò strada facendo”. Vincoli decisi sotto pressione sono peggiori di vincoli decisi a freddo. Soprattutto budget e privacy.

Confondere desideri e vincoli. “Voglio sia bello” non è vincolo. “Deve passare WCAG AA” lo è.

Vincoli incompatibili nascosti. “Gratis, infinito, sicurissimo”: tre rigidi che non coesistono. Il modello sceglierà quale violare se non li espliciti come incompatibili.

Dimenticare i vincoli umani. Un sistema tecnicamente perfetto che richiede manutenzione di un team che non hai è un sistema fallito.

Vincoli solo nel prompt, mai nel file di regole. Devi ripeterli ogni volta. Stancante e fragile. File di regole è la memoria stabile.

Prompt di lavoro

Aiutami a esplicitare i vincoli per questo progetto:

Idea: [descrizione 2 righe]

Per ognuna delle 5 categorie chiedimi una alla volta cosa so:

1. Tecnici (piattaforma, dispositivi, stack, servizi, hosting)
2. Pratici (tempo, budget, manutenzione, team, scadenze)
3. Dati (disponibilità, qualità, privacy, aggiornamento, export/cancellazione)
4. Regolamentari (GDPR, settoriali, accessibilità)
5. Umani (chi usa, chi mantiene, competenze)

Per ogni risposta:
- chiedimi se è rigido (R), negoziabile (N) o sconosciuto (S)
- se S, suggerisci come scoprirlo

Al termine: tabella riassuntiva e segnalazione di eventuali conflitti fra vincoli rigidi.

Non scrivere ancora codice né proporre architettura.

Esercizio finale

Prendi un progetto in produzione (tuo o altrui di cui conosci storia). Ricostruisci a posteriori i vincoli rigidi che hanno guidato le scelte architetturali. Ce ne sono che oggi rivedresti? Ci sono vincoli che NON erano espliciti e che hanno portato a decisioni sbagliate? L’esercizio mostra come i vincoli (espliciti o impliciti) determinino il design molto più delle preferenze tecniche.