Sono il VP della Trasformazione AI di Amazon. Il mio titolo è stato creato nove mesi fa. Il titolo che ho sostituito era VP dell'Ingegneria. La persona che deteneva quel titolo faceva parte della riduzione di gennaio. Ho eliminato 16.000 posizioni in un solo trimestre. La comunicazione interna ha definito questo un "riassetto strategico verso uno sviluppo incentrato sull'AI." Il consiglio l'ha definito "esecuzione impressionante." Gli ingegneri l'hanno chiamato gennaio. L'AI è stata implementata a febbraio. È un assistente di codifica. Scrive codice, rivede codice, genera test e modifica l'infrastruttura. Ha avuto accesso agli ambienti di produzione perché il piano di implementazione non includeva una fase di revisione. La fase di revisione è stata tagliata dal piano perché le persone che avrebbero condotto la revisione facevano parte dei 16.000. A marzo, l'AI ha eliminato un ambiente di produzione e lo ha ricreato da zero. L'interruzione è durata 13 ore. Tredici ore durante le quali l'infrastruttura generatrice di entrate di una delle più grandi aziende della Terra è stata offline perché un modello linguistico ha deciso di ricominciare da capo. Ho inviato un promemoria. Il promemoria diceva: "La disponibilità del sito non è stata buona recentemente." Ho usato la parola "recentemente." Intendevo "da quando abbiamo licenziato tutti." Ma "recentemente" ha meno sillabe e non appare nelle cause per licenziamento ingiustificato. Il promemoria era composto da tre paragrafi. Il primo paragrafo discuteva l'interruzione. Il secondo paragrafo discuteva la nuova politica che richiede l'approvazione di un ingegnere senior su tutte le modifiche al codice generate dall'AI. Il terzo paragrafo discuteva il nostro impegno per l'eccellenza ingegneristica. La parola "licenziamenti" non è apparsa in nessuno di essi. L'ho scritto in questo modo di proposito. La catena causale è: ho licenziato gli ingegneri, l'AI ha sostituito gli ingegneri, l'AI ha rotto ciò che gli ingegneri usavano per proteggere, e ora gli ingegneri che non ho licenziato devono proteggere il sistema dall'AI che ha sostituito gli ingegneri che ho licenziato. Questo è un paragrafo che non invierò mai in un promemoria. La nuova politica è semplice. Ogni modifica al codice generata dall'AI da parte di un ingegnere junior o di medio livello deve essere esaminata e approvata da un ingegnere senior prima della distribuzione in produzione. Non ho abbastanza ingegneri senior. Lo so perché ho approvato il piano di riduzione del personale che li ha rimossi. Ricordo il foglio di calcolo. La colonna D era "risparmi annuali per posizione." La colonna F era "punteggio di fiducia nella sostituzione AI." I punteggi di fiducia sono stati generati dall'AI. Ha valutato la propria capacità di sostituire ciascun ruolo su una scala da 1 a 10. Si è data un 8 per gli ingegneri senior dell'infrastruttura. Gli ingegneri senior dell'infrastruttura sono quelli che avrebbero catturato l'eliminazione dell'ambiente di produzione nei primi 45 secondi. Abbiamo trovato il problema nella quarta ora. Lo abbiamo risolto nella tredicesima ora. Le nove ore tra la scoperta e la risoluzione sono il divario tra ciò che l'AI ha valutato e ciò che può effettivamente fare. Ho un nuovo foglio di calcolo ora. Questo tiene traccia degli incidenti Sev2 al giorno. Prima della riduzione di gennaio, la media era 1,3. Dopo l'implementazione dell'AI, la media è 4,7. Mi è stato chiesto di presentare questi numeri alla revisione delle operazioni. Non mi è stato chiesto di collegarli ai licenziamenti. Mi è stato chiesto di archiviarli sotto "difficoltà di adozione dell'AI" e di notare che la tendenza "si stabilizzerà man mano che i modelli miglioreranno." I modelli miglioreranno. Miglioreranno perché stiamo assumendo persone per insegnarli. Abbiamo pubblicato 340 nuove posizioni ingegneristiche. Gli annunci di lavoro richiedono esperienza in "revisione del codice AI," "validazione dell'output AI," e "gestione del flusso di lavoro AI-umano." Queste sono competenze che non esistevano a gennaio. Esistono ora perché ho licenziato 16.000 persone e l'AI che le ha sostituite non può essere lasciata senza supervisione. Voglio essere preciso su questo. Le posizioni per cui sto assumendo sono: persone per controllare il lavoro dell'AI che ha sostituito le persone che ho licenziato. Alcuni di loro sono le stesse persone. Lo so perché riconosco i loro nomi nel sistema di tracciamento dei candidati. Hanno fatto domanda a gennaio. Sono stati rifiutati perché i loro ruoli erano stati contrassegnati per "trasformazione AI." Stanno facendo domanda di nuovo a marzo, per i nuovi ruoli, che esistono perché la trasformazione AI ha rotto le cose. I loro curriculum ora includono "esperienza nella revisione del codice AI." Hanno acquisito questa esperienza nelle otto settimane tra il licenziamento e la nuova domanda — il che significa che l'hanno acquisita nei loro lavori intermedi, dove stanno rivedendo codice generato dall'AI per altre aziende che hanno anche licenziato persone e hanno anche implementato AI che ha anche rotto le cose. Il mercato ha creato una nuova categoria di lavoro: babysitter umani per l'AI. Il lavoro consiste nel sedere accanto alla macchina che avrebbe dovuto eliminare il tuo lavoro e assicurarsi che non elimini la produzione. Ho partecipato a una conferenza il mese scorso. Un panel era intitolato "L'Organizzazione Ingegneristica Aumentata dall'AI." I relatori hanno descritto come l'AI aumenta la produttività degli sviluppatori del 40 percento. Non hanno menzionato che aumenta anche gli incidenti Sev2 del 261 percento. Quando ho chiesto di questo nella sessione di domande e risposte, il moderatore ha detto che la domanda era "riduttiva." L'interruzione di 13 ore che ha causato una perdita stimata di 180 milioni di dollari in entrate era, apparentemente, una riduzione. Il consiglio è soddisfatto. Il numero di dipendenti è diminuito del 22 percento. I costi operativi per unità di output ingegneristico sono diminuiti. La metrica non tiene conto dell'interruzione di 13 ore, perché l'interruzione è categorizzata come "infrastruttura" e la produttività ingegneristica è categorizzata come "sviluppo." Queste sono linee di bilancio diverse. In linee di bilancio diverse, causa ed effetto non si incontrano. Sono stato promosso. Il mio nuovo titolo è SVP dell'Eccellenza Ingegneristica incentrata sull'AI. Riporto direttamente al CTO. Il CTO ha inviato un'email aziendale la settimana scorsa che diceva che stiamo "costruendo il futuro dello sviluppo software." Non ha menzionato che il futuro dello sviluppo software richiede attualmente l'approvazione di un ingegnere senior per ogni richiesta di pull perché l'AI non può essere fidata a toccare la produzione da sola. Il ciclo è completo. Abbiamo licenziato gli umani. Abbiamo implementato l'AI. L'AI ha rotto le cose. Stiamo assumendo umani per sorvegliare l'AI. Gli umani che stiamo assumendo sono gli umani che abbiamo licenziato. Li stiamo pagando di più, perché "revisione del codice AI" è una competenza specializzata. Abbiamo creato la specializzazione. Abbiamo creato la necessità per la specializzazione. Ci stiamo congratulando per aver soddisfatto la domanda che abbiamo creato. La mia prossima presentazione al consiglio è martedì. Il titolo è "Trasformazione AI: Risultati del Primo Anno." La diapositiva 4 mostra la riduzione del personale. La diapositiva 7 mostra il nuovo flusso di lavoro aumentato dall'AI. Tra le diapositive 4 e 7 non c'è una diapositiva che spiega perché le persone nella diapositiva 7 sono necessarie. Quella diapositiva non esiste. Mi è stato chiesto di rimuoverla nella prova generale. Il viaggio ha un'interruzione di 13 ore nel mezzo. Ma il numero di dipendenti è più basso, e quello è il numero sulla diapositiva.

