Simon Willison cita D. Richard Hipp, e l’analogia con SQL mette in discussione le previsioni sull’occupazione nell’IA

Simon Willison ha messo in evidenza l’analogia con SQL di D. Richard Hipp il 29 luglio, contrapponendo una sfida storica alle previsioni secondo cui l’IA eliminerà i programmatori. L’argomento di Hipp parte da un precedente cambiamento nel lavoro. SQL ha automatizzato attività che in passato venivano svolte tramite programmi personalizzati per l’elaborazione dei dati, eppure la programmazione è sopravvissuta e si è espansa assumendo forme diverse.

Il post è breve, ma il suo tempismo è importante. I sistemi di programmazione con IA generano ormai funzioni, test, query, documentazione e talvolta modifiche coordinate tra repository. Questo progresso ha incoraggiato un’affermazione più forte: una volta che le persone potranno descrivere il software in linguaggio naturale, alle organizzazioni serviranno molti meno programmatori.

Hipp propone un modello meno drammatico. Le nuove astrazioni riducono il costo di esprimere alcune istruzioni, per poi spostare lo sforzo umano verso specifiche, verifica, architettura e manutenzione. SQL non ha posto fine alla programmazione. Ha cambiato quali problemi meritassero codice personalizzato e quali potessero essere delegati a un motore di database.

Quell’analogia non dimostra che l’IA seguirà lo stesso percorso. I modelli linguistici di grandi dimensioni producono output probabilistico, mentre un database esegue SQL secondo regole definite. Il confronto offre comunque un test utile per le affermazioni sulle carriere nel software: uno strumento elimina il lavoro ingegneristico oppure lo sposta a un altro livello?

Simon Willison trasforma una citazione in un argomento sul mercato del lavoro

La notizia non è una nuova funzionalità di SQLite o un prodotto di IA. È una cornice storica più nitida per valutare le affermazioni sull’automazione.

Nel suo post del 29 luglio, Simon Willison ha citato D. Richard Hipp mentre descriveva come il lavoro sui dati sia cambiato con l’arrivo di SQL. Prima di SQL, le organizzazioni pagavano spesso programmatori affinché creassero software procedurale in grado di cercare, unire, filtrare e riassumere grandi insiemi di dati.

Hipp ha identificato questi lavoratori, con una certa semplificazione, come programmatori COBOL. SQL consentiva a un utente di specificare il risultato desiderato attraverso una query compatta. Il motore di database generava o selezionava quindi gran parte della logica di esecuzione che in precedenza era contenuta nei programmi personalizzati.

La frase chiave nel confronto di Hipp è che i programmatori non sono scomparsi. Il loro lavoro è cambiato.

La distinzione può sembrare modesta, ma incide su una delle principali ipotesi alla base delle attuali previsioni sull’occupazione nell’IA. Molte previsioni trattano la produzione di codice come l’unità definitoria del lavoro di programmazione. Se il software può produrre codice, secondo questo ragionamento, il lavoratore che prima lo digitava diventa superfluo.

SQL suggerisce che il volume di codice e il valore ingegneristico non siano la stessa cosa. Una query dichiarativa può sostituire molte righe di codice procedurale per la gestione dei dati. Eppure qualcuno deve ancora definire i dati, decidere cosa significhi il risultato, gestire le autorizzazioni, testare i casi limite, monitorare le prestazioni e intervenire quando i requisiti entrano in conflitto.

La programmazione dichiarativa significa specificare il risultato che un sistema dovrebbe produrre senza descrivere ogni singolo passaggio di esecuzione. SQL ne è diventato l’esempio principale perché gli utenti dichiarano quali dati desiderano. Un pianificatore di query sceglie come il database debba recuperarli.

Hipp ha già sottolineato questa distinzione. In un profilo sul database, ha sostenuto che molti sviluppatori sottovalutano quanto lavoro possa far risparmiare un linguaggio dichiarativo. Ha citato codice applicativo che esegue manualmente join che il database potrebbe gestire.

Questa osservazione si collega direttamente alla programmazione con IA. Uno sviluppatore può ora chiedere a un assistente di implementare una funzionalità senza inserire manualmente ogni istruzione. La richiesta comprime lo sforzo visibile, così come una query SQL comprime le operazioni procedurali sui dati.

