Il punto di partenza
L'ingegneria del software moderna è una disciplina di cui diventa più difficile parlare ogni anno. Il vocabolario si è gonfiato più in fretta di quanto il mestiere sottostante sia cambiato: ogni framework si dice un paradigma, ogni cloud si dice una piattaforma, ogni assistente si dice un agente.
Dietro il rumore, il lavoro è rimasto riconoscibile. Un team prende un bisogno di business, sceglie un'architettura con cui può convivere, consegna una prima versione che sopravvive al contatto con gli utenti, poi la mantiene attraverso tre anni di cambiamento senza riscriverla. I team che fanno questo in modo costante nel 2026 condividono un piccolo numero di abitudini, e quasi nessuna riguarda la scelta del framework.
Questo testo riguarda ciò che l'ingegneria del software moderna consegna davvero, e dove l'IA ha cambiato, e non ha cambiato, l'ingegneria stessa.
Il costo di una cattiva architettura non è sceso
I framework sono evoluti. Il costo di una cattiva scelta di fondo, invece, non è sceso.
Un'affermazione frequente nel 2026 è che lo sviluppo assistito dall'IA ha reso il software a buon mercato. Ha reso un certo software più rapido. Più rapido non è la stessa cosa di meno costoso, perché il lavoro che l'assistenza dell'IA comprime (la digitazione) era raramente la parte costosa. Le parti costose sono sempre le stesse: scegliere la giusta architettura, modellare correttamente il dominio, decidere cosa consegnare e cosa rifiutare, e mantenere il risultato per anni.
Un modello di dati mal giudicato resta un problema esteso su più trimestri. Un confine di autenticazione mal giudicato fa ancora trapelare i dati dei clienti. Una storia di deploy mal giudicata sveglia ancora l'ingegnere di reperibilità alle 3:14. Nessuna di queste classi di errore è risolta da una digitazione più rapida. Sono risolte dal giudizio senior in fase di design, la parte del lavoro che l'IA assiste, ma non sostituisce.
I team che consegnano software nel 2026 passano più tempo sulle decisioni architetturali precoci di cinque anni fa, perché il costo di sbagliare si compone più in fretta attraverso un codice aumentato dall'IA.
Default noiosi, assunti dove conta
Lo stack di default di SDEN per il web e il mobile è deliberatamente conservativo: Next.js con TypeScript al frontend, PostgreSQL con Prisma o Drizzle sul livello dati, Node.js o un framework come NestJS sulla superficie di API. Il mobile passa di default a Flutter o React Native a meno che il prodotto non abbia bisogno di un'integrazione profonda alla piattaforma. L'obiettivo non è che siano le scelte più di moda. È che siano le scelte che un piccolo team senior può ancora mantenere tra tre anni.
Dove siamo assunti è sui confini: API tipizzate end-to-end, rendering lato server di default, nessun dato non tipizzato che attraversa tra server e client, una pipeline di CI che compila e fa deploy a ogni commit sul branch principale, e un processo di pubblicazione abbastanza automatizzato perché l'ingegnere che ha consegnato la modifica non sia l'ingegnere che sorveglia il deploy.
Non sono scelte eccitanti. Sono le scelte che rendono possibile il lavoro eccitante più tardi, perché il team non spende la sua energia sui fondamentali.
I pattern che sopravvivono al secondo anno
La maggior parte dei progetti software sembra andar bene nei primi sei mesi. I test interessanti vengono al secondo anno, quando gli ingegneri originali hanno cambiato posizione, il prodotto ha accumulato casi marginali, e la clientela si è estesa oltre le ipotesi di design. I pattern che sopravvivono a questo test sono quelli noiosi: confini di modulo espliciti, un modello di dominio documentato nel codice anziché in un wiki, un registro di decisioni architetturali per ogni scelta non evidente, e una suite di test che qualcuno può ancora eseguire.
I pattern che non sopravvivono sono quelli che dipendevano dalla memoria di un solo ingegnere, dal fatto che i default di un framework restino costanti, o dall'ipotesi che nessuno vorrebbe mai rivedere quel codice. Lo si vuole sempre.
Il partito preso di SDEN su ogni progetto va verso il pattern noioso, accettato esplicitamente e documentato. Scambieremo l'astuzia con la leggibilità sul secondo anno di ogni progetto.
Tre abitudini dietro ogni codice che consegniamo
Non sono aspirazioni. Sono i default operativi su ogni progetto, scritti nel contratto di progetto.
Tipizzato end-to-end
TypeScript su tutto lo stack, senza confine non tipizzato tra server e client. Se un campo cambia nel database, il frontend rifiuta di compilare finché il cambiamento non è riconosciuto. È la rete di sicurezza meno costosa per un grande team che conosciamo.
Registri di decisioni architetturali
Ogni scelta non evidente ottiene un ADR di una pagina nel repository: ciò che abbiamo deciso, ciò che abbiamo considerato, perché ne abbiamo scelto uno anziché l'altro. I futuri ingegneri (compresi i nostri) li leggono dal primo giorno.
Deploy noioso
Il deploy è automatizzato, osservabile e reversibile. Qualsiasi ingegnere del team può consegnare in produzione; qualsiasi ingegnere del team può tornare indietro. Il processo di pubblicazione non è un rituale.
Il codice che puoi ancora leggere tra tre anni
La misura onesta di un progetto è cosa pensa del codice il prossimo team.
Un codice che invecchia bene non ha un'unica astuzia. Ha un centinaio di piccole gentilezze: nomi significativi, moduli dimensionati perché una persona li tenga in testa, test che spiegano l'intenzione dietro il codice, niente codice morto che resta lì a confondere il prossimo lettore, e un registro di decisioni architetturali a ogni snodo in cui un futuro ingegnere dovrebbe altrimenti indovinare.
Quando SDEN consegna un codice, il test è concreto: un ingegnere senior che si unisce al progetto dovrebbe essere produttivo in meno di una settimana, senza visita guidata. Se non può, non abbiamo finito.
È la metà noiosa del lavoro. È anche la metà che determina se il prodotto sopravvive al prossimo cambiamento nel team.
Software e mobile
le domande che ci fanno più spesso.
Risposte dirette alle domande che ci vengono poste più spesso. Se la tua non c'è, scrivi al team.