Donn Felker, AI platform lead presso Polygon, in precedenza in Tinder e specialista Android da dieci anni, pubblica il 14 settembre 2026 un saggio sulla scomparsa dell'ingegneria del software come l'ha praticata lui. Data la propria presa di coscienza al luglio 2025, sulla base di tre fatti. Ha costruito una SaaS completa senza scrivere una riga di codice. In Tinder, un prompt di duemila parole ha eseguito in dieci minuti, senza errori, una migrazione di una libreria di threading che prima richiedeva da sei a otto ore per istanza. Infine, ha visto persone non tecniche spedire prodotti reali: una CFO ha costruito il suo strumento di operazioni finanziarie con l'app Claude, un gestore di palestra la sua piattaforma di coaching. La sua conclusione: non si è mai trattato di scrivere codice ma di eseguire — il codice era solo un pedaggio.
Il saggio spiega poi l'ansia degli ingegneri attraverso due concetti di psicologia sociale. L'occupational categorization riduce una persona al proprio lavoro; la professional identity centrality fa di quel lavoro il fondamento del proprio valore. Quando il lavoro quotidiano passa a un agente, l'identità vacilla: restare indietro oppure addestrare il proprio sostituto.
Felker propone l'immagine di un pendolo della leva tra prodotto e ingegneria. L'agente sposta la leva iniziale verso il prodotto, che ottiene un prototipo in un pomeriggio. Ma la complessità e la scala riportano la leva verso l'ingegneria: una CFO bloccata dopo due mesi nella stessa sessione di Claude Cowork senza sapere dove si trova il suo codice, un fotografo la cui app Base44 memorizzava i suoi contenuti multimediali su Google Drive a un costo di trasferimento insostenibile. L'ingegnere corregge, mette in atto architettura e guardrail, poi restituisce il controllo. Ogni oscillazione si attenua, fino alla versione successiva del modello.
Il ruolo che emerge nel punto di equilibrio è l'agentic builder, un ibrido tra ingegnere e product lead. I puri specialisti dei due estremi sono presentati come minacciati. Il percorso proposto ha due fasi: codificare le proprie conoscenze in skill e procedure eseguibili dagli agenti, il che rende l'individuo scalabile e lo fa passare da operatore a orchestratore; poi adottare il pensiero sistemico — business per l'ingegnere, ingegneria per la persona non tecnica — con un elenco di sei requisiti da richiedere all'agente: architettura, guardrail, backup, versioning, governance, osservabilità.
L'autore fissa un orizzonte di sei mesi per compiere la transizione e conclude con la figura del builder capace di leggere un bilancio e una traccia di esecuzione.
Punti chiave
Tre fattori scatenanti datati luglio 2025. una SaaS completa costruita senza scrivere codice; un prompt di 2.000 parole — "which we'd now call a Skill" — che esegue in 10 minuti una migrazione di una libreria di threading che costava a un ingegnere 6-8 ore per istanza, ripetuta centinaia di volte nel codebase di Tinder; persone non tecniche che spediscono prodotti. La narrazione di questa svolta fa eco a quella di [[cherny-sequoia-coding-is-solved-loops-printing-press-2026-05]].
Formula centrale."Coding was just a gatekeeper." Ciò che separa chi sogna da chi realizza è la capacità di eseguire; il codice è sempre stato solo il pedaggio per questo.
Il quadro identitario. l'occupational categorization comprime una persona in un ruolo ("Android Developer"); la professional identity centrality fa di quel ruolo il fondamento del valore percepito. Da qui il doppio vincolo formulato dal saggio: non usare l'IA significa restare indietro; usarla significa addestrare il proprio sostituto.
Il pendolo della leva. prima dell'IA, l'ingegneria dettava il ritmo e deteneva la leva; l'agente sposta la leva iniziale verso il prodotto (un MVP in un pomeriggio). Complessità, scala ed economia dei sistemi la riportano verso l'ingegneria, che corregge, mette in atto architettura e guardrail, poi la restituisce al prodotto. Ogni ritorno è più breve — damped oscillation — ma una nuova versione del modello rimette in moto il movimento.
Due casi in cui il pendolo torna indietro. una CFO che ha costruito il proprio strumento finanziario in un'unica sessione di Claude Cowork durata due mesi, finché l'ambiente ha raggiunto la saturazione, senza sapere dove si trova il suo codice (trovato in un repository GitHub privato); un fotografo che ha collegato Google Drive come storage multimediale in un'app Base44, una scelta che l'agente ha seguito senza obiezioni e che ha reso insostenibili i costi di trasferimento. L'agente "will follow your lead".
L'analogia del coach. all'inizio basta muoversi, poi si raggiunge un plateau o ci si infortuna; l'ingegnere corregge la forma e fissa il programma, poi si fa da parte; le visite successive sono più brevi.
Il ruolo che emerge. né ingegnere né prodotto, ma entrambi — "the engineer who thinks like a product person and the product person who thinks like an engineer". Sul lato ingegneristico, il titolo proposto è Agentic Product Engineer. I puri specialisti dei due estremi sono presentati come esposti; gli specialisti profondi persistono ma con competenze fuori dal proprio dominio. Questa mappatura dei ruoli può essere letta insieme a [[ng-ai-engineering-skills-map-2026-08-14]].
Percorso in due fasi, comune a entrambi i profili. (1) codificare le proprie conoscenze in skill, template e procedure eseguibili da persone o agenti — "you're making yourself scalable", un passaggio da operatore a orchestratore; (2) passare dal pensiero da specialista al pensiero sistemico, che l'autore chiama complessità cognitiva.
Per l'ingegnere. lasciare andare un'identità legata a un linguaggio o a una piattaforma (l'autore non tocca Android o Kotlin da sei mesi), trattare ogni skill come un mattoncino Lego, valutare build vs buy tenendo conto della manutenzione, pensare in termini di ROI, acquisizione, retention. Una posizione vicina a quella di [[osmani-google-new-sdlc-vibe-coding-agentic-engineering-2026-05]] sulla svolta verso l'agentic engineering.
Per la persona non tecnica. interrogare l'agente a ogni blocco e richiedere sei cose che non saprebbe chiedere da sola — architettura mantenibile, guardrail, backup, controllo di versione, governance, osservabilità. Consiglia di installare un Destructive Command Guard.
⚠️ L'orizzonte di sei mesi è ripetuto tre volte senza giustificazione; funziona come artificio retorico, non come previsione fondata.
Primo passo consigliato. elencare ciò che si fa manualmente e si detesta fare, scegliere una cosa, chiedere a Claude o ChatGPT "help me turn this into a skill" e lasciarsi intervistare. Cinque minuti.
Dati chiave
migrazione della libreria di threading presso Tinder ridotta da 6-8 ore a 10 minuti con un prompt di 2 000 parole, luglio 2025
"It was never about coding, it's about the ability to execute"
— Donn Felker
"Coding was just a gatekeeper"
— Donn Felker
"The ability to stand where the pendulum stops"
— Donn Felker
l'IA déplace le levier initial de l'ingénierie vers le produit, la complexité et l'échelle le ramènent vers l'ingénierie
— pendule de levier
lo sviluppo di un prodotto software ha sempre rappresentato il 30 % del problema, con il restante 70 % costituito da posizionamento, marketing e vendita
— Donn Felker
Il grafo di conoscenza estratto da questa fiche — 12 entità, 25 relazioni.
In questo grafo :Donn Felker · Polygon · Tinder · agentic builder · pendule de levier · identité professionnelle · vibe coding · Claude Cowork · Base44 · codification du savoir en skills · Destructive Command Guard · agents IA