La compressione è reale. La scomparsa della responsabilità non lo è.

Un utente SQL resta responsabile di richiedere il risultato corretto. Uno sviluppatore assistito dall’IA resta responsabile di determinare se il software generato corrisponde al comportamento previsto. In entrambi i casi, l’interfaccia si sposta verso l’alto, mentre decisioni importanti restano nelle mani delle persone.

La scelta di Willison attribuisce all’analogia di Hipp un significato più ampio. Trasforma un commento sulla storia di SQL in una risposta all’idea che la programmazione in linguaggio naturale crei automaticamente un futuro senza programmatori.

Il post evita anche una facile conclusione anti-IA. Hipp non sostiene che l’automazione non realizzi nulla. SQL ha chiaramente eliminato la necessità di scrivere manualmente alcuni programmi. L’analogia accetta notevoli guadagni di produttività, respingendo però un percorso diretto dalla produttività all’estinzione di una professione.

Questa è la tensione centrale dell’evento. La stessa storia può sostenere due letture. L’automazione elimina compiti specifici, ma rende anche la creazione di software abbastanza economica da generare maggiore domanda di software.

SQL ha cambiato l’unità di lavoro

SQL non ha preservato ogni attività di programmazione. Ha reso molte di queste attività economicamente non necessarie e ha spostato l’attenzione verso decisioni di livello superiore.

Prima dei database relazionali e dei linguaggi di query ampiamente adottati, ottenere una nuova risposta dai dati aziendali poteva richiedere un programma dedicato. Un programmatore doveva comprendere layout dei record, percorsi di accesso, routine di ordinamento, formati di file e requisiti di reporting.

Una piccola modifica a una domanda poteva richiedere un altro programma o una revisione significativa. L’organizzazione pagava per una procedura, non semplicemente per un risultato.

SQL ha modificato questa impostazione. Un utente poteva descrivere un risultato usando selezioni, join, raggruppamenti e ordinamenti. Il database traduceva quella richiesta in un piano di esecuzione, ovvero l’insieme di operazioni utilizzate per restituire i dati richiesti.

L’analogia di Hipp comprime una lunga storia tecnica, come egli stesso riconosce nell’impostazione della citazione. COBOL non è scomparso con l’arrivo di SQL. I sistemi COBOL hanno inoltre continuato a gestire carichi di lavoro relativi a stipendi, banche, assicurazioni, amministrazioni pubbliche ed elaborazione delle transazioni.

Il cambiamento importante era più circoscritto. Le organizzazioni non avevano più bisogno di un nuovo programma procedurale per ogni domanda ordinaria che una query relazionale potesse esprimere.

Si tratta di una forma significativa di sostituzione del lavoro a livello di compito. Uno strumento può eliminare ore di implementazione specializzata senza eliminare la professione che include quel compito.

La distinzione tra lavori e compiti si perde spesso nei dibattiti sull’IA. Un lavoro è un insieme di attività, responsabilità, conoscenze di dominio, comunicazione e decisioni. L’automazione raramente raggiunge tutte le parti di questo insieme con la stessa velocità.

SQL ha automatizzato l’esecuzione delle query, ma ha creato domanda per amministrazione di database, progettazione degli schemi, ottimizzazione delle query, modellazione dei dati, analisi, sicurezza e integrazione applicativa. Ha anche reso pratico l’accesso ai dati per molti più team.

Hipp ha descritto il valore duraturo di SQL attraverso tre idee: transazioni, astrazione dei dati e linguaggio dichiarativo. In un’intervista su SQLite del 2024, ha affermato che il modello relazionale rimane efficace per rappresentare molti problemi del mondo reale.

Le transazioni garantiscono che operazioni di database correlate vengano completate secondo regole controllate di coerenza. L’astrazione dei dati separa una richiesta logica dai dettagli dell’archiviazione fisica. Il linguaggio dichiarativo consente all’utente di concentrarsi sulla risposta desiderata.

Insieme, queste capacità hanno fatto più che far risparmiare battiture. Hanno ridistribuito le competenze tra il programmatore applicativo, il motore di database, lo specialista di database e l’utente aziendale.

