{"id":4895,"date":"2026-08-29T13:19:23","date_gmt":"2026-08-29T12:19:23","guid":{"rendered":"https:\/\/www.fullo.net\/blog\/?p=4895"},"modified":"2026-08-29T13:19:27","modified_gmt":"2026-08-29T12:19:27","slug":"espandi-poi-pota-il-poc-usa-e-getta-come-strumento-di-scoperta","status":"publish","type":"post","link":"https:\/\/www.fullo.net\/blog\/2026\/08\/29\/espandi-poi-pota-il-poc-usa-e-getta-come-strumento-di-scoperta\/","title":{"rendered":"Espandi, poi pota: il POC usa e getta come strumento di scoperta"},"content":{"rendered":"\n

Diciamocelo: nella maggior parte delle aziende il “proof of concept<\/em>” era una parola usata per indicare qualcos’altro… cio\u00e8 qualcosa che nasceva per validare un’idea e finiva per diventare un software in produzione interna se andava bene, a tutti i clienti altrimenti. Questo avveniva e tuttora avviene perch\u00e9 realizzare un POC ha un costo. Tre giorni-uomo, cinque, dieci, e una cosa che costa dieci giorni-uomo non la butta via nessuno, nemmeno quando dovrebbe.<\/p>\n\n\n\n

Il risultato \u00e8 un vizio che ho visto ovunque e che ho avuto anch’io: si parte gi\u00e0 preoccupati per la qualit\u00e0. Si sceglie l’architettura giusta prima di sapere se il problema \u00e8 quello che si crede. Si discute della libreria di validazione prima di capire se la feature ha senso. \u00c8 un’ottimizzazione prematura applicata a una fase di discovery, in cui ha poco senso ottimizzare un percorso di cui non si sa ancora dove finir\u00e0.<\/p>\n\n\n\n\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Quello che \u00e8 cambiato \u00e8 banale ed enorme insieme: il costo marginale di scrivere codice esplorativo \u00e8 crollato. Non parlo di scrivere codice buono<\/strong>, quello costa ancora<\/em>, e ci arrivo. Parlo di arrivare a qualcosa che gira, che si pu\u00f2 toccare, che risponde alla domanda “ma questa idea sta in piedi?<\/em>“. <\/p>\n\n\n\n

E quando una cosa costa ore, si pu\u00f2 buttare. \u00c8 tutta l\u00ec la differenza.<\/p>\n\n\n\n

Fase uno: libero arbitrio sulle dipendenze<\/h2>\n\n\n\n

Il mio flusso per i POC comincia con una regola che a diversi colleghi fa storcere il naso: in fase di esplorazione non mi pongo alcun limite alle dipendenze. Serve un SDK? Lo installo. Serve una libreria di validazione? La installo. Serve una cosa che si trascina dietro 94 pacchetti? Vabb\u00e8, creo quel buco nero attira byte chiamato “node_modules<\/em>“.<\/p>\n\n\n\n

Il motivo \u00e8 semplice: in questa fase l’obiettivo non \u00e8 il codice, ma la risposta. Ogni minuto speso a valutare se una libreria sia la scelta giusta \u00e8 un minuto sottratto alla domanda vera<\/a>: se ci\u00f2 che sto costruendo serva a qualcuno. E nell’esplorazione le dipendenze sono un acceleratore enorme: mi danno gratis tutti i pezzi a cui non voglio ancora pensare.<\/p>\n\n\n\n

Il caso concreto: un server MCP (Model Context Protocol<\/a>, il protocollo che permette a un assistente AI di parlare con sistemi esterni<\/em>) che espone, come strumenti, le funzioni di un apparato di rete che ho in casa. Volevo capire se l’idea reggesse: chiedergli, in linguaggio naturale, lo stato dei dispositivi connessi, invece di navigare un pannello di amministrazione disegnato nel 2014 e mai pi\u00f9 guardato in faccia da nessuno.<\/p>\n\n\n\n

Ho preso l’SDK ufficiale, ho preso zod<\/code> per la validazione, ho scritto gli handler, ha funzionato. 28 strumenti esposti, chiamate vere all’apparato, risposte corrette. Tre ore, forse quattro. La domanda aveva la sua risposta: s\u00ec, l’idea regge (se siete curiosi, trovate il lavoro nel mio repository <\/a>su GitHub).<\/p>\n\n\n\n

E qui, nel flusso tradizionale, sarebbe finita. Funziona, quindi va bene. Invece \u00e8 qui che comincia la parte interessante.<\/p>\n\n\n\n

Il bivio: butto o poto?<\/h2>\n\n\n\n

Un POC che funziona non \u00e8 automaticamente un POC da mantenere. Scritto cos\u00ec sembra ovvio e, nella pratica, \u00e8 il passaggio che salto pi\u00f9 spesso anch’io.<\/p>\n\n\n\n

Il criterio che uso comprende due domande, in quest’ordine.<\/p>\n\n\n\n

La prima: ho raggiunto l’obiettivo?<\/strong> Il codice si scrive perch\u00e9 c’\u00e8 un obiettivo, non per scrivere codice. Se il POC non ci arriva, si butta, e si \u00e8 imparato qualcosa, che poi \u00e8 esattamente il valore che ci si aspetta da un proof of concept. Non \u00e8 un fallimento, \u00e8 il risultato.<\/p>\n\n\n\n

La seconda, quella scomoda: con che qualit\u00e0 ci sono arrivato?<\/strong> Perch\u00e9 si pu\u00f2 raggiungere l’obiettivo in un modo che non vale la pena di mantenere. Magari funziona, ma \u00e8 ingestibile. Magari funziona, ma il valore aggiunto rispetto a come si faceva prima \u00e8 cos\u00ec marginale da non giustificare il costo di mantenerlo in vita. In quel caso, il POC si butta anche se ha avuto successo<\/em> e si lascia tutto com’era.<\/p>\n\n\n\n

Mi \u00e8 capitato di recente, in una direzione esattamente opposta a quella della storia che sto raccontando. Avevo scritto un paio di tool da zero e funzionavano; il POC serviva a capire se fosse conveniente farli ex novo o costruire un plugin su qualcosa gi\u00e0 esistente. La risposta \u00e8 stata che erano ridondanti rispetto agli strumenti open source gi\u00e0 in circolazione e mantenuti da altri. Buttati. Non perch\u00e9 non funzionassero, ma perch\u00e9 ci\u00f2 che aggiungevano non giustificava il costo di portarseli dietro.<\/p>\n\n\n\n

\u00c8 lo stesso criterio del server MCP applicato al contrario: l\u00ec ho sostituito le librerie generaliste con il mio codice, qui ho sostituito il mio codice con le librerie di qualcun altro. Il criterio non \u00e8 “meno dipendenze”. \u00c8 il codice giusto per quel problema e per la manutenzione che avr\u00e0.<\/p>\n\n\n\n

Questa \u00e8 la parte del metodo che regge tutto il resto e anche quella che costa di pi\u00f9 da esercitare, perch\u00e9 sembra buttare via lavoro. Ma se non si \u00e8 disposti a buttare via un POC riuscito, non si sta esplorando: si sta costruendo e si \u00e8 tornati al punto di partenza, in cui il costo gi\u00e0 speso decide al posto nostro.<\/p>\n\n\n\n

Nel caso del server MCP entrambe le risposte sono state s\u00ec: il salto rispetto al pannello di amministrazione era reale. Quindi si potava.<\/p>\n\n\n\n

E qui arriva la terza domanda, quella che decide il come e non il se: quanta manutenzione avr\u00e0 questa cosa?<\/strong><\/p>\n\n\n\n

Passare da POC a progetto significa prendere decisioni su come quel codice verr\u00e0 mantenuto ed \u00e8 l\u00ec, non prima, che si decide quanto specializzarlo. Se il progetto avr\u00e0 poca manutenzione, un tool interno, un server che faccia una sola cosa e non evolver\u00e0 granch\u00e9, allora conviene specializzarlo: si riduce la superficie di attacco e ci si tiene solo ci\u00f2 che serve. Se invece quel codice finisce in mano a un team che ci lavorer\u00e0 sopra per anni, l’SDK generalista compra una cosa che il codice specializzato non ha: documentazione che non avete scritto voi, e gente che sa gi\u00e0 come funziona. In quel caso trecento casi d’uso contro quattro non sono uno spreco: \u00e8 onboarding pagato in anticipo.<\/p>\n\n\n\n

Il POC serve a imparare e a valutare la fattibilit\u00e0. Non serve a produrre codice da tenere; quello \u00e8 un secondo lavoro che comincia dopo e parte da questa domanda.<\/p>\n\n\n\n

La gabbia: i test non sono igiene, sono la precondizione<\/h2>\n\n\n\n

Qui c’\u00e8 il pezzo che rende possibile tutto il resto.<\/p>\n\n\n\n

Prima di toccare una sola dipendenza, ho costruito una gabbia di test: unitari sui singoli componenti, funzionali end-to-end sul comportamento del server visto dall’esterno. 99 test, verdi. E, soprattutto, ho verificato l’interoperabilit\u00e0 con il client SDK reale, con tutti e 28 gli strumenti, prima di rimuovere la dipendenza dall’SDK. Il che significa che avevo una descrizione esecutiva di ci\u00f2 che il sistema doveva fare, redatta mentre l’SDK era ancora disponibile.<\/p>\n\n\n\n

\u00c8 anche il punto in cui la Definition of Done<\/a> fa il lavoro per cui esiste: dice quando il comportamento \u00e8 descritto abbastanza bene da poter cambiare quello che sta sotto. \u00c8 la differenza tra potare e sperare: senza la gabbia, sostituire un SDK con codice proprio \u00e8 un atto di fede: togli, provi a mano due o tre casi, sembra che vada, spedisci. Con la gabbia, ogni sostituzione produce una risposta binaria entro 30 secondi.<\/p>\n\n\n\n

Detto in altri termini: la libert\u00e0 della fase uno \u00e8 pagata con la disciplina della fase due. Le due cose vengono in coppia e, nel mio caso, l’ordine conta: i test scritti prima sono l’unica ragione per cui potevo permettermi di essere spericolato<\/em> all’inizio.<\/p>\n\n\n\n

Il cherry picking: cosa tieni, cosa sostituisci<\/h2>\n\n\n\n

S\u00ec, ma come fare il cherry-picking? Cosa tenere? Cosa sostituisco e cosa rimuovo?<\/p>\n\n\n\n

Cosa tengo.<\/strong> Le librerie indispensabili e con una community forte alle spalle. Indispensabile vuol dire che risolve un problema che non voglio risolvere io, con una complessit\u00e0 reale. Community forte vuol dire che c’\u00e8 gente che la usa in produzione, che i bug li trova qualcun altro prima di me, che gli aggiornamenti di sicurezza arrivano.<\/p>\n\n\n\n

Cosa sostituisco.<\/strong> Le librerie il cui rapporto tra casi d’uso offerti e casi d’uso necessari \u00e8 sbilanciato. Un SDK che gestisce trecento scenari quando a me ne servono quattro non \u00e8 un acceleratore: \u00e8 un peso che mi porto dietro per sempre. E le librerie che aggiungono complessit\u00e0 per contesti che non sono i miei, il caso da manuale \u00e8 left-pad<\/code> quelle undici righe che nel 2016 ruppero mezzo npm quando l’autore le tolse dal registry. Se devo allineare una stringa e non mi servono le trentasei varianti di encoding che qualcun altro ha previsto, quel rischio di supply chain \u00e8 accettato per risparmiare tre righe.<\/p>\n\n\n\n

L’audit sul mio caso \u00e8 stato imbarazzante per la sua chiarezza. L’SDK MCP si trascinava dietro 94 pacchetti \u2014 express<\/code>, hono<\/code>, ajv<\/code>, jose<\/code>, cors<\/code>, eventsource<\/code> \u2014 per un server che usa esclusivamente il transport stdio<\/code>. Tutta quella roba serve a gestire i transport HTTP, l’autenticazione OAuth, il CORS: casi d’uso reali e legittimi, semplicemente non i miei. Mi stavo portando in giro un web server completo per far parlare due processi sulla stessa macchina attraverso standard input e standard output: l’equivalente di spedire una lettera al vicino di casa facendola passare dal centro di smistamento.<\/p>\n\n\n\n

Ho scritto due file:<\/p>\n\n\n\n