Percorsi
Percorsi
I percorsi sono traiettorie concettuali. Ognuno descrive una progressione da un punto di partenza familiare a un risultato più strutturato.
Non sono guide passo-passo. Non prescrivono strumenti o tempistiche. Descrivono una sequenza di ragionamento: se parti da qui e segui questa linea di pensiero, puoi arrivare là.
I percorsi nascono dal lavoro reale. Riflettono decisioni che ho effettivamente preso, non ideali teorici.
Chat → Progetto
Punto di partenza: una conversazione con un modello AI. Una domanda, un’idea grezza, un problema descritto in linguaggio naturale.
La traiettoria:
La maggior parte delle interazioni con l’AI inizia come conversazione. Chiedi qualcosa, ottieni una risposta, la raffini. È utile ma fragile. La conversazione è effimera, il contesto è implicito e l’output non ha struttura oltre a quello che il modello ha prodotto in quel momento.
Il percorso da chat a progetto consiste nel rendere esplicito l’implicito. Inizia quando noti che la conversazione continua a tornare sullo stesso problema. A quel punto, il problema merita un file, non un prompt.
La prima decisione strutturale è lo scope: cosa fa questa cosa, e cosa non fa. L’AI è brava a generare possibilità ma scarsa nel tracciare confini. Quello è il lavoro dell’umano.
La seconda decisione è la persistenza: dove vive l’output e come è organizzato. Un progetto ha file, nomi e un layout. Una conversazione non ha niente di tutto questo.
La terza decisione è il feedback: come sai se funziona. Di solito questo significa un test, un deploy, o almeno un modo per eseguire la cosa fuori dalla finestra di chat.
Dove arrivi: un piccolo progetto delimitato e eseguibile che è nato da una conversazione ma non dipende più da essa.
Infrastruttura → Sistema
Punto di partenza: un pezzo di infrastruttura. Un account cloud, una pipeline di deploy, un insieme di risorse provisionate.
La traiettoria:
L’infrastruttura da sola non è un sistema. È una fondazione senza edificio. La distanza tra “ho un modulo Terraform” e “ho un sistema funzionante” è più grande di quanto sembri, perché il divario non è tecnico — è architetturale.
La prima cosa da stabilire è a cosa serve l’infrastruttura. Non in termini generali, ma concretamente: cosa ci girerà sopra, chi la userà, e quali sono le modalità di errore che contano. L’infrastruttura provisionata senza rispondere a queste domande tende a essere sovra-ingegnerizzata o disallineata con le esigenze reali.
Il passo successivo sono i confini. Un sistema ha componenti con responsabilità definite e interfacce tra di essi. L’infrastruttura li supporta, ma non li crea. Devi decidere dove vive l’autenticazione, come fluiscono i dati tra i servizi, cosa è sincrono e cosa no.
Poi viene l’osservabilità. Un sistema deve essere leggibile per le persone che lo gestiscono. Log, metriche e health check non sono un ripensamento — fanno parte del design. Se non riesci a capire se il sistema funziona guardando i suoi output, non hai ancora un sistema.
Dove arrivi: infrastruttura che serve uno scopo coerente, con confini chiari tra i componenti e sufficiente osservabilità per comprendere il suo comportamento in produzione.
Workflow → Servizio
Punto di partenza: un workflow manuale. Una sequenza di passi che una persona esegue ripetutamente, magari con qualche script o automazione.
La traiettoria:
Molti servizi utili iniziano come workflow che qualcuno fa a mano. L’impulso di automatizzare è naturale, ma l’automazione prematura produce sistemi fragili. Il percorso da workflow a servizio richiede di capire il workflow in profondità prima di codificarlo.
La prima domanda è l’affidabilità: cosa succede quando un passaggio fallisce. In un workflow manuale, l’umano si adatta. In un servizio, il fallimento deve essere gestito esplicitamente. È qui che la maggior parte dell’automazione ingenua si rompe — assume che il percorso felice sia l’unico percorso.
La seconda domanda è l’interfaccia: chi o cosa attiva il workflow, e come viene consegnato il risultato. Un workflow manuale potrebbe iniziare con “apro il laptop e controllo il foglio di calcolo.” Un servizio ha bisogno di un punto di ingresso definito e un output definito.
La terza domanda è dove l’AI si inserisce. Non tutti i passaggi beneficiano del coinvolgimento dell’AI. I passaggi che richiedono giudizio, riconoscimento di pattern o elaborazione del linguaggio naturale sono candidati. I passaggi che richiedono calcolo preciso e ripetibile no — quelli appartengono al codice deterministico.
Dove arrivi: un servizio affidabile e attivabile che codifica un workflow precedentemente manuale, con l’AI applicata solo dove fornisce valore chiaro e logica deterministica ovunque altro.