Gli assistenti di programmazione con IA stanno avviando una redistribuzione simile, anche se il loro meccanismo è diverso. Possono tradurre l’intento in codice, cercare in repository sconosciuti, proporre test, spiegare funzioni legacy e produrre bozze di migrazioni o documentazione.

Con il miglioramento di queste capacità, i team dedicheranno meno tempo alla scrittura di codice di implementazione ordinario. Questo risultato non va attenuato. Alcuni compiti entry-level, incarichi di manutenzione e lavori di programmazione esternalizzati subiranno una pressione diretta.

Tuttavia, lo sforzo risparmiato non dice cosa accadrà all’occupazione totale. Costi di produzione inferiori possono ridurre la domanda di lavoro quando la quantità di output desiderato resta fissa. Possono aumentare la domanda di lavoro quando una produzione più economica sblocca molti più progetti.

Il software raramente si è comportato come un mercato fisso. I team mantengono lunghi backlog, rinviano strumenti interni, tollerano flussi di lavoro manuali e posticipano integrazioni perché la capacità ingegneristica è limitata. Se l’IA riduce il costo di questi progetti, le organizzazioni possono realizzarne di più.

Il precedente di SQL presenta quindi tre effetti contemporaneamente:

• Sostituzione: il sistema esegue lavoro precedentemente assegnato a un programmatore.

• Espansione: costi inferiori rendono economicamente vantaggiosi ulteriori lavori su software e dati.

• Ricomposizione: i ruoli rimanenti attribuiscono maggiore peso al giudizio, alla progettazione, alla revisione e alla conoscenza del dominio.

Questi effetti non si bilanceranno allo stesso modo in ogni azienda. Un’impresa con un prodotto stabile e una roadmap fissa potrebbe usare l’IA per ridurre le assunzioni. Un’azienda in crescita potrebbe mantenere stabile l’organico rilasciando più funzionalità. Una piccola organizzazione potrebbe iniziare a sviluppare software che in precedenza non poteva permettersi.

Questa variazione spiega perché le affermazioni generiche sul “programmatore” siano deboli. L’automazione raggiunge compiti specifici all’interno di organizzazioni specifiche. I suoi effetti sull’occupazione dipendono dalla domanda, dai budget, dal rischio e dalla quantità di nuovo lavoro creato.

Il vero avversario è l’automazione dei compiti contro l’eliminazione dei posti di lavoro

La sfida principale di Hipp non è rivolta agli strumenti di programmazione con IA. È rivolta all’ipotesi che automatizzare la generazione di codice elimini l’intero ruolo ingegneristico.

Una funzione generata può sembrare lavoro completato. Arriva rapidamente, nei casi favorevoli viene compilata e può superare i test forniti al modello. Questo output visibile incoraggia le persone a equiparare l’implementazione all’intero ciclo di vita del software.

L’ingegneria in produzione comprende molto di più. Qualcuno deve trasformare una richiesta ambigua in un comportamento preciso. Quella persona deve risolvere conflitti tra stakeholder, individuare requisiti mancanti, scegliere i confini del sistema, proteggere i dati e decidere quali guasti siano accettabili.

Il team deve inoltre mantenere il risultato dopo che il suo contesto originario è cambiato. Le dipendenze ricevono aggiornamenti. Le normative cambiano. Gli utenti scoprono flussi di lavoro imprevisti. Gli aggressori cercano vulnerabilità. I volumi di dati crescono oltre le ipotesi incorporate nella prima versione.

L’IA può assistere in ciascuna attività, ma l’assistenza non trasferisce automaticamente la responsabilità. Quando il codice generato provoca un incidente di sicurezza, clienti e autorità di regolamentazione non considerano il modello come l’operatore responsabile.

Il confronto con SQL rende più facile vedere questo confine. Un motore di database può scegliere un piano di esecuzione, ma non decide se una query risponde alla corretta domanda aziendale. Non può determinare se un join tecnicamente valido produca una metrica fuorviante.

Allo stesso modo, un assistente IA può produrre un’implementazione senza sapere se la specifica riflette le esigenze reali dell’organizzazione. Più l’implementazione diventa automatizzata, più la qualità della specifica determina il risultato.

