Com treballar amb un desenvolupador en una app creada amb IA
Per treballar bé amb un desenvolupador en una app creada amb IA, dona-li el codi en un repositori de Git, un resum d’una pàgina de què fa l’app i per què, i una tasca ben delimitada amb una definició de «acabat». Acordeu qui canvia quines parts perquè tu i la IA no sobreescriviu la seva feina, mantén el repositori i els comptes d’allotjament a nom teu, i comparteix els secrets a través de la configuració adequada, no per missatges.
Molta gent construeix la primera versió d’una app amb IA i després incorpora un desenvolupador per afegir pagaments, arreglar alguna cosa que la IA segueix fent malament, revisar la seguretat o assumir el projecte quan l’app creix. Si encara estàs decidint si contractar algú, consulta contractar un desenvolupador o construir amb IA. Aquesta guia parteix que ja has decidit, i vols que la col·laboració vagi bé.
Quan val la pena un desenvolupador
Motius habituals per incorporar algú:
- Un problema que la IA no resol després de diversos intents clars i reversions.
- Àrees de risc: pagaments, permisos, dades sensibles, migracions de la base de dades.
- Una revisió de seguretat o de codi abans del llançament o abans de captar clients més grans.
- Rendiment quan arriba trànsit real.
- Creixement: l’app s’ha convertit en un negoci i necessita algú que en sigui responsable del codi.
Tenir clar quin d’aquests motius és el cas determina tota la resta.
Pas 1: posa el codi en un lloc compartible
Les persones desenvolupadores treballen des de repositoris de Git. Abans de contactar ningú:
- Connecta el projecte a un repositori privat de GitHub (o similar), o exporta’l.
- Assegura’t que no hi hagi secrets al codi ni a l’historial. Consulta com mantenir segures les claus d’API.
- Comprova que el projecte s’executa des d’una còpia neta: demana a la IA que escrigui els passos de configuració.
Escriu un README per a un desenvolupador que s’incorpora a aquest projecte: què fa l’app, la tecnologia que fa servir, com instal·lar-la i executar-la en local, les variables d’entorn que necessita (només els noms), l’estructura de carpetes i qualsevol cosa fràgil o inusual.
Si Git és nou per a tu, com fer servir Git amb una app creada amb IA explica els fonaments.
Pas 2: escriu un resum d’una pàgina
El desenvolupador no ha viscut el teu historial de xat. Dona-li el context en una pàgina:
- Què fa l’app, per a qui i quantes persones la fan servir.
- Què és més important: els fluxos que mai no han de fallar.
- Problemes coneguts i què has provat ja.
- La tasca, i com sabràs que està feta.
- Restriccions: pressupost, termini, coses que no han de canviar.
Una bona «definició de feta» és comprovable: «Un usuari que ha iniciat sessió pot pagar un pla mensual amb Stripe Checkout, el pla apareix a la pàgina del seu compte, i en cancel·lar al portal de client es passa al pla inferior al final del període.» No pas «arregla els pagaments».
Pas 3: dona accés de manera segura
- Codi: afegeix-los com a col·laboradors del repositori. No enviïs fitxers ZIP d’un costat a l’altre quan el treball ja ha començat.
- Constructor: si el teu constructor d’IA admet membres d’equip, convida’ls a un espai de treball que només contingui aquest projecte.
- Secrets: afegeix-los a la configuració del teu allotjament, o comparteix-los amb un gestor de contrasenyes. Mai no enganxis claus al correu ni al xat.
- Comptes de prova: crea’ls amb dades de prova, en lloc de compartir el teu propi inici de sessió.
- Dades de producció: només si realment les necessiten, i només les que necessitin.
Mantén el repositori, el domini i els comptes d’allotjament a nom teu. Afegeix persones; no els traspassis els comptes.
Pas 4: acordeu qui canvia què
La major font de fricció és que dues parts, tu amb una IA i el desenvolupador, canviïn el mateix codi al mateix temps. Trieu una regla:
| Enfocament | Com funciona | Adequat per a |
|---|---|---|
| Dividir per àrea | Tu i la IA treballeu el text, les pàgines i l’estil; el desenvolupador es fa càrrec dels pagaments, les dades i l’API | Col·laboració continuada |
| Torns | Pauses la IA mentre el desenvolupador treballa en una branca, i després fas pull dels seus canvis | Una tasca única i ben definida |
| Traspàs complet | El desenvolupador en prengui el control; tu fas les peticions i els informes d’error | L’app ha crescut més enllà del constructor |
Triïs el que triïs: fes pull del codi més recent abans de cada sessió de peticions, i fes els canvis grans en branques que l’altra persona pugui revisar.
Pas 5: comunica’t per escrit
- Informa dels problemes amb els passos, el resultat esperat i el resultat real. Consulta com escriure un bon informe d’error.
- Guarda les decisions en un sol lloc: un registre d’incidències, un document compartit o els comentaris de les pull requests.
- Demana que expliquin els canvis en llenguatge clar a cada pull request.
- Acordeu amb quina freqüència us posareu al dia.
Pas 6: revisa el seu treball
No cal que llegeixis el codi per revisar la feina. Comprova:
- Fa el que deia el resum, a la vista prèvia o a la còpia de staging.
- Que no s’hagi trencat res més: executa els teus fluxos crítics.
- Que ho han explicat: què han canviat i per què.
- Que no hi ha secrets al codi.
Per a una mirada més detallada, com revisar el codi generat per IA té una llista de comprovació que també funciona per al codi escrit per persones. També pots demanar al teu constructor d’IA que t’expliqui en termes senzills una pull request del desenvolupador.
Pas 7: mantén clara la propietat
- El repositori, l’allotjament, el domini i els comptes de tercers segueixen sent teus.
- Posa per escrit la propietat del codi que escriuen abans que comenci el treball. Consulta la normativa local o un assessor per a les qüestions contractuals.
- Quan acabi el treball, elimina’n l’accés i renova les claus que hagin vist.
Exemples de peticions
Un desenvolupador ha canviat el codi del pagament en l’última pull. Explica en llenguatge planer què ha canviat i si alguna altra part de l’app en depèn.
Fes una llista de les parts d’aquesta app més complexes o arriscades, perquè pugui indicar a un desenvolupador on centrar la revisió.
Estic passant els pagaments a un desenvolupador. A partir d’ara, no toquis cap fitxer dins de src/payments ni les rutes /api/billing. Si un canvi les necessita, digue’m-ho en lloc de fer-lo.
Errors habituals
- No tenir un resum. El desenvolupador gasta hores pagades endevinant què volies.
- Un abast vague, com «arregla els errors» o «fes-ho llest per a producció».
- Editar els dos al mateix temps sense fer pull primer, i perdre feina en els conflictes.
- Compartir el teu propi inici de sessió o enganxar claus al xat.
- Comptes a nom del desenvolupador, que dificulten separar-se’n.
- Oblidar eliminar l’accés i renovar les claus en acabar la feina.
Llista de comprovació
- El codi és en un repositori privat a nom meu, sense secrets.
- Un README explica la configuració; un resum d’una pàgina explica l’app i la tasca.
- La tasca té una definició de «acabat» comprovable.
- L’accés es fa mitjançant invitacions de col·laborador, i els secrets, a través de la configuració o d’un gestor de contrasenyes.
- Hem acordat qui canvia què, i jo faig pull abans de fer peticions.
- El treball es revisa contra el resum i els fluxos crítics.
- La propietat és per escrit; quan acaba el treball, s’elimina l’accés i es renoven les claus.
Treballar amb un desenvolupador a Mythex
- Convida’l a un espai de treball. Els propietaris poden convidar col·laboradors il·limitats sense cost per lloc; els membres treballen en els projectes de l’espai. Fes servir un espai de treball separat perquè només vegi aquest projecte. Els crèdits de les apps publicades es facturen al propietari de l’espai. Consulta Invitacions.
- Sincronització amb GitHub i exportació (Pro). Connecta un repositori i fes push i pull, o exporta el projecte sense els secrets. Consulta GitHub, exportació i importació.
- Comparteix un enllaç de vista prèvia per mostrar el treball en curs a algú sense compte de Mythex; esborra’l quan hagis acabat.
- El mode Pregunta respon preguntes sobre el codi sense canviar-lo; és útil per entendre els canvis d’un desenvolupador.
Si el desenvolupador executarà l’app en un altre lloc, consulta com exportar i allotjar pel teu compte una app creada amb IA.
Preguntes
Podrà un desenvolupador treballar en un codi que ha escrit una IA?
Normalment, sí. Els constructors d’apps amb IA produeixen sobretot codi estàndard amb frameworks comuns com React i TypeScript, que els desenvolupadors ja coneixen. Espera que n’hagin de llegir una part primer i que, en alguns punts, suggereixin una neteja.
He de seguir fent servir el constructor d’IA després de contractar un desenvolupador?
Pots fer-ho, però primer acordeu les regles. La divisió més simple és per àrea: tu t’encarregues del text i els retocs de les pàgines, mentre el desenvolupador es fa càrrec dels pagaments i les dades. Fes sempre pull del codi més recent abans de fer una petició, perquè cap dels dos no sobreescrigui la feina de l’altre.
Com em puc assegurar que sóc propietari del codi que escriu un desenvolupador?
Mantén el repositori i els comptes d’allotjament a nom teu i afegeix el desenvolupador com a col·laborador. Posa per escrit la propietat del treball abans que comenci i consulta la normativa local o un assessor per a les qüestions contractuals.
Què he de donar a un desenvolupador abans que comenci?
Accés al codi, una descripció curta de què fa l’app i de qui l’utilitza, la llista de problemes coneguts, la tasca que vols que faci amb la manera com jutjaràs que està acabada, i comptes de prova. Comparteix els secrets a través de la configuració del teu allotjament o d’un gestor de contrasenyes, no pel xat.