Com iterar en una app creada amb IA sense trencar-la

Per iterar en una app creada amb IA sense trencar-la, canvia una cosa per prompt, comprova-la a la vista prèvia i desa un punt de control abans de continuar. Descriu què veus en lloc del que creus que fa el codi, planifica els canvis grans abans de construir-los i, quan un canvi surt malament, torna a l’última versió bona en lloc de demanar a la IA que arregli el seu propi arreglo.

La primera versió d’una app sovint es completa en minuts. La part difícil és el cinquantè canvi, quan cada prompt nou corre el risc de trencar alguna cosa que ja funcionava. Aquesta guia és el bucle que evita que passi.

El bucle d’iteració

1. Tria un canvi. Una funció, un error, una pàgina.
2. Descriu-lo en termes del que l’usuari veu i fa.
3. Per als canvis grans, planifica primer. Demana un pla, llegeix-lo i després construeix.
4. Comprova el resultat a la vista prèvia: el canvi i els fluxos que hi ha al costat.
5. Desa un punt de control o un commit.
6. Repeteix.

Cada pas existeix per mantenir els canvis petits i reversibles.

Pas 1: mantén una llista curta

Abans de fer un prompt, apunta què vols canviar, per ordre d’importància. Així no envies un paràgraf amb deu desitjos en un sol missatge, i tens manera de dir «ara no» a les idees que surten a mig camí.

Si un canvi és gran, divideix-lo. «Afegir comptes d’equip» es converteix en: crear equips, convidar un membre, canviar entre equips, limitar les dades a l’equip actual. Cadascun és un prompt propi. Escriure historries d’usuari és una bona manera de fer-ho.

Pas 2: descriu el que veus

La IA no veu la teva pantalla si no li ho dius. Assenyala coses concretes i digues què hauria de passar:

A la pàgina de preus en un mòbil, el botó de la targeta Pro està retallat a la vora dreta. Mantén el disseny d’escriptori igual; en pantalles de menys de 640 px, apila les targetes i fes els botons d’amplada completa.

Compara-ho amb «la pàgina de preus es veu malament en mòbil». El primer es pot fer i comprovar d’una vegada; el segon convida a un redisseny que no has demanat.

Les captures ajuden. Si el teu constructor accepta imatges, adjunta-n’una i marca el problema.

Pas 3: planifica abans dels canvis grans

Per a qualsevol cosa que toqui diverses parts de l’app —un nou model de dades, pagaments, rols d’usuari—, demana un pla abans que el codi canviï:

No canviïs el codi encara. Vull que els usuaris pertanyin a equips i vegin només els projectes del seu equip. Planifica el canvi: quines taules, pàgines i rutes d’API canvien, què passa amb les dades dels usuaris existents, i en quin ordre ho construiries.

Llegeix el pla. Si és incorrecte, corregir un pla és molt més barat que desfer una construcció.

Pas 4: digues què no ha de canviar

Les eines d’IA de vegades «netegen» coses que no has demanat. Protegeix el que funciona:

Afegeix un filtre de dates a la taula de comandes. No canviïs les columnes de la taula, l’estil ni el botó d’exportació.

Per a les regles que s’apliquen a tot arreu —colors de marca, to de veu, «mai no esborris dades sense confirmació»—, posa-les en un fitxer de notes del projecte o en la configuració de coneixement que la IA llegeix cada vegada, en lloc de repetir-les.

Pas 5: comprova més que el canvi

Després de cada prompt, prova:

• El canvi en si. Fa el que has demanat, a l’escriptori i al mòbil?
• Els veïns. Coses de la mateixa pàgina i fluxos que fan servir les mateixes dades.
• El camí crític. Registre, inici de sessió, l’acció principal, el pagament. Una revisió de trenta segons després de cada canvi gran detecta gran part dels trencaments d’hora.

Si alguna cosa no quadra, descriu-la amb precisió; consulta com escriure un bon informe d’error.

Pas 6: fes marxa enrere en lloc d’acumular arreglos

Quan un canvi trenca alguna cosa i el primer arreglo no funciona, para. Cada «arreglo» addicional es construeix sobre un estat trencat, i els problemes s’agreugen.

En lloc d’això:

1. Torna a l’última versió que funcionava (un punt de control o un commit de Git).
2. Pensa què era poc clar al prompt.
3. Torna-ho a intentar amb una petició més petita o més clara.

Aquell canvi ha trencat el desat d’esborranys. He fet marxa enrere. Aquesta vegada: afegeix només l’indicador de desat automàtic, com a text a la capçalera. No canviïs com es desen els esborranys.

Pas 7: saber quan refer és el correcte

Refer des de zero descarta molts detalls que funcionen. Només val la pena quan:

• La idea del producte ha canviat per complet.
• L’estructura subjacent no pot donar suport al que ara necessites; per exemple, es va construir com un lloc estàtic i ara necessita comptes i una base de dades.
• El projecte encara està gairebé buit.

Quan refas, fes una llista del que cal conservar: nom, colors, text, les parts que els usuaris van apreciar.

Exemples de prompts

Abans de continuar, resumeix com funciona ara mateix l’app: pàgines, dades que guarda i qualsevol cosa que creguis que és fràgil.

Vull afegir reserves recurrents. Quina és la versió més petita que seria útil? Suggereix-la com a tres canvis separats que puguem fer un a un.

Revisa els tres últims canvis per veure si alguna cosa pot haver trencat el flux de pagament. No editis encara.

Errors habituals

• Deu peticions en un sol prompt. Algunes es fan, algunes a mitges, i no pots saber quines.
• Feedback vague. «Està trencat» o «fes-ho millor» produeix suposicions.
• No comprovar els veïns mai. Un canvi en un component compartit trenca tres altres pàgines.
• Arreglar arreglos. Quatre prompts després d’un error, fes marxa enrere.
• Repetir el context cada vegada en lloc de guardar les regles permanents a les notes del projecte.
• Refer quan et bloquegis. La majoria dels moments de «tornem a començar» són en realitat «torna enrere dos passos».

Llista de comprovació

• Un objectiu per prompt.
• Descric el que veig i el que hauria de passar.
• Els canvis grans tenen un pla abans de qualsevol codi.
• Dic què no ha de canviar.
• Després de cada canvi, el comprovo, els seus veïns i el camí crític.
• Desso un punt de control o un commit després de cada canvi que funciona.
• Quan un arreglo falla, faig marxa enrere en lloc d’acumular arreglos.
• Les regles permanents viuen a les notes del projecte que la IA llegeix cada vegada.

Iterar a Mythex

Mythex està construït al voltant d’aquest bucle:

• Modes Plan, Build i Ask. Plan discuteix l’enfocament abans d’editar; Ask respon sense canviar el codi; Build fa el canvi. Consulta Xat.
• Punts de control. Després de cada torn amb èxit, Mythex desa un punt de control de Git; Revert to this point fa marxa enrere. També pots editar un missatge anterior i fer Discard & resend per provar un prompt diferent des d’aquell punt. Consulta Itera sense refer.
• Coneixement. Configuració del projecte → Knowledge conté notes permanents que l’agent segueix a cada missatge.
• /test fa que l’agent faci clic per la vista prèvia com un usuari després d’un canvi gran.

Les peticions més petites també costen menys crèdits. Per escriure els prompts, consulta com escriure prompts per a constructors d’apps amb IA; quan alguna cosa es trenca, com depurar una app creada amb IA.

Preguntes