Di Andrew Tan
Perché sto scrivendo questo
Poiché l'IA è di gran moda al momento, alcuni CTO si chiedono: "L'IA dovrebbe sostituire metà del nostro team di ingegneria dei dati?"
Questo è lo stato dell'IA nell'ingegneria dei dati in questo momento. Tutti pubblicano contenuti entusiastici. Nessuno è specifico. Quindi ecco il mio punto di vista sull'argomento:
Con cosa l'IA aiuta veramente
La generazione di SQL è la vittoria più chiara. Strumenti in stile Copilot riducono il tempo per scrivere una bozza iniziale di una query analitica del 50-70% per ingegneri con solidi fondamenti di SQL. È ancora necessario rivederla. Devi ancora sapere come dovrebbe apparire la risposta. Ma il problema della pagina bianca è scomparso.
La documentazione dello schema è notevolmente più veloce. Passare da "abbiamo 400 tabelle" a "abbiamo documentato 400 tabelle" richiedeva mesi di lavoro degli analisti. Con buoni strumenti LLM, i team possono completare questo in settimane. La documentazione non è perfetta, ma è abbastanza buona da essere utile, cosa che spesso non era prima.
L'analisi ad hoc è cambiata significativamente per i non-ingegneri. Gli analisti aziendali che erano soliti aprire ticket per "puoi scrivermi una query che…" ora possono ottenere risposte funzionanti a domande semplici da soli. Questa è vera produttività. È anche una riduzione significativa del lavoro interrotto per i team di ingegneria dei dati.
Bozze di revisione del codice. Non un sostituto per la revisione, ma catturare le cose ovvie — join non indicizzati, controlli null mancanti, incompatibilità di tipo — prima che un umano le esamini, risparmia tempo complessivamente.
Questi sono reali e contano. Non voglio sminuirli.
Cosa l'IA non può gestire in modo affidabile
Ecco dove si apre il divario tra le affermazioni dei fornitori e la realtà della produzione.
Evoluzione dello schema su larga scala
La parte più difficile del mantenimento delle pipeline di produzione non è scrivere il codice — è sapere cosa fare quando un sistema a monte cambia un tipo di campo, depreca una colonna o inizia a inviare dati in un formato diverso. Questo richiede di comprendere la logica aziendale dietro i dati, i consumatori a valle, il contesto storico del perché il campo esiste. Un LLM che non era presente quando quelle decisioni sono state prese non può ragionare in modo affidabile sulla risposta giusta. Ti darà qualcosa che sembra giusto. Spesso non lo è.
Elaborazione di flussi con stato
Un team può passare tre mesi cercando di far implementare correttamente a un LLM un'aggregazione finestrata con gestione degli arrivi tardivi per la loro pipeline di rilevamento delle frodi in tempo reale. L'LLM potrebbe scrivere il codice. Il codice funziona anche. Produce risposte sbagliate in casi limite che si manifestano solo in produzione, in condizioni di ordinamento specifiche, in giorni con volumi di eventi insoliti. Quei bug sono del tipo difficile — non lanciano errori, corrompono silenziosamente le tue metriche. Il modello non ha modo di testare il proprio output contro i casi limite effettivi che affronterà.
Recupero da guasti in produzione
Quando un consumatore Kafka è in ritardo di 48 ore e devi decidere se riprodurre, scartare o deduplicare — non è un problema di generazione del codice. È una decisione che richiede di conoscere la tua attività, i tuoi SLA e il costo di ciascuna opzione. Non ho ancora visto un LLM prendere quella decisione correttamente senza un significativo supporto umano.
Un ingegnere capo di una società di sicurezza informatica mi ha detto: "Abbiamo raggiunto circa il 70% di automazione sui nostri schemi ETL standard. L'ultimo 30% è la parte che effettivamente si rompe in produzione." Non si stava lamentando. Capiva perché. Ma il 30% è ciò che mantiene occupati gli ingegneri dei dati.
Il problema dell'"80% di automazione"
Gartner ha pubblicato una previsione l'anno scorso secondo cui l'80% del lavoro di ingegneria dei dati sarebbe stato influenzato entro il 2027. Capisco perché l'hanno scritto.
Ecco la questione dell'80%: l'80% di cui parlano è impalcatura. Boilerplate. Prime bozze. La parte che è realmente automatizzabile all'80% per esempio è la parte che era già relativamente veloce.
Ciò che rimane è il 20% che richiede l'80% del tempo — il debug del perché i dati sembrano sbagliati, la negoziazione delle modifiche dello schema con i team a monte, il ragionamento sulla affidabilità delle pipeline in condizioni che nessuno aveva previsto. Quel 20% è anche il 20% in cui una risposta sbagliata è costosa.
Non lo dico per essere pessimista. L'80% conta. Liberare i team di ingegneria dall'impalcatura è davvero prezioso. Ma i team che pianificano un mondo in cui questa automazione significa meno ingegneri stanno facendo una scommessa specifica che anche i problemi costosi diventeranno più facili. Potrebbero. Non vedo ancora prove di ciò.
Cosa dico ai team che considerano riduzioni di personale
Non farlo ancora. Non perché la tecnologia non sia reale, ma perché stai scommettendo sulla variabile sbagliata.
I team che ottengono il massimo dagli strumenti di IA non sono quelli che riducono il personale — sono quelli che mantengono lo stesso personale e lo indirizzano verso problemi più difficili. Gli ingegneri che passavano le loro giornate su lavori ETL di routine ora lavorano su framework di qualità dei dati, governance dello schema, affidabilità delle pipeline in tempo reale. La produttività per ingegnere è più alta. La qualità del risultato è più alta. Il team è più difficile da sostituire, non più facile.
Questa è la storia. L'IA è un moltiplicatore di produttività per gli ingegneri dei dati. Non è L'INGEGNERE dei dati.
Una semplice panoramica
So che ho detto che avrei evitato il formato della tabella di confronto. Ma questo è davvero il modo più chiaro per mostrarlo:
| Compito | L'IA aiuta | L'IA fatica |
|---|---|---|
| Generazione SQL | Prime bozze, 50-70% più veloce | Logica complessa con regole aziendali sottili |
| Documentazione schema | Primo passaggio, settimane non mesi | Semantica accurata senza contesto aziendale |
| Analisi ad hoc | Domande semplici per non-ingegneri | Domande che richiedono contesto tra sistemi |
| Codice pipeline | Boilerplate, schemi standard | Logica con stato, gestione dei casi limite |
| Evoluzione schema | — | Quasi interamente giudizio umano |
| Recupero da guasti | — | Richiede conoscenza aziendale + operativa |
| Debugging in produzione | — | Gli LLM non conoscono la tua storia specifica |
La colonna di sinistra è reale. La colonna di destra è il motivo per cui i team di ingegneria dei dati esistono ancora.
Dove si inserisce layline.io
Sarò diretto: i guadagni di produttività dell'IA che ho descritto sopra sono più facili da catturare quando le tue pipeline hanno una struttura esplicita che gli LLM possono comprendere ed estendere.
Su layline.io, costruiamo pipeline con configurazione dichiarativa — la logica è in operatori strutturati, non incorporata in codice personalizzato (tranne per il casuale Javascript o Python qua e là e solo dove veramente necessario). Si scopre che questo si abbina bene con lo sviluppo assistito dall'IA. Quando un ingegnere chiede a un LLM di aggiungere un passaggio di elaborazione, l'LLM può ragionarci chiaramente. Quando qualcosa si rompe, il guasto è in un luogo noto piuttosto che sepolto in codice personalizzato.
Non è per questo che l'abbiamo costruito in questo modo. L'abbiamo costruito in questo modo perché le pipeline dichiarative sono più facili da debug e mantenere per gli esseri umani. L'affinità con l'IA si è rivelata un effetto collaterale.
Ma significa che i team che costruiscono su una base strutturata ottengono di più dagli strumenti di IA rispetto ai team che lavorano in codice personalizzato. Qualcosa da considerare quando si fanno scelte architettoniche che avranno importanza tra due anni.
La domanda che vale la pena porre al tuo team
Prova questo: scegli i tuoi ultimi cinque incidenti sui dati. Per ciascuno, chiediti se un'IA avrebbe potuto prevenirlo o diagnosticarlo più velocemente.
Per la maggior parte dei team la risposta è "forse 1 su 5." Gli altri quattro sono problemi su cui un LLM non può ragionare in modo affidabile — logica aziendale sbagliata che è codice tecnicamente corretto, un cambiamento di schema da un team a monte che nessuno ha annunciato, un caso limite nell'elaborazione dei flussi che si manifesta solo a volumi di eventi specifici.
Se stai valutando strumenti di IA, quello è il tuo punto di riferimento. Non "l'IA cambierà l'ingegneria dei dati" — ovviamente lo farà. Ma "l'IA eliminerà i problemi che ci danneggiano effettivamente?" La risposta è no, non ancora, e probabilmente non senza qualcosa che cambi che non è ancora cambiato.
Andrew Tan è un imprenditore seriale e fondatore di layline.io, costruendo infrastrutture di elaborazione dati aziendali che gestiscono carichi di lavoro sia batch che in tempo reale su larga scala.
