Machikoba no Techo Settembre 2026

Solo chi sa scriverlo riesce a vedere il pericolo.

Settembre. La stagione della pesca notturna al calamaro spillo (Kensaki) — uno dei segni dell'estate da queste parti — sta volgendo al termine. Chi usciva in barca di notte si sta spostando con discrezione su quello che noi chiamiamo budouika, il «calamaro uva». Vi ringraziamo di cuore per il vostro continuo sostegno.

E c'è un'altra cosa che riguarda settembre: è la stagione in cui il calamaro maori (Aori) si raduna. Quando la temperatura dell'acqua scende dal picco estivo, i pesci foraggio si animano tutti insieme. I calamari cambiano con loro, e i banchi di esemplari giovani entrano nei bassi fondali: lungo i frangiflutti le canne si piegano nelle brevi finestre dell'alba e del tramonto. È forse il periodo più emozionante dell'anno. Per chi pensa di iniziare a praticare l'eging, è anche la stagione più indulgente per cominciare.

Questo mese vorrei tornare a parlare del retro dell'officina. Il mese scorso scrivevo che, anche quando lo scrive l'IA, fermarsi a controllare è compito dell'uomo. Questo ne è il seguito. Nell'ultimo anno, usando a fondo in reparto il cosiddetto «vibe coding», ne ho sentito tanto la forza quanto un pericolo esattamente della stessa misura. E mi sono imbattuto nella domanda che immagino molti si stiano ponendo: il codice prodotto dall'IA può essere portato in reparto come una scatola nera, senza guardarci dentro?

■ Dici «vorrei una cosa così», e funziona

Vibe coding significa saltare le specifiche dettagliate: descrivi ciò che vuoi in linguaggio ordinario, lasci che sia l'IA a scriverlo e ti riprendi qualcosa che gira. Nell'ultimo anno abbiamo costruito così diversi piccoli strumenti per il reparto. O meglio: generiamo strumenti con la stessa naturalezza con cui respiriamo.

Va detto subito: è una cosa davvero potente. Ciò che prima finiva in un cassetto con un «mi piacerebbe, ma non c'è tempo per studiarlo» oggi gira il giorno stesso in cui ti viene in mente. Ciò che sarebbe partito con un preventivo di una ditta esterna prende forma nella pausa pranzo. Per una piccola officina come la nostra non c'è cambiamento più gradito.

■ Una cosa è che giri, un'altra che sia corretta

Eppure la cosa più spaventosa di quest'anno è stata proprio che gira. Quello che esce di solito funziona. La schermata è pulita, i numeri compaiono. Proprio perché gira, da fuori non si capisce se sia solido o pericoloso.

Un arrotondamento leggermente diverso in un punto. Comportamento indefinito quando arriva un valore fuori dall'intervallo previsto. Errori inghiottiti in silenzio, così che tutto prosegue come se nulla fosse. Niente di tutto questo si vede fissando una schermata che funziona. Lo vede soltanto chi quel tipo di codice l'ha scritto di persona e ci si è bruciato.

Alla fine non si sta tranquilli finché non si è seguito tutto il codice uscito. Il tempo che avresti dovuto risparmiare delegando ti torna indietro tale e quale sotto forma di lettura. La soglia per costruire si è abbassata enormemente; quella per accorgersi del pericolo no. Questa asimmetria è la cosa più nitida che ho imparato quest'anno. Detto nei nostri termini, sarebbe come stare davanti a un centro di lavoro da 40 milioni di yen e dire «ha girato, quindi va bene». Una cosa mai ammissibile.

■ In una piccola officina non esiste il pezzo ideale

Allora è uno strumento inutilizzabile? Tutt'altro. In certe parti del nostro lavoro calza meglio di qualunque altra cosa. Ma per spiegarlo devo fare una deviazione attraverso la realtà di una piccola officina.

Nel mio caso faccio abitualmente una cosa un po' insolita: genero l'NC — il linguaggio macchina — con il vibe coding. Per scrivere il codice che produce l'NC di solito viene scelto automaticamente Python; nella maggior parte dei casi lo sostituisco con Ruby. È il mio stile.

Le moderne macchine utensili a NC sono straordinariamente precise. Dai loro un materiale ideale, una forma ideale e dimensioni ideali, e ti restituiscono una finitura che sorprende. Ma nella nostra officina quegli ideali non ci sono quasi mai. Bisogna portare a casa il risultato con quello che si ha sottomano. Il materiale non è uniforme; forma e misura cambiano ogni volta. Il presupposto stesso del «come da disegno» non è davanti a noi.

