Sto osservando il nostro team di editing video presso Techstrong lavorare in modo diverso. Sempre più spesso, stanno dicendo all'IA cosa editare e come. Le decisioni che una volta richiedevano loro di eseguire manualmente una serie di operazioni possono ora essere espresse come istruzioni.

Loro sono ancora quelli che prendono le decisioni creative. Sanno cosa vogliono che il video diventi. Ma possono trascorrere più tempo a pensare a cosa vogliono creare e meno tempo a eseguire ogni aggiustamento da soli. Inoltre, stanno editando molti più video.

Questa è un'esperienza diversa da quella implicata dalla domanda familiare se l'IA sostituirà gli editor video. Nel lavoro che sto vedendo, l'IA sta espandendo ciò che i nostri editor possono fare. Il loro giudizio viene applicato a più output.

Ci ho pensato mentre leggevo l'articolo recente di Corynn Winston su CNBC riguardo agli annunci di lavoro per sviluppatori software. L'IA sta facendo più codifica, ma la domanda di sviluppatori, almeno come misurata da quegli annunci, è in ripresa.

Per chiunque equipari lo sviluppo software alla digitazione di codice, questo potrebbe sembrare contraddittorio. Per le persone che effettivamente consegnano e operano software, dovrebbe essere meno sorprendente.

Il lavoro è sempre stato più grande del codice

CNBC riporta che gli annunci di sviluppo software di Indeed negli Stati Uniti sono aumentati di quasi il 15% da fine febbraio 2025, mentre gli annunci complessivi sono diminuiti del 7%. In un periodo separato, da maggio 2025 a maggio 2026, i ruoli senior hanno rappresentato il 71% dell'aumento degli annunci di sviluppo software. Le posizioni legate all'IA hanno rappresentato il 37%, con queste categorie che potrebbero sovrapporsi.

Ci sono delle qualifiche. Gli annunci non sono assunzioni completate. Gli annunci di sviluppo software sono rimasti circa il 27,5% al di sotto del loro livello pre-pandemico. Una ripresa non stabilisce che l'IA abbia causato la crescita, tanto meno prova che tutti nella professione stiano bene.

Tuttavia, la concentrazione della domanda tra le persone esperte merita attenzione. Forse le aziende stanno scoprendo che generare un'implementazione e consegnare un sistema funzionante richiedono capacità diverse.

Il valore di uno sviluppatore esperto non è mai stato limitato al numero di righe che scrive personalmente. Molti sviluppatori senior codificano ancora estensivamente. Essi comprendono anche perché un particolare approccio fallirà, quale dipendenza rende un cambiamento apparentemente semplice rischioso e cosa il cliente intendeva quando i requisiti dicevano qualcos'altro.

L'IA può assumersi più implementazioni senza risolvere queste domande.

Lo vedo come sviluppatori che diventano più focalizzati sull'ingegneria del software. Non sto proponendo una nuova gerarchia di titoli di lavoro. Gli sviluppatori hanno sempre fatto ingegneria. L'equilibrio del loro tempo e della loro responsabilità si sta spostando verso la definizione del sistema, la direzione su come viene costruito e l'accertamento se funziona.

Una richiesta di generare una funzione è solo l'inizio. Qualcuno deve determinare come quella funzione si adatta all'architettura, quali dati può accedere, come si comporta in caso di guasto e se il suo costo continuo è accettabile. Un'implementazione può soddisfare il prompt e comunque essere sbagliata per l'azienda.

È per questo che descrivere questo lavoro come "solo prompting" manca l'esperienza dietro un'istruzione utile. I nostri editor devono sapere come appare un buon editing. Un ingegnere del software deve riconoscere cosa un'implementazione che sembra plausibile sbaglia.

Attraverso il ciclo di vita della consegna

Lo stesso spostamento si estende attraverso QA, DevOps, ingegneria delle piattaforme, SRE e sicurezza. Queste discipline coinvolgono già la progettazione di sistemi e l'esercizio del giudizio. L'automazione di più esecuzioni rende queste responsabilità più conseguenti.

Prendiamo QA. Generare e eseguire più test può aiutare, ma il volume dei test non ti dice se stai testando le cose giuste. Se un agente scrive codice basato su un'interpretazione errata di un requisito, i test generati da quella stessa interpretazione potrebbero confermare con entusiasmo l'errore.

