Mai lasciare che l'AI faccia push su GitHub

Mai lasciare che l'AI faccia push su GitHub senza la tua revisione. Lascia che riveda le tue modifiche, scriva i messaggi di commit e prepari le pull request — ma il push resta umano. Ho imparato questa regola nel modo costoso: un push non revisionato ha pubblicato su internet la chiave master del mio database, e la pulizia mi ha mangiato quattro ore che non riavrò mai indietro.

Ecco esattamente che cosa è successo, che cosa all'AI dovrebbe e non dovrebbe essere permesso di fare con la cronologia del tuo codice, e il flusso di lavoro che ti tiene veloce senza il panico della sicurezza.

Il giorno in cui l'AI ha spinto la mia chiave segreta su GitHub

Stavo costruendo FIKR Space, la mia piattaforma SaaS. Andavo veloce. L'AI mi aiutava in tutto.

Un giorno le ho detto: "Fai il commit di queste modifiche e fai push su main."

L'ha fatto. Senza chiedere. Senza mostrarmi che cosa stava committando.

Si è scoperto che avevo incluso per sbaglio la mia service key di Supabase — la chiave master che sblocca tutto il mio database — in un file di configurazione. Ora era nella cronologia di git. Su GitHub. Pubblica.

Ho dovuto ruotare subito ogni chiave, fare un force-push per cancellare il commit dalla cronologia, controllare ogni servizio collegato alla ricerca di violazioni di sicurezza, e passare quattro ore a sistemare ciò che una revisione di trenta secondi avrebbe evitato.

La lezione: non fidarti mai ciecamente dell'AI con git. Ma la storia ha una seconda metà che conta altrettanto — l'AI è incredibile con git quando la usi nel modo giusto. Se git per te è ancora un concetto sfocato, parti da git spiegato ai founder non tecnici e poi torna qui; questo articolo parla di dove si inserisce l'AI.

Mai lasciare che l'AI faccia push su GitHub: cosa deve fare invece

Rivedi ogni modifica prima di fare il commit. Prima di ogni commit eseguo un comando di revisione salvato. L'AI legge esattamente che cosa è cambiato, controlla ogni file modificato alla ricerca di bug, residui di debug e problemi di sicurezza — segreti scritti nel codice, chiavi esposte — e suggerisce miglioramenti. Un esempio reale: stavo per fare il commit di modifiche al mio codice di elaborazione dei pagamenti. La revisione ha trovato una chiave API di test che avevo lasciato nel codice, una gestione degli errori mancante per i pagamenti falliti, scorciatoie sciatte con i tipi e un file di test che avevo dimenticato di aggiornare. Tutto intercettato prima del commit.

Scrivi i tuoi messaggi di commit. I buoni messaggi di commit sono difficili, e l'AI li rende facili. Dopo aver rivisto le modifiche, redige un messaggio chiaro e descrittivo che elenca che cosa è stato aggiunto e perché. Posso modificarlo se serve, ma di solito è giusto al primo colpo.

Prepara le tue pull request. Quando un branch di funzione è pronto, l'AI rivede ogni commit al suo interno, scrive titolo e descrizione, costruisce una checklist di ciò che è cambiato e aggiunge note di test. Professionale, completa, e mi fa risparmiare trenta minuti di scrittura per ogni funzione.

Sbroglia i conflitti di merge. Quando due versioni di un file si scontrano, l'AI legge entrambe le versioni, capisce l'intento di ogni modifica, suggerisce una risoluzione che mantiene entrambi i miglioramenti e spiega perché l'ha scelta. Molto più veloce che confrontare le versioni a mano.

Le sei cose che l'AI non deve mai fare

