Come lavorare con uno sviluppatore su un'app creata con l'IA

Per lavorare bene con uno sviluppatore su un'app creata con l'IA, dagli il codice in un repository Git, un riepilogo di una pagina su cosa fa l'app e perché, e un compito chiaramente definito con una definizione di "completato". Concordate chi cambia quali parti, così né tu né l'IA sovrascrivete il suo lavoro, tieni il repository e gli account di hosting a tuo nome e condividi i segreti tramite le impostazioni appropriate, non tramite messaggi.

Molte persone costruiscono la prima versione di un'app con l'IA e poi coinvolgono uno sviluppatore: per aggiungere pagamenti, risolvere qualcosa che l'IA continua a sbagliare, revisionare la sicurezza o subentrare quando l'app cresce. Se stai ancora decidendo se assumere qualcuno, vedi assumere uno sviluppatore o costruire con l'IA. Questa guida presuppone che tu abbia già deciso e voglia che la collaborazione proceda senza intoppi.

Quando conviene uno sviluppatore

Motivi comuni per coinvolgere qualcuno:

• Un problema che l'IA non riesce a risolvere dopo diversi tentativi chiari e ripristini.
• Aree a rischio: pagamenti, permessi, dati sensibili, migrazioni del database.
• Una revisione di sicurezza o del codice prima del lancio o prima di accogliere clienti più grandi.
• Prestazioni quando arriva il traffico reale.
• Crescita: l'app è diventata un'attività e ha bisogno di qualcuno che sia responsabile del codice.

Essere chiari su quale di questi motivi vale per te determina tutto ciò che segue.

Passo 1: porta il codice in un luogo condivisibile

Gli sviluppatori lavorano a partire da repository Git. Prima di contattare qualcuno:

1. Collega il progetto a un repository privato su GitHub (o simile), oppure esportalo.
2. Assicurati che nel codice o nella cronologia non ci siano segreti. Vedi come tenere al sicuro le chiavi API.
3. Verifica che il progetto si avvii da una copia nuova: chiedi all'IA di scrivere i passaggi di installazione.

Scrivi un README per uno sviluppatore che si unisce a questo progetto: cosa fa l'app, lo stack, come installarla ed eseguirla in locale, le variabili d'ambiente necessarie (solo i nomi), la struttura delle cartelle e tutto ciò che è fragile o insolito.

Se Git ti è nuovo, come usare Git con un'app creata con l'IA copre le basi.

Passo 2: scrivi un brief di una pagina

Lo sviluppatore non ha seguito la tua cronologia di chat. Dagli il contesto in una pagina:

• Cosa fa l'app, per chi, e quante persone la usano.
• Cosa conta di più: i flussi che non devono mai rompersi.
• Problemi noti e ciò che hai già provato.
• Il compito, e come saprai che è completato.
• Vincoli: budget, scadenza, cose che non devono essere cambiate.

Una buona "definizione di completato" è verificabile: "Un utente connesso può pagare un piano mensile con Stripe Checkout, il piano compare nella pagina del suo account e annullando dal portale clienti viene retrocesso alla fine del periodo." Non "sistema i pagamenti".

Passo 3: dai l'accesso in modo sicuro

• Codice: aggiungilo come collaboratore del repository. Non scambiatevi file ZIP una volta iniziato il lavoro.
• Builder: se il tuo builder di app con IA supporta i membri del team, invitalo in uno spazio di lavoro che contenga solo questo progetto.
• Segreti: aggiungili nelle impostazioni del tuo hosting, oppure condividili tramite un gestore di password. Non incollare mai chiavi in email o chat.
• Account di prova: creali con dati di test, invece di condividere il tuo login.
• Dati di produzione: solo se ne ha davvero bisogno, e solo quelli necessari.

Tieni il repository, il dominio e gli account di hosting a tuo nome. Aggiungi persone; non consegnare gli account.

Passo 4: concordate chi cambia cosa

La fonte principale di attriti sono due parti, tu con un'IA e lo sviluppatore, che modificano lo stesso codice nello stesso momento. Scegli una regola:

Qualunque cosa scegliate: esegui il pull del codice più recente prima di ogni sessione di prompt, e fai le modifiche grandi su branch che l'altra persona può revisionare.

