LLMs stanno erodendo la mia carriera di ingegnere software e non so cosa fare

LLMs stanno erodendo la mia carriera di ingegnere software e non so cosa fare

Sono un ingegnere software, completando 10 anni di esperienza professionale quest'anno. Ho iniziato la mia carriera come ingegnere frontend web (era più facile per me debuggare il codice frontend allora, quindi ho scelto quella strada), ma presto sono passato a (web) backend e non ho mai guardato indietro.

Attraverso una serie di coincidenze, una volta che sono entrato nel mondo del backend, sono finito a lavorare in ruoli di sviluppo software nei domini della finanza, del libro contabile e del trattamento dei pagamenti, dove avevo grande autonomia e una relazione candida e sincera con i Manager dei prodotti e gli stakeholder.

Ho imparato molto sulla domanda e su come scrivere programmi efficaci per essa: PCI compliance, registri di contabilità a doppio ingresso, escrow, riconciliazione, cicli di pagamento, idempotenza dei trasferimenti bancari, ecc.

Era ovvio che dovessi concentrare la mia carriera su diventare un esperto di quella domanda per distinguermi come professionista e differenziarmi in un campo che mostrava segni di un crescente bisogno di specialisti di domanda.

Il primo pilastro a erodersi: la conoscenza domain-specific

L'anno scorso, sono stato assunto da una società nel campo della finanza. Fino ad allora, avevo lavorato su società che avevano un forte componente di pagamento e di finanza nella loro operazione/offerta, ma che non erano società focalizzate esclusivamente sulla finanza.

Quella società ha accolto con entusiasmo l'AI, quindi ho avuto accesso a ChatGPT e a Claude Enterprise fin dal primo giorno e sono stato incoraggiato a usarli per la mia ricerca, l'esplorazione e anche il codice, anche se con un avvertimento che avrei dovuto ancora esaminare e possedere ogni singola riga che era entrata in produzione.

Uno dei miei primi progetti ha coinvolto la ristrutturazione del sistema di pagamento online di vecchia data, che era un disastro. Mi hanno assunto (tra le altre cose) per la mia precedente esperienza nel costruirlo e mi hanno affidato il compito.

Diversamente dalle altre società che avevo lavorato fino ad allora, volevano che i "Design Docs" che scrivo prima di codificare fossero leggibili sia dagli ingegneri che dai manager dei prodotti - quindi non dovrebbero essere un'analisi tecnica approfondita e dovrebbero essere più di una visione architettonica. Ho scritto il mio primo con un aiuto minimale dell'AI - ho persino chiamato i LLM "parrocchetti stocastici" all'epoca, una visione che non tengo più - e l'ho consegnato.

Ho valutato la mia conoscenza e pensavo che nessun LLM potesse sostituirla.

Poi il mio manager mi ha contattato: anche se stai consegnando il codice a un buon ritmo, stai prendendo troppo tempo a consegnare quei Design Docs. Stai usando l'AI? Dovresti usarne di più.

"Non funzionerà mai", ho pensato dentro di me, ma ho accettato. I modelli all'epoca non erano così buoni come quelli che abbiamo ora, ma fornivano un buon acceleratore per la mia scrittura e anche la decisione.

E poi ho iniziato a realizzare: tutta la conoscenza che ho accumulato negli anni: i trade-off tra le implementazioni, come funziona l'acquisto, come strutturare l'idempotenza per prevenire le doppie cariche, tutto, era diventato inutile. Anche se i modelli avevano ancora bisogno di un po' di guida, potevano collegare i punti tra loro su come strutturare tali sistemi, che era la parte più difficile che solo sviluppa nella tua mente dopo anni di esperienza pratica.

Quello fu il mio primo shock

.

Ma certo, ho pensato, possono farlo perché ci sono molti articoli sul web su come funziona tutto ciò insieme con tutta la documentazione tecnica, e abbiamo post sui blog che spiegano come applicare gli strumenti tecnici alla domanda. Per gli esseri umani, può richiedere molto tempo per imparare tutto ciò, ma è dati di addestramento per i modelli che possono imparare.

Cosa i modelli non saranno mai in grado di fare bene, e dove gli esseri umani brilleranno, è il debugging! Ho accumulato una buona esperienza nel debuggare le condizioni di corsa e i sistemi distribuiti in produzione. Quello era il mio biglietto per l'occupazione a lungo termine.

Il secondo pilastro a erodersi: il debugging e i sistemi distribuiti

Quindi, dopo i LLM sono iniziati a diventare buoni nel scrivere documenti e nell'aiutare a pianificare le implementazioni reali, sono diventati buoni nel codice. È iniziato nella seconda metà del 2025 con l'ipotesi Claude Code, poi Codex è arrivato