Qualcuno deve stabilire cosa significa un comportamento corretto, quali casi di guasto contano e quali prove giustificherebbero il rilascio del software. L'esperienza in QA diventa particolarmente preziosa quando una suite di test superati crea fiducia che le ipotesi sottostanti non meritano.

Per DevOps e ingegneria delle piattaforme, la sfida è più grande che far eseguire un agente una pipeline. Dobbiamo progettare l'ambiente in cui gli agenti consegnano i cambiamenti. Quali permessi ricevono? Quali controlli sono obbligatori? Possono modificare i controlli che valutano il loro stesso lavoro? Quando un cambiamento richiede approvazione?

Una piattaforma che permette agli agenti di muoversi rapidamente senza rispondere a queste domande potrebbe accelerare la consegna di problemi. Costruire percorsi sicuri e utilizzabili per la produzione è un lavoro di ingegneria, indipendentemente dall'utente di quella piattaforma, sia una persona o un agente.

L'SRE affronta una questione simile. La diagnosi e il ripristino automatici possono essere utili, ma un sistema in grado di prendere provvedimenti ha anche bisogno di confini. Riavviare un servizio è diverso dal modificare una configurazione del database o eliminare risorse che giudica non necessarie.

Gli obiettivi di affidabilità, i meccanismi di rollback e le regole di escalation determinano quanto autonomia ha senso. Il praticante deve comprendere le conseguenze di un intervento, inclusa la possibilità che una soluzione localmente sensata crei un guasto più grande.

La sicurezza segue la stessa logica. Generare correzioni e scansionare più codice sono attività utili. Non stabiliscono, da soli, che i confini di fiducia dell'applicazione siano solidi o che i suoi controlli di accesso corrispondano al rischio aziendale.

Più codice che fluisce in questi sistemi crea più lavoro a valle. Se test, integrazione e operazioni non riescono a tenere il passo, una codifica più veloce sposta semplicemente la coda. I praticanti DevOps dovrebbero riconoscere immediatamente questo problema. Ottimizzare un'attività non garantisce una consegna migliore.

Né la risposta può essere quella di far controllare manualmente ogni riga a un umano per sempre. La verifica deve scalare. Questo significa ingegnerizzare controlli automatizzati, prove utili e meccanismi di escalation, poi valutare se questi controlli funzionano davvero.

Cosa faremo con la capacità?

È qui che diventa importante la decisione aziendale.

Un'organizzazione può guardare all'esecuzione più veloce e chiedersi quante persone servono per produrre lo stesso output. Può anche chiedersi cosa potrebbero realizzare le sue persone con il tempo che recuperano.

Presso Techstrong, vedo i nostri editor produrre più video e avere più spazio per decisioni creative. Entrambe le cose contano. La capacità aggiuntiva cambia ciò che è possibile per il team.

Le organizzazioni software hanno le loro candidate per quella capacità. Ci sono strumenti interni che non vengono mai finanziati, sistemi in attesa di modernizzazione, miglioramenti di affidabilità ripetutamente rimandati e richieste dei clienti che non possono competere con il backlog esistente.

Rendere lo sviluppo meno costoso potrebbe rendere alcuni di questi lavori pratici.

C'è una possibilità di stile Jevons qui: quando qualcosa diventa più economico da produrre o utilizzare, la domanda può espandersi. Un'azienda che poteva giustificare cinque progetti software potrebbe essere in grado di giustificarne di più quando i costi di implementazione diminuiscono.

Questo non garantisce più posti di lavoro per gli sviluppatori. L'output potrebbe aumentare mentre l'occupazione diminuisce. La domanda potrebbe non espandersi abbastanza da assorbire la capacità, o altri costi potrebbero limitare il beneficio. Alcuni datori di lavoro perseguiranno riduzioni del personale.

Ma assumere una quantità fissa di lavoro software è anche una scelta, e spesso un punto di partenza povero. Il backlog non è necessariamente l'estensione completa della domanda. Include ciò che le persone credevano fosse abbastanza fattibile da richiedere.

La domanda di gestione è quanto valore l'organizzazione può creare con le sue capacità, non semplicemente quanto economicamente può riprodurre l'output dell'anno scorso.

Un modello oltre il software

Sospetto che vedremo versioni di questo in altre professioni. Il lavoro di un commercialista include interpretare eccezioni e consigliare un'azienda, oltre a riconciliare transazioni. Il marketing richiede decidere cosa comunicare e a chi, oltre a produrre asset di campagna. Il giornalismo richiede scoprire cosa sta succedendo e perché.