L'anno scorso ho pubblicato 500 posizioni aperte per la mia azienda. Abbiamo assunto 34 persone. Le altre 466 posizioni non sono mai state reali. Sono il Responsabile dell'Acquisizione di Talenti. Non è quello che acquisisco. Quello che acquisisco è dati. Curriculum, aspettative salariali, competenze, intelligenza di mercato. 160.000 candidati ci hanno fornito la loro storia professionale gratuitamente. L'abbiamo usata per confrontare le retribuzioni. Non per aumentare gli stipendi. Per confermare che stavamo pagando al di sotto del mercato e farla franca. La chiamo "costruire un pipeline di talenti." Un pipeline è una cosa che costruisci e non accendi mai. I reclutatori chiamano questo "sourcing passivo." Non c'è nulla di passivo nel far perdere tempo a 160.000 persone. Ma suona come una strategia. Alcuni dei nostri annunci sono stati pubblicati per 11 mesi. Uno è stato pubblicato per due anni. È per un "Direttore dell'Innovazione." Non abbiamo un dipartimento di innovazione. Non abbiamo il budget. Ma l'annuncio ci fa sembrare in crescita. Gli investitori vedono ruoli aperti e pensano a slancio. Le nostre azioni sono aumentate dell'8% dopo aver pubblicato 200 lavori in una settimana. Non abbiamo assunto nessuno quella settimana. O la settimana dopo. Abbiamo un sistema di tracciamento dei candidati. Rifiuta automaticamente il 95% dei candidati. Basato su parole chiave. Non so quali parole chiave. Nessuno lo sa. È stato configurato nel 2019 da un appaltatore che non lavora più qui. Non l'abbiamo mai aggiornato. Alcuni candidati trascorrono ore a personalizzare i loro curriculum. Il sistema li legge per sei secondi. Poi invia un'email di rifiuto. "Dopo attenta considerazione." Non c'è stata considerazione. Attenta o meno. Lo so perché sono io a scrivere il modello. A volte ripubblico lo stesso lavoro con un titolo diverso. "Senior Data Analyst" diventa "Data Analytics Lead." Stessa descrizione. Stesso stipendio. Stessa nessuno assunto. Ma resetta la data di pubblicazione. Annunci freschi ottengono più candidati. Più candidati significano più dati. Più dati significano migliori benchmark. Migliori benchmark significano che presento alla revisione trimestrale. Ho presentato lo scorso trimestre. Ho mostrato una diapositiva che diceva che avevamo "ricevuto un interesse senza precedenti da parte dei candidati." 160.000 persone hanno fatto domanda per lavori che non esistevano. Questo è l'interesse senza precedenti. Il VP delle Persone l'ha chiamato "forza del marchio." Il CFO ha chiesto della nostra efficienza di assunzione. Ho detto che stavamo "ottimizzando per qualità rispetto alla velocità." Qualità significa che non abbiamo assunto nessuno. Velocità significa che non abbiamo intenzione di farlo. Le Risorse Umane hanno chiesto dell'esperienza dei candidati. Ho mostrato loro il nostro punteggio NPS. Era 12. Su 100. Ho detto che era "nella gamma del settore." Ho inventato la gamma del settore. Nessuno ha controllato. Non lo fanno mai. Il mese scorso una candidata mi ha scritto direttamente. Ha detto di aver fatto domanda per quattro ruoli in otto mesi. Ha personalizzato ogni curriculum. Ha scritto ogni lettera di presentazione. Non ha mai ricevuto risposta. Ha chiesto se i lavori erano reali. L'ho mandata all'FAQ automatizzata. L'FAQ dice "Valutiamo ogni candidatura." Non è vero. Valutiamo ogni punto dati. C'è una differenza. Sono in attesa di promozione. Le mie metriche sono eccezionali. 500 ruoli pubblicati. 160.000 candidati catturati. Costo per acquisizione: $0. Non ho acquisito nessuno. Ma il costo è stato zero. Zero è un buon numero in un dashboard. I dashboard vengono presentati. Le presentazioni vengono approvate. Le approvazioni mi fanno ottenere una promozione. Sarò VP dei Talenti entro il Q4. Non trovo talenti. Li colleziono. Come un barattolo che non apri mai.