Io lo chiamo «lo spirito di farcela con quello che si ha». È la forza di una piccola officina e il nostro orgoglio, ma dal punto di vista di chi scrive un programma è una vera seccatura. Poiché le dimensioni cambiano ogni volta, non si può scrivere una procedura con i numeri fissati nel codice. Invece di «taglia questa forma a questa misura», va riscritto come «misura ciò che hai davanti e ricava da quel valore la lavorazione». In altre parole, il livello di astrazione va alzato parecchio. È la parte più difficile del programmare in una piccola officina.

■ Perfetto per adattarsi al pezzo, e per il reverse engineering

E questo modo di lavorare — adattarsi al pezzo reale — assomiglia al vibe coding in misura sorprendente. Non c'è prima una specifica perfetta; ci si avvicina all'oggetto che si ha davanti, tagliando e provando l'accoppiamento, provando e tagliando ancora. Gli fai produrre qualcosa che gira, indichi ciò che non va, glielo fai correggere e riprovi. Poiché si possono muovere le mani prima che la specifica sia fissata, si sposa benissimo con un reparto fatto di «farcela con quello che si ha».

Soprattutto, il vibe coding è un buon complemento per la parte più difficile: alzare il livello di astrazione. Gli mostri una versione con i numeri fissati nel codice e gli chiedi qualcosa che funzioni anche quando le dimensioni cambiano, e lui individua ciò che deve diventare una variabile. La parte della generalizzazione che a una persona costava giorni — trovare il punto da cui attaccare — viene spazzata via in un colpo solo. È esattamente la capacità che mancava al nostro reparto del «farcela con quello che si ha».

L'altro buon accoppiamento è il reverse engineering: sondare dall'esterno un meccanismo che non si capisce e ricostruire la logica che ci sta dietro. Per leggere formati di dati sconosciuti, o codice lungo scritto da qualcuno molto tempo fa, e capire che cosa fa, è sorprendentemente affidabile. Qui si tratta di terreno che comunque non capivamo in partenza, quindi un errore costa poco. Una volta trovato il punto da cui attaccare, il resto lo verifica una persona.

Un esempio vicino a noi: i programmi NC che i costruttori delle macchine stessi generano. Sinceramente, non mi piacciono granché. Nessuna indentazione, commenti inutili, nessun modo di leggere che cosa stiano facendo. Un programma che non si riesce a leggere è un programma che non si riesce a fermare e controllare. L'IA colma questa lacuna. Le chiedi di aggiungere indentazione e commenti perché il codice è difficile da leggere, e te lo restituisce esattamente così. Le dici che l'astrazione è troppo bassa e le chiedi di spezzarlo in subroutine, e divide il codice in blocchi dotati di senso. Stesso comportamento, ma disposto in una forma leggibile da una persona: è forse l'uso a cui ricorriamo più spesso in questo momento.

Ciò che ci dà più fastidio è che da nessuna parte è scritto su quali variabili una subroutine abbia effetti collaterali. La richiami e qualcosa cambia. Ma che cosa cambi resta ignoto finché non si è letto tutto. Fai leggere il codice all'IA e le chiedi di elencare, in un commento in testa, le variabili scritte all'interno: e lei le individua. È un lavoro su cui una persona passava mezza giornata.

Un esempio concreto. Facciamo spesso rielaborare all'IA i programmi NC della nostra elettroerosione a filo. È così comodo che per poco non mi è venuto il capogiro. Nel mondo NC, per quanto tutti lo chiamino «G-code», ogni costruttore ha le proprie abitudini di scrittura: dialetti, in pratica. Questo modello si scrive così; quell'altro vuole questo comando. Per un essere umano significa confrontare manuali e imparare sul campo.

L'IA lo deduce dallo stile del programma che le passi. Percepisce di chi siano le convenzioni seguite dal codice e scrive le aggiunte con le stesse convenzioni. Dalle in pasto anche il manuale del costruttore e comincia a usare macro specifiche di quel modello senza che nessuno glielo dica. Legge che «questa macchina mette a disposizione questa istruzione» e la scrive con la massima naturalezza. Che una conoscenza tacita, accumulata nei reparti nel corso di lunghi anni, si possa estrarre in questo modo, sinceramente, mi ha fatto venire i brividi.

