Tra AI agentiche, Claude Code e similari inizio a pensare che sia più sensato imparare “design del software” e come riconoscere del codice ben strutturato più che saper manualmente scriverne ex novo. Cosa ne pensate? Nel tempo libero sto studiando PowerShell e ho ripreso in mano Python (a scopi di automazione di task), ma a lavoro, e non, mi sento dire che ormai non serva a nulla.
Si, ma non nel senso di conoscere la “grammatica” quanto i design pattern, principles, etc.
Nel mio lavoro devo avere a che fare con un range molto vario di linguaggi. La cosa che mi rallentava un sacco era la grammatica dei linguaggi. Via AI assist (che e’ tipo l’opposto del vibe coding) quel problema non esiste piu’.
Impara BENE un linguaggio di programmazione, sarebbe meglio qualcosa tipo C++ per capire le basi della memoria ma la learning curve é molto più ripida, python é un buon compromesso.
Una volta che sai usare bene un linguaggio, grazie all’AI te ne fotti relativamente di imparare gli altri, perché bene o male capisci quello che fanno anche se non conosci la sintassi, quel che non capisci te lo fai spiegare dall’AI stessa.
Una volta che sai usare decentemente un linguaggio e risolvere qualche esercizio medio su leetcode, concentrati invece su design del software, architettura, tools, sistemi distribuiti, sicurezza. É quello che fa la differenza tra usare l’AI per tirare fuori mondezza che gira a malapena in localhost e invece usarla come aiuto per mettere insieme i mattoncini per qualcosa di decente. Senza le basi non capisci quali mattoncini sono stati tirati su automaticamente dall’AI, come indirizzarla a usare quelli giusti per i tuoi obiettivi, come riconoscere se sta facendo cagate astronomiche e quali pezzi mancano nel tuo stack.
La conoscenza del linguaggio ti tornerà comunque utile, perché anche se non scriverai una sola riga, ti servirà più volte capire quel pezzo di codice se sta effettivamente facendo questo o quello.
Inoltre a causa dei guardarail di sicurezza sempre più frequenti che inseriscono nei modelli di frontiera, ti potrá capitare che l’hai ti dica “ciuccia” e si rifiuti di implementare una feature. A quel punto la soluzione più semplice é fargli scrivere il codice fino ad un certo punto e scrivere te la restante parte incrimainata, che spesso sono poche righe
“Saper programmare“, dal post-crash del 2008 fino a poco tempo fa era una cosa che praticamente garantiva un lavoro a condizioni decenti (e svariate volte anche ottime) nella maggioranza delle aree del mondo. Questa era una situazione atipica, secondo me, ed era uno dei motivi per cui la Zuboff in The Age of Surveillance Capitalism paragonava la “classe“ dei “programmatori“ al clero dei secoli passati: al servizio della tecnologia principale che fornisce risposte (una volta erano i testi sacri) e, tra altre cose, come loro, dopo un periodo limitato di formazione potevano lavorare quasi ovunque e ben trattati Questa cosa è finita, secondo me, come è finita per altre professioni nella storia (inclusi anche molti cleri religiosi, direi). Cioè, una formazione anche inferiore a quella di un “bootcamp“ non ti da più così tanti “vantaggi“ sul mercato del lavoro come ti dava 5-7 anni fa. Se quindi vuoi farlo per quello, può avere poco senso, ma è una previsione personale.
Se vuoi farlo perchè vuoi partecipare, in un modo nell’altro, allo sviluppo di certe tecnologie o dell’informatica, invece non puoi non farlo. Anche fisici o matematici hanno calcolatrici scientifiche da decenni, ma inventare una nuova tecnica per stimare certi integrali - o anche capire quelle più avanzate esistenti - non ti è possibile se prima non hai risolto integrali più semplici, e quindi imparato la base dell’analisi ecc. E impararlo guardando Claude o altri LLM che lo fanno per te non è possibile, così non si impara, come non si impara guardando Claude come implementare un algoritmo complesso o organizzare un SW complesso. Quindi per quello non c’è scappatoia.
Questione “architettura“/design patterns ecc: io alla fine ho scritto molto SW e in tanti ambiti diversi nella vita. Sapere i design pattern dei libri (gang of four or altro) alla fine aiuta veramente il giusto. Essere bravi in SW architecture mi sembra, ora, la competenza osannata come antitodo al lavoro LLM-driven per un motivo molto semplice: è la parte più soggettiva del tutto. Quindi, quello che Claude fa, molto spesso a te, o al tuo team, non andrà bene perchè a voi “piace diverso”, che tra l’altro a volte può anche voler dire “peggio di quello che ti da LLM“ senza nemmeno saperlo. Ma anche se fosse così, non ci sarebbe niente di male: il lavoro comunque è fatto da “umani“, che hanno gusti, manie, paranoie ecc. Quindi, sì, potrebbe essere un altro elemento distintivo rispetto a “machines of engineered bias“.
My 2c… sicuramente si, imparare a programmare serve, ma il lavoro in futuro non sarà come è stato finora, è inutile girarci intorno.
Il “coding” come skill è secondario, quello che serve è capire le architetture i pattern, sapere cosa succede, sapere come dirigerlo e manovrarlo e correggerlo quando serve, e dedicare (questa è la novità) una buona percentuale delle proprie competenze allo studio del coordinamento delle risorse AI.
Io non credo alle cassandre che dicono che il swe (software engineering) sparirà, si trasformerà e per certi versi si espanderà, si avrà sicuramente la possibilità di costruire cose che prima non era possibile per limiti di risorse e di tempo.
Una grossa fetta del software engineering finora era fare da gateway fra chi voleva un software e le capacità per costruirlo (tempo, skill, risorse); la seconda parte è diventata più facile quindi la “superficie” si allarga.
C’è da dire che io non dovrò mai svolgere un vero e proprio compito di SWE, il mio campo richiede altro; il coding (nel mio caso più scripting) è un plus molto apprezzato e basta.
piu’ che sapere programmare ora come ora direi che il software architet e’ molto piu’ importante. il che che comporta sapere di concerti di rete/containerizzazione/orchestrazione container (k8s/swarm)/cicd/messages dispatching (amqp/kafka)/sql ecc.
tutte queste cose devi sapere come implementarle. ovviamente se sai programmare ti e’ tutto molto piu’ chiaro e ti renderai conto che non e’ complicatissimo ma e’ facile farlo male
Assolutamente sì, anche ai tempi dell’AI, non saper leggere e capire il codice può essere molto pericoloso. Al momento anche i modelli di frontiera producono codice funzionante che è diverso da codice corretto e pulito.
Gli LLM sono anche non deterministici, altro fattore da tenere in considerazione.
Io non penso che il software engineering e la programmazione siano morti, anzi, penso non siano mai stati così bene.
Lo so che gli LLM sono fallaci per definizione, però ormai tra guardrails, RAG etc penso sia sempre più “facile” avere degli output decenti di partenza.
Io non sono un programmatore anche se lo so fare abbastanza bene (mi considero l’equivalente di uno che ha fatto il conservatorio e sa suonare il piano se confrontato con un pianista professionista).
E la ma impressione é che anche per quelli come noi, forse anche di più, rimanga importantissimo saper programmare, ma non nel senso che sai che ci vuole la parentesi o il ; ad un certo punto, ma hai l’abitudine di pensare al flusso dei dati, alle strutture del software che vuoi scrivere, alle relazioni tra le sue varie componenti, a come pianificare per futuri upgrade etc.