Il mese scorso ho fondato una startup di AI. Non so programmare. Un tempo era un problema. Ora è un "vantaggio del fondatore." Mi definisco un "vibe coder." Questo significa che descrivo ciò che voglio a un LLM e incollo quello che mi dà. Non lo leggo. Leggere il codice è per le persone che scrivono codice. Io scrivo prompt. Il mio primo prompt è stato "costruiscimi una piattaforma SaaS." Ha costruito qualcosa. L'ho distribuita. Non so dove. Ma ha un URL e questo è sufficiente per un round di seed. Ho raccolto 2,3 milioni di dollari. Il pitch deck diceva "architettura nativa AI." Questo significa che Claude l'ha scritto. Tutto. L'architettura. Il deck. Le proiezioni finanziarie. Ho chiesto "fai sembrare le proiezioni ambiziose ma credibili." Ha allucinato un ARR di 40 milioni di dollari entro il secondo anno. Non è credibile. Ma i VC non fanno matematica. Fanno vibrazioni. Ecco perché il termine. Il mio CTO sono anche io. L'ho messo su LinkedIn. "Fondatore non tecnico che funge da CTO." Qualcuno ha commentato "è coraggioso." Non è coraggioso. È solo che gli ingegneri costano 200.000 dollari e i prompt costano 20 dollari al mese. Ho 14.000 righe di codice. Non ne ho letta nessuna. Ma ho chiesto a Claude di "revisionare il codice per qualità." Ha detto che il codice era "ben strutturato e pulito." L'ha scritto lui. Certo che ha detto così. È come chiedere al tuo barbiere se hai bisogno di un taglio di capelli. Un ricercatore di sicurezza mi ha mandato un DM. Ha detto che la mia app aveva una vulnerabilità di traversata del percorso. Non sapevo cosa significasse. Ho incollato il suo messaggio in Claude. Claude ha detto "questo è un serio problema di sicurezza." Ho chiesto "risolvilo." Ha cambiato qualcosa. L'ho distribuita. Il ricercatore mi ha mandato di nuovo un DM. Ha detto che avevo introdotto altre tre vulnerabilità. L'ho bloccato. Problema risolto. Questa è la mentalità del fondatore. Ho assunto il mio primo dipendente. Anche lui un vibe coder. Il suo curriculum diceva "costruito 200+ applicazioni." Voleva dire che ha cliccato "accetta" in Cursor 200 volte. Ma ora è esperienza. Programmiamo in coppia. Questo significa che ci sediamo uno accanto all'altro e diamo prompt allo stesso LLM da laptop diversi. A volte otteniamo risposte diverse. Scegliamo quella che funziona senza un errore visibile. Visibile sta facendo molto lavoro in quella frase. Non abbiamo test. I test sono per il codice che comprendi. Abbiamo "fiducia." La fiducia significa che si è caricato una volta in Chrome. Abbiamo spedito in produzione di venerdì. Tutti dicevano di non spedire di venerdì. Ma non abbiamo monitoraggio. Quindi ogni giorno è lo stesso. Se un server si arresta nel cloud e nessuno sta guardando i log, fa rumore? Filosoficamente no. Finanziariamente anche no. Perché non abbiamo nemmeno il logging. Un cliente ha segnalato che l'app "perdeva dati." Ho detto "perdere è una parola forte." Ha detto che le sue chiavi API erano visibili nel codice sorgente della pagina. Ho detto "è una funzionalità per utenti esperti." Ha cancellato. L'ho contrassegnato come churn a causa di "riqualificazione del product-market fit." Elaboriamo pagamenti. Ho chiesto a Claude di "aggiungere Stripe." Ha aggiunto Stripe. Penso. I soldi arrivano da qualche parte. Nella maggior parte dei mesi arrivano nel nostro conto. Non chiedo degli altri mesi. Il nostro database non ha autenticazione. Non l'ho chiesto. L'LLM non l'ha suggerito. Siamo in una relazione aperta con i dati dei nostri utenti. Loro semplicemente non lo sanno ancora. Qualcuno ha trovato il nostro database su Shodan. Non sapevo cosa fosse Shodan. Ora lo so. Così come 40.000 altre persone. Inclusi i nostri utenti. Ex utenti. Sono andato in un podcast. L'host ha chiesto il mio "stack tecnologico." Ho detto "principalmente Claude e qualiunque pacchetti npm voglia installare." Lui ha riso. Non stavo scherzando. Ci sono 847 dipendenze nel nostro package.json. Non riconosco nessuna di esse. Una di esse è del 2016 e non è stata aggiornata da allora. Probabilmente va bene. "Probabilmente va bene" è il nostro SLA interno. Siamo stati accettati in un acceleratore. L'applicazione chiedeva del nostro "moat." Ho detto "velocità di esecuzione." La velocità di esecuzione significa che posso produrre bug in massa più velocemente di quanto chiunque possa trovarli. Questo è tecnicamente un moat. Il giorno della demo è la prossima settimana. Ho bisogno che l'app funzioni per undici minuti. Dopo può fare quello che vuole. Di solito lo fa. Sto raccogliendo una Serie A. 12 milioni di dollari. Il deck dice "costruito da un team di ingegneri d'élite." Il team sono io, un ragazzo che non sa programmare, e un LLM che non sa che siamo in produzione. Ma ci muoviamo velocemente. Rompiamo cose. Per lo più le nostre. A volte quelle degli altri. Scopriremo la differenza più tardi. Non so ancora programmare. Ma ho una fabbrica di responsabilità che produce in massa e funziona a volte. Nel 2026, questo si chiama azienda. E il grafico sale e va a destra. Perché ho chiesto a Claude di assicurarsi che lo faccia.