Ma un programma prodotto così non lo mandiamo mai direttamente in macchina. Lo debughiamo. Va sempre sulla macchina reale, eseguito riga per riga, con i valori delle variabili e il movimento del filo controllati a vista. È qui che l'M01 (arresto opzionale) di cui scrivevo il mese scorso si guadagna il pane. Per quanto il lavoro sembri ben fatto, se manca la capacità di debuggarlo sulla macchina reale, questo strumento non si può usare. O meglio: credo che non si debba. Usato come strumento per produrre risposte corrette è pericoloso; usato come strumento per trovare il punto da cui attaccare è formidabile. Ma confermare quel punto è sempre compito dell'uomo.

■ Deve restare una scatola nera?

Il che ci riporta alla domanda iniziale. Il codice prodotto dall'IA può essere portato in reparto senza guardarci dentro? Sinceramente, distinguiamo tra i casi in cui si può e quelli in cui non si può. Per ora la linea che tracciamo passa per il punto in cui quel codice sta. Dove un errore si può notare e correggere in seguito, dove l'unica cosa che si perde è tempo, lo usiamo senza seguirlo tutto. Dove una macchina si muove, si fissano quote e si consuma materiale — dove non c'è un secondo tentativo — una persona lo legge tutto, per quanto lunga sia la strada.

La parte scomoda è che la scatola nera non è soltanto ciò che ha scritto l'IA. Il software di oggi si costruisce richiamando un gran numero di componenti: librerie pubblicate da qualcuno, da qualche parte, su GitHub e altrove. Proprio di recente c'è stato un grosso incidente nel mondo JavaScript. (In effetti, di backdoor se ne sente parlare quasi ogni giorno.) Una libreria su cui poggia moltissimo software è stata presa in mano da altri e vi è stato inserito un meccanismo che entrava in funzione all'installazione e si propagava da sé al pacchetto successivo. Pare che centinaia di pacchetti siano stati contaminati nel giro di poche ore. Poco prima si erano verificati casi di intercettazione in transito per sostituire la destinazione di un pagamento: cioè manomissione della parte che tratta il denaro.

Chiedi a un'IA «una cosa così» e naturalmente sceglierà e includerà componenti comodi. Parte della sua velocità sta proprio nel fatto che quei componenti non li scrive lei. Quello che riceviamo, allora, ha una doppia struttura: dentro la scatola scritta dall'IA viene richiamata la scatola di qualcun altro. Nessun artigiano lavora un materiale senza sapere che cosa ci sia mescolato dentro. Per il software, credo, vale lo stesso.

Questa domanda — se ci si possa fidare della scatola di qualcun altro — non è nuova. A metà degli anni Novanta, D. J. Bernstein, autore del programma di trasporto della posta qmail (che anche noi abbiamo fatto girare più di dieci anni fa), non si fidava nemmeno della libreria standard del C: i componenti che arrivano con il linguaggio e che tutti usano senza farsi domande. Nelle sue note di progetto dichiarò di aver in larga parte rinunciato alla libreria standard e di aver sostituito le parti in cui gli incidenti capitano più facilmente, come la gestione delle stringhe e della memoria, con piccoli componenti propri, sviluppati negli anni. Non arrivò a ricostruire il sistema operativo, ma su un punto fu inflessibile: tenere sotto il proprio controllo le parti pericolose.

Ciò che attraversa qmail è l'idea di ridurre il più possibile ciò di cui bisogna fidarsi. Oltre a scriversi i propri componenti, divise l'interno del programma in piccole parti per ruolo, costruite in modo che nemmeno le sue stesse parti si fidassero l'una dell'altra. Se una di esse viene presa in mano da altri, non può andare oltre. Qualcuno ci aveva già pensato fino in fondo trent'anni fa. Naturalmente non possiamo imitarlo scrivendoci da soli ogni libreria. Ma l'idea — tracciare i propri confini partendo dal presupposto che qualcosa di non affidabile finirà nel mucchio — vale tale e quale ancora oggi.

E la cosa che spaventa è che, se la scatola è troppo grande, non si torna indietro. Prendi come un unico grosso blocco qualcosa che nel profondo non capisci e, quando succede qualcosa, non riesci più a separarlo. Perciò la contromisura va presa in fase di progetto: tenerlo in una forma che si possa sempre sostituire. Questa parte può essere rimpiazzata con un'altra; togli questo componente e l'insieme continua a funzionare. Costruiscilo così e, il giorno in cui succede qualcosa, potrai buttare via soltanto quella scatola.