Questo crea un’importante inversione. Il linguaggio naturale sembra più semplice del codice, ma il linguaggio ordinario tollera ambiguità che il software non può ignorare in sicurezza.

“Aggiungi la gestione automatica delle imposte” sembra chiaro finché il sistema non deve affrontare giurisdizioni, esenzioni, rimborsi, regole di arrotondamento, date di entrata in vigore e dati incompleti dei clienti. Tradizionalmente, un ingegnere umano scopre e formalizza questi dettagli durante la progettazione e l’implementazione.

Se un agente di IA scrive il codice, quelle domande non scompaiono. Si spostano nei prompt, nelle specifiche, nei test, nei documenti di policy, nelle sessioni di revisione o negli incidenti di produzione.

Un'analisi del giugno 2026 sul futuro senza codice ha sostenuto un'argomentazione correlata. Ha descritto l'IA come un ulteriore passo nell'astrazione della programmazione, osservando al contempo che specifiche precise continuano a fungere da codice, indipendentemente dal loro formato superficiale.

È qui che l'analogia di Hipp con SQL risulta più forte. SQL ha successo perché il suo ambito dichiarativo è circoscritto. Il database comprende tabelle, relazioni, predicati, raggruppamenti, ordinamenti e transazioni secondo una semantica formale.

I requisiti del software generalista non arrivano con confini equivalenti. Mescolano comportamento tecnico con policy, estetica, incentivi organizzativi, obblighi legali e assunzioni che le parti interessate potrebbero non esplicitare mai.

Un agente di coding basato sull'IA può dedurre dettagli mancanti. Questa flessibilità è utile, ma introduce anche rischi. Un requisito dedotto può essere plausibile e tuttavia errato.

Anche i motori SQL producono piani indesiderabili, soprattutto quando statistiche, indici o assunzioni sul carico di lavoro sono inadeguati. Il loro output resta governato da una semantica deterministica dei database. Un modello linguistico di grandi dimensioni può generare implementazioni diverse a partire da prompt simili e può inventare API o assunzioni.

Pertanto, il coding con IA non è semplicemente «SQL per tutto il software». È un'interfaccia più flessibile e più ambiziosa.

L'analogia funziona a livello economico perché entrambe le tecnologie comprimono lo sforzo di implementazione. Diventa più debole sul piano dell'affidabilità, perché la generazione di codice generale ha uno spazio di output molto più ampio.

Questa differenza aumenta il valore della verifica. Gli sviluppatori hanno bisogno di test che coprano comportamenti significativi, pratiche di revisione che esaminino sicurezza e manutenibilità, e osservabilità che renda evidenti i guasti dopo il rilascio.

I team hanno inoltre bisogno di contesto durevole. Requisiti, decisioni architetturali, cronologie degli incidenti e vincoli di dominio devono restare accessibili quando un agente o un ingegnere modifica un sistema. Una base di conoscenza tecnica ricercabile può supportare questo lavoro, soprattutto quando le modifiche generate coinvolgono repository poco familiari.

Il ruolo risultante può comportare meno inserimento manuale di codice. Continua tuttavia ad assomigliare all'ingegneria, perché richiede formalizzazione, validazione, compromessi e responsabilità.

Dove si rompe l'analogia con SQL

SQL offre un utile precedente sul lavoro, ma non può stabilire con quale rapidità migliorerà l'IA né quante posizioni di programmazione le aziende manterranno.

Le analogie storiche selezionano somiglianze nascondendo al contempo le differenze. SQL è stato progettato per una specifica famiglia di operazioni sui dati. La sua sintassi e la sua semantica hanno creato un contratto stabile tra chi formula una query e il database che la esegue.

I sistemi di coding con IA operano attraverso linguaggi, framework, repository, interfacce e domini aziendali in evoluzione. Incontrano spesso documentazione incompleta e convenzioni contraddittorie. Il loro compito non consiste soltanto nell'ottimizzazione all'interno di un modello formale.

Questo ambito più ampio può rendere l'IA economicamente più significativa di SQL. Un agente che esplora un repository, modifica più servizi, esegue test e risponde ai fallimenti copre una porzione maggiore del flusso di sviluppo rispetto a quella coperta da un pianificatore di query.

