Suurimmat poimintoni tekoälyn prototyyppien tekemisestä Magic Patternsin toimitusjohtajalta @alexdanilowicz 1. Suunnittelujärjestelmän integrointi on piilevä kilpailuetu tekoälyn prototyyppien valmistuksessa. Magic Patterns rakensi "esiasetuksia", joiden avulla voit tuoda varsinaisen komponenttikirjastosi ennen rakentamisen aloittamista. Kyse ei ole vain siitä, että asiat näyttävät kauniilta. Kyse on siitä, voidaanko prototyyppiäsi todella käyttää käyttäjätutkimuksessa tai luovuttaa sidosryhmille ilman, että kaikki kysyvät: "Miksi tämä ei näytä tuotteeltamme?" Chrome-laajennus hakee komponentteja suoraan Storybookista tai tuotantosivustoista ja muuntaa ne automaattisesti Tailwindiksi. Useimmat työkalut ohittavat tämän, koska ne on optimoitu "ideasta sovellukseen" eikä "ideaan ja tuotantoon, joka sopii suunnittelujärjestelmäämme". 2. Iteroinnin laadulla on äärettömän paljon enemmän merkitystä kuin ensimmäisen pyynnön laadulla. Live-leivonnaisissaan Magic Patterns ja V0 olivat käytännössä tasapisteissä erilaisista ensimmäisen kehotteen tuloksista huolimatta. Alkuperäisten tulosteiden satunnaisuus on korkea, mutta hyvät työkalut erottaa loistavista se, miten ne käsittelevät seuraavat 500 kehotetta. Alex näkee, että asiakkaat turhautuvat ja roskaposti "ei toimi, ei toimi, ei toimi", mikä vain pahentaa tilannetta saastuttamalla kontekstia. Magic Patterns rakensi "/debug"-komennon erityisesti murtaakseen tekoälyn pois tuomiosilmukoista. Työkalu, jolla voit iteroida tuntikausia, voittaa työkalun joka kerta näyttävällä ensimmäisellä tuloksella. 3. Tiedä, milloin tarvitset prototyypin verrattuna täydelliseen sovellukseen. Replit kehotti käyttäjiä lisäämään OpenAI API -avaimensa leivonta-offin aikana, mikä hidasti sitä, mutta lisäsi todellista toiminnallisuutta. Magic Patterns ohittaa tämän tarkoituksella, koska he keskittyvät visuaalisten prototyyppien luomiseen käyttäjätutkimuksessa, eivät tuotantosovellusten rakentamiseen. Jos validoit konseptin käyttäjien kanssa, et tarvitse Supabase-integraatiota. Mutta jos olet jo vahvistanut ja sinun on lähetettävä, haluat täyden pinon työkalut. Virhe on käyttää kaksi tuntia tietokantojen virheenkorjaukseen, kun tarvitsit vain interaktiivisen mallin viidelle asiakkaalle. 4. Tekoälyn prototyyppien luominen voi pudottaa tuotteiden epäonnistumisprosentin 80 prosentista 50 prosenttiin. Yli 80 % rakennetuista ominaisuuksista ei saavuta tavoitemittareitaan. Mutta kun laitat todellisen prototyypin käyttäjien eteen ennen rakentamista, voit tarkistaa, onko se käyttökelpoinen, kannattava yritykselle ja ymmärtävätkö käyttäjät, mitä tehdä seuraavaksi. Tämä oli aiemmin mahdotonta, koska Figma-prototyyppien luominen vaati suunnittelijan aikaa. Nyt projektipäälliköt voivat siirtyä ideasta testattavaksi prototyypiksi 10 minuutissa ja saada suoraa asiakaspalautetta ennen kuin he kirjoittavat yhden tuotantokoodirivin. Tästä pitäisi tulla vakiokäytäntö jokaiselle merkittävälle ominaisuudelle, ei vain suurimmille panoksille. 5. Parhaat perustajat aloittavat ratkaisemalla oman tuskallisen ongelmansa ennen kuin trendi on ilmeinen. Alex ja hänen perustajansa olivat front-end-insinöörejä, jotka käyttivät kaiken aikansa Figma-mallien toteuttamiseen. Elokuussa 2023, ennen V0:n julkaisua ja ennen kuin kukaan muu näki mahdollisuuden, he lisäsivät tekoälyn komponenttikirjastoeditoriinsa sisäisen hackathonin aikana. Kun V0 lanseerattiin kaksi kuukautta myöhemmin, ihmiset kertoivat heille kuolleensa. Mutta heillä oli ainutlaatuinen näkemys, koska he lähestyivät tekoälyn prototyyppien tekemistä "miten käytän todellisia tuotantokomponenttejani" -kulmasta, kun taas toiset lähestyivät sitä verkkokonteista tai muista teknologioista. Epäreilu etusi tulee siitä, että ymmärrät ongelmatilan syvällisesti ennen tekoälyn lisäämistä siihen.