Ciò che serve è capacità di progetto nel senso della programmazione a oggetti. Che cosa trattare come una singola unità, che cosa esporre verso l'esterno, quanto dell'interno nascondere? Dove tracciare il confine? Quello che una volta si considerava «scrivere in modo elegante» è diventato una necessità pratica per non portarsi dentro cose pericolose. Proprio perché è l'IA a scrivere il contenuto, ciò che serve è la capacità di decidere il confine.

E questa linea, se la si lascia stare, si sposta. Dopo una serie di cose andate bene, viene inevitabilmente voglia di ingrandire la scatola. Peggio ancora: la capacità di accorgersi del pericolo si smussa esattamente in proporzione a quanto poco si scrive di persona. Questo strumento ha la proprietà che più lo si usa, meno lo si riesce a vedere in trasparenza. Perciò la linea va ritracciata dalla parte dell'uomo, non da quella dello strumento.

■ Ingegneria dei sistemi, più che programmazione

Ripensando all'anno appena passato, è qui che la mia impressione è cambiata di più: ciò che d'ora in poi sarà davvero indispensabile non è la programmazione in sé, ma l'ingegneria dei sistemi.

Decidere che cosa costruire e che cosa non costruire. Tracciare la linea tra ciò che si delega alla macchina e il punto in cui subentra il giudizio umano. Preparare, prima di costruire, il modo di tornare indietro quando smetterà di funzionare. Decidere dove risiedono i dati e chi ne è responsabile. Per quanto diventi abile, l'IA non deciderà queste cose al posto tuo: perché deciderle richiede di conoscere il lavoro in reparto.

Man mano che il tempo speso a scrivere codice diminuiva, abbiamo cominciato a dedicare tempo alla progettazione, alla gestione e al giudizio su quando fermarsi. Paradossalmente, il venir meno della fatica di scrivere ha reso molto più visibile il peso del lavoro che viene prima della scrittura.

■ Ogni fase in casa, ad Arita

In una piccola azienda, chi l'ha costruito lo usa, e quando si rompe è la stessa persona a ripararlo. Perciò «riusciamo a costruirlo?» conta molto meno di «rientra in ciò di cui possiamo prenderci cura da soli?». Tenerlo a una scala che, il giorno in cui si ferma, si possa ripristinare con le proprie forze. Non è appariscente, ma credo che sia questo il significato di una DX tagliata su misura per sé.

È esattamente la stessa storia della costruzione degli egi. I prototipi prendono forma molto più in fretta di prima. Ma la fase di verifica in mare non si può accorciare in alcun modo. Ciò che alla fine decide se una cosa è buona o no è sempre il mare. Più in fretta riusciamo a costruire, più tempo mettiamo nella verifica: è questo l'uso che abbiamo scelto.

In una piccola cittadina di provincia — Arita, nella prefettura di Saga, in Giappone — continuiamo a produrre egi internamente in ogni fase, dalla progettazione alla lavorazione degli stampi, alla produzione in serie e alla vendita. È questo che agosto mi ha fatto meditare. Componenti scritti da qualcuno da qualche parte nel mondo girano dentro la nostra officina, e un'IA legge i dialetti delle nostre macchine. In mezzo a tutto questo, che cosa va lasciato nelle mani dell'uomo? La risposta non è arrivata nemmeno a metà, ma non ho intenzione di smettere di pensarci.

■ In mare, questo mese

Settembre porta con sé una serie di nuovi colori e prodotti. Akazamurai Meteor Glow Orange è un arancione che cambia espressione tra la luminescenza fosforescente e l'illuminazione UV; l'uscita è prevista per questo mese. Anche JetChaser Purple Edition, pensato per il tip-run da riva, esce questo mese. Inoltre JetChaser size 3.0 e size 3.1 andranno in vendita generale, con spedizione prevista per fine settembre.

Quest'anno ricorre inoltre il quindicesimo anno dalla nascita del colore «Akazamurai» di EgiSharp. Alla fine del mese scorso abbiamo diffuso le immagini di un colore che ne celebra il quindicesimo anniversario. Il fatto che per quindici anni abbia continuato a essere scelto non è merito della nostra sicurezza: è la risposta data dalle persone che lo hanno usato.

Per quanto abili diventino gli strumenti, chi giudica alla fine è una persona, e ciò che decide se una cosa è buona o no è il mare. Lo terremo a mente e continueremo a costruire, un passo alla volta. Anche questo mese vi ringraziamo per il vostro sostegno.

Settembre 2026
KeyStone Corporation
Nobuhide Kanagawa, Presidente