Lo stesso ambito può anche rendere più difficile un'automazione affidabile. Il successo in un benchmark circoscritto non dimostra prestazioni sicure all'interno di un sistema di produzione di lunga durata.

Una modifica generata può superare i test unitari pur violando un'assunzione operativa non documentata. Può ripetere un modello insicuro già presente nel repository. Può risolvere il ticket visibile aumentando però i futuri costi di manutenzione.

Anche gli sviluppatori umani commettono questi errori. La domanda pertinente è se l'IA ne modifichi frequenza, rilevabilità e scala.

La velocità può amplificare sia il buon output sia quello cattivo. Se un team produce cinque volte più modifiche, perfino un tasso di errore inferiore per modifica potrebbe creare più lavoro di revisione complessivo. Al contrario, test automatizzati efficaci potrebbero permettere al team di aumentare l'output senza incrementare i fallimenti.

Questa incertezza indebolisce le previsioni sicure da entrambe le parti. È prematuro dichiarare sicuri i lavori di programmazione perché SQL non li ha eliminati. È altrettanto prematuro dedurre un'eliminazione di massa da dimostrazioni impressionanti di generazione del codice.

I commenti pubblici dello stesso Hipp mostrano una posizione prudente sul coding completamente autonomo. Nell'intervista del 2024, ha definito l'IA utile ma sopravvalutata e ha affermato che il coding assistito sembrava più probabile della generazione di codice completamente automatica.

Quella previsione resta un punto di vista, non un risultato misurato. Le capacità dell'IA e la progettazione dei prodotti continuano a cambiare, mentre le organizzazioni stanno ancora imparando come distribuire gli agenti all'interno di processi di sviluppo controllati.

Anche le categorie professionali possono sopravvivere diventando però più piccole o più difficili da raggiungere. Il settore bancario impiega ancora specialisti COBOL, ma questo non significa che COBOL offra lo stesso percorso professionale di un tempo. Una tecnologia può preservare competenze critiche riducendo al contempo il numero di persone che svolgono attività di routine.

I ruoli junior meritano particolare attenzione. Gli ingegneri senior hanno spesso imparato attraverso piccole correzioni di bug, integrazioni lineari, scrittura di test e lavoro su funzionalità supervisionato. Sono proprio i compiti che gli attuali assistenti di coding gestiscono bene.

Se le aziende automatizzano questo lavoro senza riprogettare la formazione, potrebbero indebolire il percorso che produce i futuri ingegneri senior. SQL ha creato nuove specializzazioni, ma non ha risposto a come un team fortemente basato sull'IA dovrebbe sviluppare il giudizio delle persone che non praticano più così spesso l'implementazione di base.

Un'altra incertezza riguarda il comportamento organizzativo. I guadagni di produttività non devono necessariamente tradursi in ulteriore software. I dirigenti possono acquisirli attraverso organici ridotti, obiettivi di output più elevati, tempi più brevi o una combinazione di questi fattori.

La distribuzione conterà quanto la capacità tecnica. Gli sviluppatori potrebbero usare l'IA per controllare sistemi più grandi e affrontare problemi trascurati. Potrebbero anche trovarsi di fronte a carichi di lavoro intensificati, perché il management considera ogni risparmio di tempo come capacità aggiuntiva permanente.

L'analogia di Hipp non risolve questo conflitto. Lo chiarisce.

La domanda non è se l'IA automatizzi compiti di programmazione. Lo fa già. La domanda è chi controlla il tempo risparmiato, quali responsabilità restano umane e se la crescente domanda di software assorbe il lavoro spostato.

Il coding con IA cambia le competenze che le aziende acquistano

Man mano che l'implementazione diventa meno costosa, le organizzazioni attribuiscono maggiore valore alle persone capaci di definire risultati corretti e individuare errori convincenti.

La transizione a SQL ha premiato le persone che comprendevano i modelli di dati e le domande aziendali, non soltanto coloro che conoscevano la sintassi delle query. Il coding con IA dovrebbe produrre un premio simile per la comprensione del dominio, la progettazione dei sistemi, i test e il giudizio operativo.

La sola scrittura di prompt difficilmente diventerà una competenza sostitutiva durevole. I prompt sono interfacce, e le interfacce diventano più semplici con la maturazione dei prodotti. La capacità più rara è riconoscere quando una risposta plausibile non soddisfa il requisito reale.

