Angolo

Un bug circoscritto, un endpoint semplice, uno script, un test standard, un refactor modesto: questi compiti non si limitavano a tenere occupati gli sviluppatori junior di un team, li fabbricavano — e sono esattamente quelli che un assistente di sviluppo produce meglio. L'accelerazione, quindi, non toglie prima di tutto posti di lavoro: toglie tre meccanismi con cui un team software riproduceva la propria competenza. Il costo del codice, che imponeva di capire prima di andare avanti; le dimensioni ridotte del sistema, che mantenevano l'errore analizzabile e quindi formativo; il primo gradino, che esponeva un principiante alla resistenza del reale senza mettere a rischio il prodotto. Nessuno dei tre era una pratica decisa — erano effetti collaterali di una lentezza che nessuno ha mai avuto motivo di difendere —, ed è per questo che niente li sostituisce da solo quando quella lentezza viene meno. Ciò che li sostituisce si decide e si mette per iscritto: non fare il merge di codice che nessuno sa spiegare, legare i test alle esigenze funzionali, tenere un catalogo dei pattern autorizzati, trattare un risultato sbagliato dell'assistente come una direttiva mancante, e giudicare il sistema da ciò che se ne saprebbe ricostruire più che da ciò che mostra sullo schermo.

Sintesi

Il primo contributo di queste note, lette insieme, è separare ciò che la discussione corrente confonde: il degrado del codice e il degrado della competenza. Il primo è antico e l'assistente ne cambia solo il ritmo; il secondo è nuovo, ed è quello per cui non esiste un rimedio noto.

I tre meccanismi perduti non sono tre esempi dello stesso fatto: formano una catena. Il costo del codice produceva comprensione nel momento stesso in cui si produceva; le dimensioni contenute del sistema rendevano l'errore riconducibile a una decisione, quindi sfruttabile a posteriori; i compiti d'ingresso fornivano le occasioni di errore stesse. Se si elimina il primo, il sistema cresce più in fretta del ciclo di apprendimento e il secondo cade con lui. Se si elimina il terzo, non resta più niente da analizzare. L'accelerazione colpisce dunque la catena in tutti e tre gli anelli insieme, e con lo stesso colpo.

A questo si aggiunge una pressione che non è tecnica. Il tempo di apprendimento non è cambiato di durata, ma tutto ciò che lo circonda ha accelerato: il suo prezzo relativo è schizzato in alto, e ogni scelta locale privilegia ormai la via rapida senza che nessuna decisione abbia soppresso la formazione. È questo che rende la perdita invisibile — non si constata da nessuna parte, si accumula.

L'ultimo tassello guarda avanti e sposta la posta in gioco fuori dal team: le pratiche di un mestiere non si deducono dalla rilettura delle precedenti, nascono da un terreno che resiste. Idempotenza, retry, circuit breaker, osservabilità sono venuti da guasti e migrazioni subiti, non da un catalogo riletto. Una generazione che non affronta più direttamente la resistenza eredita i pattern esistenti senza i mezzi per inventarne altri.

Resta ciò che queste note propongono in risposta, e che ha una sua coerenza: ogni contromisura reinstalla esplicitamente uno dei meccanismi caduti. La ricostruibilità rende verificabile la comprensione che il costo del codice garantiva di riflesso. Il rifiuto di fare il merge di codice non spiegato mette un prezzo immediato su ciò che il debito di comprensione farebbe pagare più tardi. Il catalogo di pattern ripristina il vincolo di omogeneità che la lentezza imponeva per semplice fatica di reinventare tutto. L'analisi dei risultati sbagliati trasforma il fallimento in apprendimento invece che in una correzione usa e getta. E la difficoltà reintrodotta di proposito — dojo senza assistente, revisioni in cui il codice si spiega da sé — si fa carico di ciò che le altre non coprono: una competenza di cui l'uso quotidiano non ha più bisogno si spegne se niente la sollecita.

Tensioni / contraddizioni

Queste note non concordano sull'ineluttabilità della perdita. Quelle che descrivono la catena spezzata presuppongono che l'apprendimento passasse dalla produzione; quelle che sfumano ricordano che un assistente usato come tutor — spiegare, confrontare, far verbalizzare, simulare una revisione — insegna una parte di ciò che insegnava il primo gradino. Se questa sostituzione funziona davvero, la catena non è spezzata, è spostata. Niente qui permette di decidere, e la divergenza riguarda la parte dell'apprendimento che richiede di essere stati responsabili del risultato.

Secondo disaccordo, economico: l'accelerazione finanzia anche ciò che minaccia, perché il tempo guadagnato sulla produzione potrebbe pagare l'apprendimento. La tesi dice che, per impostazione predefinita, quel tempo viene riassorbito da altra produzione; non dice che non possa essere destinato ad altro.

Terzo punto di attrito, questa volta interno: il ciclo breve che queste note difendono ha il suo difetto. Insegna la mossa locale e non espone mai agli effetti di sistema, che compaiono solo su larga scala e tardi. Un team che proteggesse unicamente i piccoli errori analizzabili formerebbe sviluppatori ciechi davanti a ciò che si rompe davvero in produzione.

Domande

• Quali di queste contromisure producono davvero competenza, e quali ne producono soltanto la traccia documentale? Scrivere una decisione di architettura e saperla prendere non sono la stessa cosa.
• Quale esposizione indiretta alla resistenza del terreno — il post mortem di un guasto che non si è vissuto, una traccia operativa, l'incidente pubblico di un'altra azienda — basta a far emergere un pattern nuovo, e quale trasmette solo il pattern già trovato?
• Come riconosce un team di aver superato la soglia oltre la quale nessuno sa più spiegare il sistema che mantiene, se non aspettando il guasto che glielo farà scoprire?
• In un'organizzazione che assume profili già formati, a quale livello — l'azienda, il settore, la scuola — va sostenuto il costo del primo gradino, visto che nessun attore può reclutare fuori dall'insieme a cui appartiene?