Näin kehität tekoälyllä rakennettua sovellusta rikkomatta sitä

Kun kehität tekoälyllä rakennettua sovellusta rikkomatta sitä, muuta yhtä asiaa kerrallaan, tarkista muutos esikatselussa ja tallenna tarkistuspiste ennen kuin jatkat. Kuvaa, mitä näet, älä sitä, mitä luulet koodin tekevän. Suunnittele isot muutokset ennen rakentamista. Kun muutos menee pieleen, palauta viimeisin toimiva versio sen sijaan, että pyytäisit tekoälyä korjaamaan oman korjauksensa.

Sovelluksen ensimmäinen versio valmistuu usein minuuteissa. Vaikein osa on viideskymmenes muutos, jolloin jokainen uusi kehote voi rikkoa jotain, mikä toimi jo. Tämä opas kuvaa silmukan, joka estää sen.

Kehityssilmukka

1. Valitse yksi muutos. Yksi ominaisuus, yksi virhe tai yksi sivu.
2. Kuvaa se sen kautta, mitä käyttäjä näkee ja tekee.
3. Isoille muutoksille suunnittele ensin. Pyydä suunnitelma, lue se ja rakenna vasta sitten.
4. Tarkista tulos esikatselussa: muutos itse ja sen lähellä olevat toiminnot.
5. Tallenna tarkistuspiste tai commit.
6. Toista.

Jokainen vaihe on olemassa, jotta muutokset pysyvät pieninä ja peruttavina.

Vaihe 1: Pidä lyhyttä listaa

Ennen kehotteen kirjoittamista kirjaa ylös, mitä haluat muuttaa, tärkeysjärjestyksessä. Se estää lähettämästä kappaletta kymmenen toivomusta yhdessä viestissä, ja antaa keinon sanoa "ei vielä" kesken työn syntyville ideoille.

Jos muutos on iso, pilko se. "Lisää tiimitilit" muuttuu näin: luo tiimejä, kutsu jäsen, vaihda tiimien välillä, rajaa data nykyiseen tiimiin. Jokainen on oma kehotteensa. Käyttäjätarinoiden kirjoittaminen on hyvä tapa tehdä tämä.

Vaihe 2: Kuvaa, mitä näet

Tekoäly ei näe ruutuasi, ellet kerro. Osoita tiettyjä asioita ja kerro, mitä pitäisi tapahtua:

Hinnoittelusivulla puhelimella Pro-kortin painike leikkautuu oikeasta reunasta. Pidä työpöytäasettelu samana. Alle 640 pikselin näytöillä pinoa kortit allekkain ja tee painikkeista täyden leveyden.

Vertaa tätä kehotteeseen "hinnoittelusivu näyttää huonolta mobiilissa". Ensimmäisen voi tehdä ja tarkistaa kerralla; toinen kutsuu uudelleensuunnittelun, jota et pyytänyt.

Kuvakaappaukset auttavat. Jos rakentajasi hyväksyy kuvia, liitä yksi ja ympyröi ongelma.

Vaihe 3: Suunnittele ennen isoja muutoksia

Kaikelle, mikä koskee useita sovelluksen osia, kuten uutta tietomallia, maksuja tai käyttäjärooleja, pyydä suunnitelma ennen kuin koodi muuttuu:

Älä muuta koodia vielä. Haluan, että käyttäjät kuuluvat tiimeihin ja näkevät vain oman tiiminsä projektit. Suunnittele muutos: mitkä taulut, sivut ja API-reitit muuttuvat, mitä tapahtuu olemassa olevien käyttäjien datalle ja missä järjestyksessä rakentaisit sen.

Lue suunnitelma. Jos se on väärä, suunnitelman korjaaminen on paljon halvempaa kuin rakennuksen purkaminen.

Vaihe 4: Kerro, mitä ei saa muuttaa

Tekoälytyökalut "siistivät" joskus asioita, joista et kysynyt. Suojele toimivia osia:

Lisää päivämääräsuodatin tilaustaulukkoon. Älä muuta taulukon sarakkeita, tyylejä tai vientipainiketta.

Säännöt, jotka pätevät kaikkialla, kuten brändin värit, äänensävy tai "älä koskaan poista dataa ilman vahvistusta", kirjoita projektin muistiinpanotiedostoon tai tietoasetuksiin, jonka tekoäly lukee joka kerta, sen sijaan että toistaisit ne.

Vaihe 5: Tarkista muutoksen lisäksi muuta

Testaa jokaisen kehotteen jälkeen:

• Muutos itse. Tekeekö se mitä pyysit työpöydällä ja puhelimella?
• Naapurit. Asiat samalla sivulla ja toiminnot, jotka käyttävät samaa dataa.
• Kriittinen polku. Rekisteröityminen, kirjautuminen, pääasiallinen toiminto, maksu. Kolmenkymmenen sekunnin tarkistus jokaisen ison muutoksen jälkeen löytää suurimman osan rikkoutumisista ajoissa.

