L'ingegneria del software è morta. È questo che le voci più rumorose di tech Twitter vogliono farti credere. Condividono registrazioni dello schermo di strumenti di IA che creano intere applicazioni partendo da un singolo paragrafo di prompt e si chiedono perché qualcuno dovrebbe ancora pagare un essere umano per scrivere codice. Il panico è comprensibile, ma manca completamente il punto.
L'IA non sta arrivando per gli ingegneri. Sta arrivando per chiunque scambi la velocità di digitazione con il giudizio tecnico. C'è un enorme divario tra il programmare e l'ingegneria, e quel divario è il luogo in cui risiede l'intera professione.
Un assistente IA può fornirti cinque modi diversi per implementare una funzionalità prima che tu abbia finito di sorseggiare il caffè. Il collo di bottiglia si è spostato. Non fissiamo più un file vuoto chiedendoci come iniziare. Fissiamo cinque soluzioni plausibili chiedendoci quale non crollerà nel momento in cui arriverà il traffico reale. Quella decisione è ingegneria. Tutto il resto è solo sintassi.
La demo non è il prodotto
Guarda qualsiasi demo di coding con IA e vedrai un'interfaccia bellissima prendere forma in pochi minuti. Ciò che non vedrai è il database connection pool che si esaurisce sotto carico. Non vedrai la mancanza di rate limit su un endpoint API, l'assenza di audit log o i costi di archiviazione derivanti dal log di ogni interazione dell'utente in un object bucket perché l'IA ha pensato che fosse un posto comodo dove scaricare lo stato.
I sistemi di produzione richiedono scalabilità, sicurezza, prestazioni e controllo dei costi. Queste qualità sono invisibili in una sprint review. Si rivelano solo quando arrivano gli utenti reali con il loro comportamento imprevedibile, i loro casi limite e il loro rifiuto di cliccare i pulsanti nell'ordine previsto. Ho visto troppi progetti assistiti dall'IA che sembravano perfetti in QA trasformarsi in costose lezioni la settimana successiva al lancio.
Il codice funzionante è diventato economico. La buona ingegneria no.
Ciò che conta ora
Gli ingegneri che stanno prosperando in questo cambiamento non sono quelli che digitano più velocemente. Sono quelli che sanno quali domande porre prima che venga generata una singola riga di codice.
Definiscono i problemi in modo chiaro. Un modello di IA risolverà volentieri il problema sbagliato se glielo permetti. Costruirà un complesso livello di caching per una dashboard read-heavy utilizzata solo da sei analisti interni. Non si fermerà a chiedere se il problema reale sia un indice del database mancante o un modello dati fondamentalmente errato. Un ingegnere esperto riformula il problema finché la soluzione non diventa ovvia, che tale soluzione preveda o meno del codice.
Scompongono i grandi sistemi in piccoli pezzi. L'IA eccelle nel contesto locale. Può scrivere una singola funzione, un singolo componente, un singolo test. Fatica a mantenere in memoria un'intera architettura distribuita. Gli ingegneri capaci di decomporre un monolite, tracciare confini attorno ai servizi e definire contratti tra i team sono quelli che trasformano gli snippet generati in sistemi sostenibili.
Mettono in discussione i suggerimenti dell'IA. La sicurezza del modello è un miraggio. Proporrà architetture che ignorano la latenza di rete, raccomanderà librerie deprecate da anni o risolverà funzionalità che in realtà non esistono nei requisiti.