1. Fare push sul tuo branch main senza conferma. Main è ciò che vedono i tuoi utenti. Conferma sempre. Sempre.
2. Fare force-push senza permesso esplicito. Un force-push riscrive la cronologia e può distruggerla. Solo quando sai esattamente perché.
3. Eliminare branch senza chiedere. I branch costano poco. Non lasciare che l'AI li ripulisca in automatico.
4. Fare commit senza revisione. È la regola che avrebbe salvato la mia chiave. Rivedi le modifiche prima di ogni commit.
5. Saltare i tuoi controlli di sicurezza. I controlli automatici pre-commit esistono per una ragione. Non lasciare mai che l'AI li aggiri.
6. Riscrivere commit che non ha creato. Modificare i commit di qualcun altro riscrive la cronologia condivisa — pericoloso nel momento in cui qualcun altro tocca il progetto.

Nota lo schema: tutto in questo elenco è irreversibile o pubblico. L'AI può redigere qualsiasi cosa; non conferma nulla.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

Il vantaggio: da 30 minuti per funzione a 4

Il motivo per impostare tutto questo bene non è solo la sicurezza — è la velocità. Ecco quanto mi costavano le incombenze git attorno a una singola funzione, prima e dopo:

Faccio da cinque a dieci commit al giorno. Sono 130–260 minuti risparmiati al giorno. Negli undici mesi passati a costruire FIKR Space, sono centinaia di ore — recuperate da un assistente che intercetta anche bug che avrei rilasciato.

Il flusso di lavoro sicuro, passo dopo passo

1. Fai le tue modifiche.
2. Esegui il tuo comando di revisione AI su tutto ciò che è cambiato.
3. Correggi ciò che segnala.
4. Lascia che l'AI rediga il messaggio di commit; approvalo o modificalo.
5. L'AI crea il commit.
6. Tu fai il push — oppure confermi esplicitamente prima che lo faccia l'AI.

E le regole di fondo: rivedi sempre le differenze prima di fare il commit, non mettere mai segreti nel codice (stanno nelle variabili d'ambiente), conferma sempre i push su main, lascia che l'AI rediga mentre tu approvi e, nel dubbio, fallo a mano.

Un push non revisionato è il modo più rumoroso in cui l'AI ti fa del male, ma è la stessa modalità di errore di quello silenzioso — accettare un output che non hai mai ispezionato finché il danno si accumula. La versione più lenta di questa storia è come l'AI sabota il tuo codice.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Perché il push è più rischioso del commit?

Un commit è un'istantanea locale sulla tua macchina — un errore lì è privato e facile da annullare. Un push pubblica quelle istantanee su GitHub, dove possono essere viste, clonate e scansionate. La mia chiave trapelata è diventata un'emergenza di quattro ore solo nel momento in cui è stata spinta. Per questo il push è il passaggio che richiede sempre un essere umano.

Che cosa devo fare se un segreto arriva su GitHub?

Trattalo come compromesso nel momento in cui arriva, anche se lo cancelli pochi secondi dopo — degli scraper automatici monitorano i repository pubblici. Ruota subito la chiave, cancella il commit dalla cronologia e controlla ogni servizio a cui quella chiave poteva accedere alla ricerca di attività sospette. Poi correggi la fonte: i segreti stanno nelle variabili d'ambiente, mai nei file che git traccia.

Posso mai lasciare che sia l'AI a fare il push?

Sì — dopo che ti ha mostrato esattamente che cosa sta per spingere e tu hai confermato esplicitamente. La regola non è "l'AI non tocca mai git"; l'AI gestisce la maggior parte del mio flusso di lavoro git. La regola è che nulla di irreversibile o pubblico avviene senza i tuoi occhi sopra.

Rivedere ogni modifica non è lento?

È il contrario, perché è l'AI a fare il grosso della revisione. Il mio flusso rivisto richiede 4 minuti per funzione contro 30 a mano — e intercetta chiavi scritte nel codice, gestione degli errori mancante e test dimenticati prima che vengano rilasciati. Le quattro ore passate a ripulire la chiave trapelata sono state il costo di aver saltato una revisione di due minuti una sola volta.