Per gli sviluppatori, questo significa comprendere il sistema oltre il diff generato. Devono tracciare il movimento dei dati, identificare i confini di fiducia, valutare le modalità di guasto e collegare le modifiche al codice alle conseguenze per gli utenti.

Leggere il codice potrebbe diventare più importante anche se scriverlo diventa meno centrale. Gli ingegneri devono ispezionare output poco familiari e determinare se rispettano le convenzioni locali. Hanno inoltre bisogno di conoscenze fondamentali sufficienti a riconoscere difetti sottili.

Anche i test cambiano. I test generati possono ampliare la copertura, ma un modello può riprodurre lo stesso fraintendimento sia nel codice sia nei test. I team hanno bisogno di criteri di accettazione indipendenti e di test basati sul comportamento desiderato, non soltanto sull'implementazione generata.

L'architettura diventa un ulteriore punto di pressione. I sistemi di IA possono proporre modelli familiari, ma un modello familiare non è sempre appropriato. Le decisioni su confini dei servizi, coerenza, latenza, conservazione dei dati e complessità operativa riflettono vincoli specifici.

Gli esperti di dominio acquisiscono influenza perché possono fornire un contesto che il modello non possiede. Un flusso di lavoro sanitario, un sistema di riconciliazione finanziaria o un controllore industriale contengono regole che non possono essere recuperate in modo affidabile da dati di addestramento generici.

Questo non significa che ogni sviluppatore diventi un architetto. Significa che il centro economico del ruolo si sposta verso la selezione, il vincolo e la validazione del lavoro automatizzato.

Alcuni lavori si restringeranno. I team potrebbero aver bisogno di meno persone per conversioni ripetitive, strutture di base delle interfacce o generazione di test di routine. I contractor che vendono volume di implementazione potrebbero subire pressioni sui prezzi quando i clienti possono produrre internamente prime bozze accettabili.

Altri lavori si espanderanno attorno all'integrazione e all'assurance. Le organizzazioni hanno bisogno di persone che colleghino sistemi di IA a repository privati, controllino i permessi degli strumenti, valutino l'output, mantengano l'infrastruttura di sviluppo e indaghino sui fallimenti.

La modernizzazione dei sistemi legacy illustra l'effetto misto. I ricercatori IBM hanno descritto l'uso di modelli addestrati sui pattern COBOL aziendali per supportare la traduzione in Java. Il loro lavoro di modernizzazione dipende ancora dalla comprensione di CICS, Db2, VSAM, IMS e del comportamento aziendale incorporato nei vecchi sistemi.

La traduzione non equivale alla sostituzione. Un sistema può contenere decenni di decisioni non documentate. Produrre sintassi Java non dimostra che il nuovo programma preservi ogni comportamento richiesto.

Il programmatore COBOL esperto potrebbe scrivere a mano meno routine di migrazione. La conoscenza di quella persona diventa più importante durante la validazione, perché il modello non dispone di contesto storico e istituzionale.

SQL ha creato una divisione comparabile. Il motore di query ha automatizzato la selezione degli algoritmi, ma i carichi di lavoro difficili richiedevano comunque persone che comprendessero schemi, indici, statistiche e comportamento delle applicazioni.

Il coding con IA spinge quindi gli sviluppatori a salire di livello senza perdere il contatto con l'implementazione. Un revisore che non sa ragionare sul codice diventa dipendente dallo stesso sistema che sta revisionando.

Anche le aziende affrontano una sfida gestionale. Devono distinguere una produzione di codice più rapida da una consegna più rapida di risultati affidabili. Se revisioni, controlli di sicurezza, decisioni degli stakeholder o processi di distribuzione restano vincolati, il codice generato può accumularsi senza migliorare il valore per il cliente.

Le metriche basate sulle righe di codice o sui ticket completati diventano ancora meno utili. I team dovrebbero esaminare il lead time, i difetti sfuggiti, la frequenza degli incidenti, le rilavorazioni e se le funzionalità rilasciate risolvono il problema previsto.

Il vantaggio durevole appartiene ai team che combinano l'automazione con specifiche chiare e controlli indipendenti. Aggiungere semplicemente un assistente IA a un processo esistente non rivelerà dove dovrebbe spostarsi la responsabilità.

