Tunnelmavoodaus: Projektipäälliköt käyttävät luonnollisen kielen kehotteita tekoälytyökaluissa yksilöllisten ohjelmistoratkaisujen rakentamiseen.
Erikoistuneet ratkaisut: Tunnelmavoodaus mahdollistaa erikoistuneiden työkalujen luomisen tiettyihin toimialojen ongelmiin, joita vakiomuotoiset ohjelmistot eivät ratkaise.
Tehokkuus: Tekoälyn avulla rakennetut sovellukset vähentävät huomattavasti aikaa ja resursseja perinteiseen ohjelmistokehitykseen verrattuna.
Kaupallinen potentiaali: Tunnelmavoodaus laajenee sisäisistä työkaluista markkinoille valmiisiin tuotteisiin, joita maksavat asiakkaat voivat hyödyntää.
Testauksen tärkeys: Uusien ominaisuuksien perusteellinen testaaminen ennen tuotantokäyttöä on ratkaisevan tärkeää sovelluksen toiminnallisuuden säilyttämiseksi.
Projektipäälliköt käyttävät uransa työnkulkujen kartoittamiseen, puutteiden tunnistamiseen ja sekavan todellisuuden muuntamiseen selkeiksi prosesseiksi. Tämä osaaminen osoittautuu juuri sellaiseksi, jota tarvitset ohjelmistojen rakentamiseen – vaikka et olisi koskaan kirjoittanut riviäkään koodia. Vibekoodaus, eli toimivien sovellusten rakentaminen tekoälytyökaluille annettavien luonnollisen kielen kehotteiden avulla, antaa projektipäälliköille jotain, mitä heillä ei ole koskaan aiemmin ollut: mahdollisuuden rakentaa juuri tarvitsemansa työkalu sen sijaan, että he tyytyisivät lähes sopivaan vaihtoehtoon.
Alla olevat käyttötapaukset ovat peräisin eri alojen ammattilaisilta, jotka tekevät juuri näin – jotkut rakentavat sisäisiä työkaluja manuaalisen työn poistamiseksi, toiset asiakkaille suunnattuja tuotteita, ja jotkut ovat lähellä täysin vibekoodatun alustan tuomista markkinoille.
Työn laajuuden määrittäjä (sisustussuunnittelun operatiivinen toiminta)
Poised & Plumb -yrityksen perustajalle ja johtavalle projektistrategille Dixie Willardille päätöstä vibekoodaukseen ei ohjannut uteliaisuus tai kokeilunhalu. Sen taustalla oli se, että hänen tarvitsemansa ratkaisu ei yksinkertaisesti ollut olemassa. Willard konsultoi sisustussuunnittelijoita ja niihin liittyviä palveluyrityksiä auttaen niitä arvioimaan ohjelmistoja, rakentamaan projektien työnkulkuja ja vähentämään toiminnan kitkaa. Kun hän etsi työkalua, joka auttaisi suunnittelijoita laatimaan työn laajuuden määrittelyn heti asiakaskonsultoinnin aikana, hän ei löytänyt mitään. ”Sellaista ei ole”, hän sanoi. ”Ja on paljon asioita, joita suunnittelijat voisivat käyttää, mutta joita ei yksinkertaisesti ole olemassa.”
Sellaista [työn laajuuden määrittelyyn tarkoitettua työkalua] ei ole. Ja on paljon asioita, joita suunnittelijat voisivat käyttää, mutta joita ei yksinkertaisesti ole olemassa.
Niinpä hän rakensi sellaisen itse. Hänen parhaillaan kehittämänsä työkalu on mobiiliystävällinen verkkosovellus, joka on tarkoitettu käytettäväksi reaaliajassa ensimmäisen asiakaskeskustelun aikana. Willard kuvailee sitä ”joksikin, joka voisi olla tabletillasi tai puhelimellasi, kun menet ensimmäiseen konsultaatioon. Keskustelun aikana merkitset asioita tehdyiksi sitä mukaa kun etenet, ja kun olette valmiit, sinulla on hienosti laadittu työn laajuuden määrittely ilman, että sinun tarvitsee tehdä muistiinpanoja.”
Toinen hänen työn alla oleva projektinsa ratkaisee toisen operatiivisen puutteen: erityisesti sitä varten rakennetun voittomarginaalilaskurin, jolla suunnittelijat hinnoittelevat ja korottavat asiakkaiden tuotteiden hintoja. Jälleen kerran syy sen itse rakentamiseen oli sama – ”Sellaista ei ole. Sellaista ei vain ole.”
Willardin tilanne havainnollistaa kaavaa, joka toistuu usein niiden projektipäälliköiden keskuudessa, jotka ovat lähteneet tälle tielle. Mitä erikoistuneempi toimialasi on, sitä todennäköisempää on, ettei markkinoilta löytyvää valmista työkalua ole rakennettu juuri sinun ongelmaasi varten. Kuten hän asian ilmaisi: ”Uskon, että erikoistuneet käyttötapaukset ovat todennäköisesti suurin syy vibekoodata työkaluja. Se yksinkertaisesti helpottaa elämää niin paljon.”
Uskon, että erikoistuneet käyttötapaukset ovat todennäköisesti suurin syy vibekoodata työkaluja. Se yksinkertaisesti helpottaa elämää niin paljon.
Lähetyskysynnän hallintapaneeli (Amazonin yrityslogistiikka)
Amazonin vanhempi toimitusketjupäällikkö Aniket Ghonge käytti viikoittain 16–18 tuntia uusien Amazonin kuljetusliikenneverkostoon liittyvien lähettäjien kysyntäsuunnitelmien manuaaliseen laatimiseen. Työhön kuului tietojen kerääminen useista lähteistä, satojen tilien laskelmien tekeminen ja viikoittaisten ennusteiden tuottaminen – mikään näistä ei onnistunut nykyisellä CRM-järjestelmällä.
”CRM-teknologialla, jonka kanssa työskentelin, ei ollut tarvitsemiani ominaisuuksia”, Ghonge selitti. ”Tarvitsin jotain, joka auttaisi automatisoimaan työni, antaisi minulle mahdollisuuden vertailla useita lähteitä ja tuottaisi sitten lopullisen kysyntäsuunnitelman uusille lähettäjillemme. Siksi rakensin tämän älykkään perehdytyksen hallintapaneelin. Se vähensi 18 tuntia työtä alle tuntiin tuhansien tilien osalta.”
Rakensin älykkään perehdytyksen hallintapaneelin. Se vähensi tuhansien tilien käsittelyyn kuluneen työaikani 18 tunnista alle tuntiin.
Ghongen rakentama kokonaisuus on täysimittainen verkkosovellus — otettu käyttöön Amazonin verkossa, Amazonin tietoturvatarkastuksen, käyttäjätason käyttöoikeuksien, auditointilokien ja S3-pohjaisen tietokerroksen kera — ja kaikki tämä agenttimaisten tekoälytyökalujen avulla. Hän ei ole ohjelmistoinsinööri. Hänen taustansa on kone- ja tuotantotekniikassa, ja hän on hankkinut jonkin verran SQL-kokemusta työn ohessa. Vuosien aikana teknisille tiimeille laadituista vaatimusmäärittelyistä kertynyt kokemus kuitenkin siirtyi suoraan siihen, miten hän lähestyi rakentamista tekoälyn avulla: selitä konsepti selkeästi, kuvaile mitä tarvitset ja anna järjestelmän rakentaa se.
Perinteiseen kehitykseen verrattuna saavutettu nopeusero oli hänestä huomattava. ”Pari vuotta sitten minun piti työskennellä verkkokehittäjän, UX-suunnittelijan, tuotepäällikön ja teknisen ohjelmapäällikön kanssa – tuotteen rakentamiseen tarvittiin paljon ihmisiä”, Ghonge sanoi. ”Nyt minulla ei ole esteitä. Pystyin rakentamaan sovelluksen kahdessa viikossa. Tukemani vastaavanlaisen sovelluksen rakentaminen kesti kaksi vuotta.”
Ainoa asia, jonka Ghonge oppi kantapään kautta, oli sama asia, joka nousi esiin lähes jokaisessa tätä artikkelia varten käydyssä keskustelussa: testaa ennen tuotantoon viemistä. Kehityksen puolivälissä uusi ominaisuus pyyhki pois puolet hänen sovelluksensa toiminnallisuudesta. ”Rakensin ja jatkoin rakentamista joka päivä”, hän sanoi. ”Mutta tuli hetki, jolloin menetin yhtäkkiä 50 % työstäni, ja se pelotti minua jonkin verran. Se oli vaikea oppituntini. Ominaisuus täytyy testata testiympäristössä ennen kuin tuotantoympäristöön tehdään muutos.”
Tuli hetki, jolloin menetin yhtäkkiä 50 % työstäni, ja se pelotti minua jonkin verran. Se oli vaikea oppituntini.
Menetetyn palauttamiseen kului neljä tuntia kehotteiden kirjoittamista, eikä hän ole sen jälkeen jättänyt testausvaihetta väliin. Kokeilu ja erehdys kuuluvat minkä tahansa uuden taidon oppimiseen — ja yhä useammalle projektipäällikölle vibe-koodaus on juuri sitä.
Mukautettu CRM- ja liidienhankintatyökalu
Gold Project Managementin perustaja ja osa-aikainen toimitusjohtaja Michael Gold päätyi vibe-koodaukseen yksinkertaisen kustannus-hyötylaskelman perusteella. Hän maksoi CRM-järjestelmästä, joka maksoi enemmän kuin siitä oli hänelle hyötyä, ja päätteli voivansa rakentaa itse jotain parempaa. ”Rakensin oman CRM-järjestelmäni Replitillä, koska käytin Closea ja se maksoi minulle 100 dollaria kuukaudessa.”
Hänen rakentamansa CRM-yhteys muodostaa yhteyden hänen verkkosivustoonsa ja sisältää liidien kvalifiointityökalun, josta hän on erityisen ylpeä: ”Loin terveystarkastuksen, joten kun ihmiset siirtyvät yhteydenottolomakkeelleni, he voivat vastata muutamaan kysymykseen ja saada raportin.” Se on käytännössä potentiaalisten asiakkaiden itsearviointi, jonka tulokset siirtyvät suoraan hänen myyntiputkeensa.
Tämä projekti johti paljon suurempaan projektiin, mutta siitä lisää myöhemmin.
Projektinhallinta-avustaja
RTS Labsin tekninen projektipäällikkö Ryan Gilbreath lähestyi asiaa eri tavalla — hän rakensi henkilökohtaisen työkalun, joka nopeuttaa hänen päivittäistä projektinhallintatyötään ja vähentää sen vaatimaa kognitiivista kuormitusta. Gilbreath kuvailee sitä näin: ”Olen luonut Google AI Studiolla projektinhallinta-avustajan, jossa on äänitila. Jos käyn päivän tapahtumia läpi ja minun tarvitsee vain tyhjentää ajatukseni, voin laittaa sen päälle. Voin sanoa: hei, näin tapahtui päivän aikana XYZ-projekteissa, ja pyytää sitä laatimaan minulle raportin.”
Olen luonut Google AI Studiolla projektinhallinta-avustajan, jossa on äänitila. Jos käyn päivän tapahtumia läpi ja minun tarvitsee vain tyhjentää ajatukseni, voin laittaa sen päälle.
Äänitila tekee työkalusta aidosti hyödyllisen — istuutuminen kirjoittamaan tilannepäivitystä ei enää aiheuta kitkaa, kun voit puhua päivästäsi ja saada sen perusteella luodun raportin. Myös Gilbreathin tiimi on ottanut käyttöön erillisen vibe-koodatun työkalun: ”Eräs kollegani loi vibe-koodaamalla henkilöstön tukipyyntöjen muodostimen, jota me kaikki käytämme tällä hetkellä.”
Kaupalliseen käyttöön valmis ohjelmisto: askel pidemmälle
Kunnianhimoisimmat vibecoding-tarinat eivät koske sisäisiä työkaluja – ne ovat tuotteita. Sekä Michael Gold että Harry Max, osa-aikainen johtaja ja Managing Priorities -kirjan kirjoittaja, ovat menneet paljon henkilökohtaisia tuottavuustyökaluja pidemmälle ja ryhtyneet rakentamaan maksaville asiakkaille tarkoitettuja ohjelmistoja.
Tekoälyä hyödyntävät asiantuntijapalvelut
Vietettyään paljon aikaa sisäisten työkalujen vibecodingin parissa Gold ryhtyi vibecoodaamaan prototyyppiä kokonaan uudelle asiantuntijapalvelujen automaatioalustalle, jonka hän ja hänen liikekumppaninsa aikovat tuoda markkinoille. "Rakensimme asiantuntijapalvelujen automaatiotyökalun, jonka haluamme haastaa markkinoilla olevat ratkaisut. Alkuperäinen prototyyppi rakennettiin Lovablella, ja jopa se oli varsin hyvä."
Rakensimme asiantuntijapalvelujen automaatiotyökalun, jonka haluamme haastaa markkinoilla olevat ratkaisut. Alkuperäinen prototyyppi rakennettiin Lovablella, ja jopa se oli varsin hyvä
Goldille tämä siirtyminen henkilökohtaisesta projektista kaupalliseksi tuotteeksi tarkoitti vibecodingin rajoitteiden kohtaamista. "Koska tämä on kuluttajille suunnattu sovellus, otimme mukaan teknisen asiantuntijan. Tunsin voivani viedä sen tietylle tasolle, mutta kun ihmiset maksavat siitä ja käyttävät sitä suuressa mittakaavassa, sen omistaminen ei-teknisenä henkilönä olisi aivan liian pelottavaa."
Kun otetaan huomioon, että Gold on myös työkalun suunniteltu loppukäyttäjä, hänen kykynsä muokata siitä täsmälleen visionsa mukainen ennen sen luovuttamista teknisemmän yhteistyökumppanin viimeisteltäväksi saattaa tehdä yhteistyöstä – ja lopulta myös tuotteesta – paljon vahvemman.
Tekoälyä hyödyntävä priorisointiohjelmisto
Harry Maxin tarina lähestyy kaupallista vibecodingia eri näkökulmasta – käyttämällä olemassa olevaa aineetonta omaisuutta perustana. Hänen liikekumppaninsa rakensi konsultointiyritykselleen yrityksille suunnatun SaaS-alustan käsittelemällä Maxin julkaisemaa priorisointia käsittelevää kirjaa tuotevaatimusdokumenttina.
"Hän otti kirjani Managing Priorities ja sanoi: ‘Voinko poimia tästä menetelmän ja käytännössä leipoa sen sisään alustaan?’ Sen sijaan, että asiakkaidemme pitäisi lukea kirja ja käydä kanssamme läpi työskentelyä fläppitaulun äärellä, voimme käyttää alustaa, jonka avulla voimme nyt tehdä paljon paremman ja laajemman työn pienemmällä vaivalla."
Hän [hänen liikekumppaninsa] otti kirjani Managing Priorities ja sanoi: ‘Voinko poimia tästä menetelmän ja leipoa sen sisään alustaan?
Max ei vähättele sitä, mitä yksi ei-insinööri rakensi yhdeksässä kuukaudessa, sillä hän on aiemmin käynyt läpi perinteisen ohjelmistokehitysprosessin. "Yhdeksässä kuukaudessa yksi henkilö rakensi jotain yhtä kehittynyttä kuin se, minkä rakensimme 20 vuotta sitten 14 henkilön ja 2 miljoonan dollarin voimin. Ja hän teki kaiken itse." Tämä osoittaa, kuinka suuri vaikutus vibecodingilla on – ja voi olla – lukuisiin toimialoihin ja työnkulkuihin.
Vibecoding ja parempien, räätälöityjen työnkulkujen lupaus
Vibecoding ei ainoastaan auta projektipäälliköitä rakentamaan työnkulkuja, jotka nopeuttavat työn etenemistä. Joissakin tapauksissa se auttaa heitä rakentamaan asioita, joita ei ole koskaan aiemmin ollut olemassa – työkaluja, jotka ovat liian tarkasti rajattuja, jotta mikään ohjelmistoyritys olisi viitsinyt kehittää niitä, ja toimialoille, jotka ovat liian erityisiä houkutellakseen oikean kehittäjän oikeaan aikaan. Niille projektipäälliköille, jotka työskentelevät näissä katvealueissa, raja sen välillä, että "toivoisin tämän olevan olemassa" ja että "rakensin tämän", ei ole koskaan ollut pienempi.
Koodi ei ole vaikein osa. Vaikeinta on tietää tarkalleen, mitä tarvitset – ja olla riittävän kurinalainen testaamaan ennen kuin rikot kaiken. Tätä jo tekeville projektipäälliköille ero on selvinnyt nopeasti. Niille, jotka ovat vasta aloittamassa, se saattaa olla tärkein asia, joka kannattaa tietää etukäteen.
Haluatko lisää tällaisia näkemyksiä? Rekisteröidy maksuttomalle DPM-tilille, niin kuulet lisää tällaisilta asiantuntijoilta.