Passo 5: comunicate per iscritto

• Segnala i problemi con i passaggi, il risultato atteso e quello effettivo. Vedi come scrivere una buona segnalazione di bug.
• Tieni le decisioni in un unico posto: un tracker di issue, un documento condiviso o i commenti delle pull request.
• Chiedi che spieghi ogni modifica in linguaggio semplice in ogni pull request.
• Concordate con quale frequenza vi aggiornerete.

Passo 6: revisiona il loro lavoro

Non serve leggere il codice per revisionare il lavoro. Verifica:

• Fa ciò che diceva il brief, nell'anteprima o nella copia di staging.
• Non si è rotto nient'altro: esegui i tuoi flussi critici.
• Ti hanno spiegato cosa hanno cambiato e perché.
• Non compaiono segreti nel codice.

Per un controllo più approfondito, come revisionare il codice generato dall'IA include una checklist che funziona anche per il codice scritto da persone. Puoi anche chiedere al tuo builder con IA di spiegarti in termini semplici la pull request di uno sviluppatore.

Passo 7: mantieni chiara la proprietà

• Il repository, l'hosting, il dominio e gli account di terze parti restano tuoi.
• Mettete per iscritto la proprietà del codice che scrivono prima che il lavoro inizi. Per le questioni contrattuali verifica le norme locali o rivolgiti a un consulente.
• Quando il lavoro finisce, rimuovi il loro accesso e sostituisci le chiavi che hanno visto.

Esempi di prompt

Uno sviluppatore ha modificato il codice del checkout nell'ultima pull. Spiega in linguaggio semplice cosa ha cambiato e se qualcos'altro nell'app dipende da quella modifica.

Elenca le parti di questa app più complesse o rischiose, così posso indicare a uno sviluppatore su cosa concentrare la revisione.

Affido i pagamenti a uno sviluppatore. D'ora in poi non toccare i file in src/payments o le route /api/billing. Se una modifica li richiede, dimmelo invece di farla.

Errori comuni

• Nessun brief. Lo sviluppatore passa ore pagate a ricostruire cosa volevi.
• Ambito vago, come "sistema i bug" o "rendila pronta per la produzione".
• Modificare entrambi nello stesso momento senza fare il pull, per poi perdere lavoro nei conflitti.
• Condividere il tuo login o incollare chiavi in chat.
• Account a nome dello sviluppatore, che rendono difficile separarsi.
• Dimenticare di rimuovere l'accesso e di sostituire le chiavi a lavoro finito.

Checklist

• Il codice è in un repository privato a mio nome, senza segreti.
• Un README spiega l'installazione; un brief di una pagina spiega l'app e il compito.
• Il compito ha una definizione di completato verificabile.
• L'accesso avviene tramite inviti da collaboratore, i segreti tramite impostazioni o un gestore di password.
• Abbiamo concordato chi cambia cosa, e faccio il pull prima di scrivere un prompt.
• Il lavoro viene revisionato rispetto al brief e ai flussi critici.
• La proprietà è scritta; a fine lavoro l'accesso viene rimosso e le chiavi sostituite.

Lavorare con uno sviluppatore su Mythex

• Invitalo in uno spazio di lavoro. I proprietari possono invitare collaboratori senza limiti e senza costi per postazione; i membri lavorano sui progetti dello spazio di lavoro. Usa uno spazio di lavoro separato, così vedono solo questo progetto. I crediti per le app pubblicate vengono addebitati al proprietario dello spazio di lavoro. Vedi Inviti.
• Sincronizzazione GitHub ed esportazione (Pro). Collega un repository e fai push e pull, oppure esporta il progetto senza segreti. Vedi GitHub, esportazione e importazione.
• Condividi un link di anteprima per mostrare il lavoro in corso a qualcuno senza un account Mythex; eliminalo quando hai finito.
• La modalità Chiedi risponde a domande sul codice senza modificarlo, utile per capire le modifiche di uno sviluppatore.

Se lo sviluppatore eseguirà l'app altrove, vedi come esportare e ospitare autonomamente un'app creata con l'IA.

Domande