Cosa rende utile osservare la citazione di Simon Willison

La prossima fase dovrebbe essere giudicata attraverso prove su autonomia, domanda di software e formazione delle carriere, non attraverso il volume di codice generato.

Il primo segnale è se gli agenti di IA possano completare un lavoro di produzione prolungato con un intervento umano limitato. Le brevi dimostrazioni di coding non sono più sufficienti. Il test più rigoroso riguarda modifiche a più file, requisiti ambigui, vincoli di distribuzione, revisione della sicurezza e manutenzione dopo il rilascio.

Se gli agenti gestiscono ripetutamente questi flussi di lavoro con poche rilavorazioni e pochi difetti sfuggiti, l'analogia di Hipp con SQL si indebolisce come previsione di una sostituzione limitata dei compiti. L'IA starebbe automatizzando una quota maggiore del pacchetto di attività ingegneristiche.

Se la revisione umana resta il vincolo dominante, l'analogia si rafforza. Il lavoro si sarà spostato verso supervisione e specifica anziché scomparire.

Il secondo segnale è la domanda complessiva di software. Le aziende dovrebbero mostrare se i guadagni di produttività producono team più piccoli, arretrati più lunghi completati da team stabili, oppure un’espansione di progetti in precedenza economicamente insostenibili.

I soli dati sulle assunzioni saranno difficili da interpretare. Un’azienda può rallentare le assunzioni aumentando al contempo l’output, oppure ridurre le posizioni junior mentre compete intensamente per ingegneri esperti. La composizione dell’occupazione dirà più del dato complessivo.

Osservate quali progetti ricevono finanziamenti. La crescita di strumenti interni, software per piccole imprese, integrazioni personalizzate e miglioramenti dell’accessibilità sosterrebbe l’effetto di espansione osservato dopo precedenti astrazioni. Una concentrazione dei benefici all’interno dei prodotti esistenti sosterrebbe una sostituzione più marcata.

Il terzo segnale è la struttura del lavoro entry-level. Le organizzazioni hanno bisogno di un modo credibile per formare gli sviluppatori quando gli agenti svolgono molte delle tradizionali attività da principianti.

L’evidenza di flussi di lavoro AI supervisionati, programmi di apprendistato più solidi e valutazioni basate sul debugging o sul ragionamento sui sistemi mostrerebbe che la professione si sta adattando. Un crollo prolungato delle assunzioni junior senza una formazione sostitutiva suggerirebbe una discontinuità più profonda nelle carriere.

Questi segnali dovrebbero emergere nel tempo, non da un singolo rilascio o benchmark. I sistemi occupazionali si adattano più lentamente delle capacità dei modelli. Budget, regole di approvvigionamento, requisiti di sicurezza e architetture legacy limitano la rapidità con cui il potenziale tecnico diventa pratica operativa.

Il post di Simon Willison è importante perché Hipp offre una domanda di partenza migliore. Invece di chiedersi se l’AI possa scrivere codice, occorre chiedersi quale livello del lavoro diventi dichiarativo e quale responsabilità umana rimanga al di sopra di esso.

SQL ha reso superflua un’enorme quantità di lavoro procedurale sui dati. Ha anche consentito sistemi software più grandi, un accesso più ampio ai dati e nuove specializzazioni tecniche. Entrambi gli esiti erano veri.

La programmazione con l’AI può seguire questo schema misto, pur causando una disruption più ampia. L’implementazione di routine perderà valore. Giudizio preciso, conoscenza del dominio, verifica e responsabilità ne acquisiranno.

Gli sviluppatori dovrebbero rispondere verificando dove l’AI elimini davvero il lavoro e dove invece nasconda soltanto la complessità. I team dovrebbero documentare i vincoli che il codice generato deve rispettare, quindi misurare i risultati dopo il rilascio.

La prossima generazione di programmatori assomiglierà agli utenti SQL che impartiscono comandi a un motore di esecuzione più capace, oppure a revisori che supervisionano sistemi che non comprendono più pienamente? La risposta dipenderà da quanto deliberatamente le aziende preserveranno verifica, apprendimento e responsabilità mentre l’automazione avanza.