Jos jokin on pielessä, kuvaa se tarkasti. Katso näin kirjoitat hyvän virheraportin.

Vaihe 6: Palauta versio sen sijaan, että kasaat korjauksia

Kun muutos rikkoo jotain eikä ensimmäinen korjaus toimi, pysähdy. Jokainen lisäkorjaus rakentuu rikkinäisen tilan päälle, ja ongelmat kertautuvat.

Tee sen sijaan näin:

1. Palauta viimeisin toimiva versio (tarkistuspiste tai Git-commit).
2. Selvitä, mikä kehotteessa oli epäselvää.
3. Yritä uudelleen pienemmällä tai selkeämmällä pyynnöllä.

Tuo muutos rikkoi luonnosten tallennuksen. Palautin version. Tällä kertaa: lisää vain automaattitallennuksen ilmaisin tekstinä otsikkoon. Älä muuta luonnosten tallennustapaa.

Vaihe 7: Tiedä, milloin uudelleenrakentaminen on oikea ratkaisu

Rakentaminen alusta poistaa paljon toimivaa yksityiskohtaa. Se kannattaa vain, kun:

• Tuoteidea on muuttunut kokonaan.
• Rakenne ei kestä tarvitsemaasi. Esimerkiksi se on rakennettu staattiseksi sivustoksi, ja nyt se tarvitsee tilejä ja tietokannan.
• Projekti on vielä lähes tyhjä.

Kun rakennat uudelleen, listaa, mitä säilytetään: nimi, värit, tekstit ja osat, joista käyttäjät pitivät.

Esimerkkikehotteet

Ennen kuin jatkamme, tiivistä, miten sovellus toimii nyt: sivut, tallennettava data ja kaikki, mikä mielestäsi on hauras.

Haluan lisätä toistuvat varaukset. Mikä on pienin hyödyllinen versio? Ehdota se kolmena erillisenä muutoksena, jotka teemme yksi kerrallaan.

Käy läpi kolme viimeisintä muutosta ja kerro, mikä niistä on voinut rikkoa kassavirran. Älä muokkaa vielä.

Yleisiä virheitä

• Kymmenen pyyntöä yhdessä kehotteessa. Osa tehdään, osa puolitehdään, eikä voi tietää, mitkä.
• Epämääräinen palaute. "Se on rikki" tai "tee paremmaksi" tuottaa arvauksia.
• Naapurien tarkistamatta jättäminen. Muutos jaettuun komponenttiin rikkoo kolme muuta sivua.
• Korjausten korjaaminen. Kun olet neljän kehotteen päässä samasta virheestä, palauta versio.
• Kontekstin toistaminen joka kerta sen sijaan, että pysyvät säännöt olisivat projektin muistiinpanoissa.
• Uudelleenrakentaminen jumiutuessa. Useimmat "aloitetaan alusta" -hetket tarkoittavat oikeasti "palautetaan kaksi askelta".

Tarkistuslista

• Yksi tavoite per kehote.
• Kuvaan, mitä näen ja mitä pitäisi tapahtua.
• Isot muutokset saavat suunnitelman ennen koodia.
• Sanon, mitä ei saa muuttaa.
• Testaan jokaisen muutoksen, sen naapurit ja kriittisen polun.
• Tallennan tarkistuspisteen tai commitin jokaisen toimivan muutoksen jälkeen.
• Kun korjaus epäonnistuu, palautan version sen sijaan, että kasaisin korjauksia.
• Pysyvät säännöt ovat projektin muistiinpanoissa, jotka tekoäly lukee joka kerta.

Kehittäminen Mythexissä

Mythex on rakennettu tämän silmukan ympärille:

• Suunnittelu-, rakennus- ja kysymystilat. Suunnittelu keskustelee lähestymistavasta ennen muokkausta; Kysy vastaa muuttamatta koodia; Rakenna tekee muutoksen. Katso Chat.
• Tarkistuspisteet. Jokaisen onnistuneen vuoron jälkeen Mythex tallentaa git-tarkistuspisteen, ja Palaa tähän kohtaan palauttaa version. Voit myös muokata aiempaa viestiä ja valita Hylkää ja lähetä uudelleen kokeillaksesi eri kehotetta siitä kohdasta. Katso Kehitä ilman uudelleenrakentamista.
• Tietopohja. Projektin asetukset → Tietopohja sisältää pysyviä muistiinpanoja, joita agentti noudattaa jokaisessa viestissä.
• /test saa agentin klikkaamaan esikatselun läpi kuin käyttäjä isomman muutoksen jälkeen.

Pienemmät pyynnöt maksavat myös vähemmän krediittejä. Kehotteiden kirjoittamiseen katso näin kirjoitat kehotteita tekoälysovellusrakentajille. Kun jokin rikkoutuu, katso näin debugaat tekoälyllä rakennetun sovelluksen.

Kysymykset