Vibekoodauksen kasvu: Vibekoodaus on kehittynyt marginaalisesta ilmiöstä konseptiksi, joka herättää yhä enemmän huomiota teknologia- ja yritysmaailmassa.
Projektipäälliköt: Selkeän viestinnän taitavat projektipäälliköt soveltuvat yllättävän hyvin menestymään vibekoodauksessa.
Käytännön esimerkit: Vibekoodauksen käytännön sovellukset osoittavat sen potentiaalin rakentaa työkaluja erityisiin käyttötarkoituksiin.
Haasteet: Vaikka vibekoodaus nopeuttaa kehityksen alkuvaihetta, skaalautuvuus ja laadunhallinta ovat edelleen haastavia osa-alueita.
Riskitietoisuus: Muille kuin teknisille rakentajille voi vibekoodauksessa aiheutua riskejä, kuten skaalautuvuusongelmia ja tietoturva-aukkoja.
Viimeisen vuoden tai kahden aikana ”vibekoodaus” on siirtynyt internetin tekoälyharrastajien piireissä kiertäneestä marginaalisesta termistä kohti valtavirtaa – ainakin teknologia-, liike-elämä- ja tuottavuuspiireissä. Olen keskustellut lukemattomia tunteja tekoälystä asiantuntijoiden kanssa ja uppoutunut itse vibekoodaukseen, ja olen huomannut tietyn kaavan: vibekoodaus on usein seuraava askel ihmisille, jotka ovat törmänneet olemassa olevien tekoälytyökalujen tarjoamien mahdollisuuksien rajoihin. Jos et löydä sitä, mitä etsit, mikset rakentaisi sitä itse?
Ongelma on siinä, että useimmat tapaamani ihmiset eivät ole vieläkään kuulleet siitä. Kyseessä on edelleen aidosti marginaalinen ilmiö, josta keskustellaan harvoin erityisesti projektinhallinnan piireissä. Niinpä lähdin etsimään ihmisiä, jotka todella tekevät sitä: oikeita projektipäälliköitä ja operatiivisen toiminnan johtajia, jotka ovat kaikessa hiljaisuudessa rakentaneet vibekoodattuja työkaluja osaksi päivittäisiä työnkulkujaan, ja kysyin heiltä, miten se on sujunut.
Olitpa projektipäällikkö, jota kiinnostaa, mihin tekoäly voi sinut seuraavaksi viedä, tai johtaja, joka yrittää pysyä edellä siinä, mitä tiimisi saattaa jo kokeilla, pidä tätä johdantona vibekoodaukseen – osittain inspiraationa, osittain varoituksena.
Mitä vibekoodaus oikeastaan on?
Vaikka ”vibekoodaukselle” ei vielä ole virallista määritelmää, koska kyseessä on uusi termi, määrittelemme sen näin: koodaamista antamalla LLM:lle luonnollisella kielellä kehotteita, joiden perusteella se tuottaa koodia.
Tässä artikkelissa haluan myös täsmentää, että ”vibekoodaus” (ainakin siinä merkityksessä, jossa itse käytän termiä) eroaa tekoälyavusteisesta koodauksesta – tilanteesta, jossa teknisesti taitava kehittäjä käyttää GitHub Copilotin kaltaisia työkaluja nopeuttaakseen työtä, jonka hän jo osaa tehdä.
Miksi projektipäälliköt sopivat tähän yllättävän hyvin?
Ensi silmäyksellä vibekoodaus saattaa vaikuttaa yrittäjille tai teknologiaa sivuaville harrastajille tarkoitetulta työkalulta. Mutta mitä useampien ihmisten kanssa keskustelin, sitä selvemmäksi kävi, että esiin nousi toisenlainen profiili: vibekoodauksessa ei välttämättä menesty parhaiten huoneen teknisin henkilö. Menestyjä on henkilö, joka tietää parhaiten, mitä haluaa, ja osaa ilmaista sen selkeästi – mikä, jos asiaa ajattelee, kuvaa hyvää projektipäällikköä lähes täydellisesti.
Tim Fisher, The Digital Project Managerin tekoälyjohtaja, ilmaisi asian näin: ”Se on uusi tapa kommunikoida.” Hän näkee vibekoodauksen vähemmän teknisenä taitona ja enemmän uutena välineenä ideoiden muuttamiseksi joksikin konkreettiseksi. ”Näiden työkalujen arvo koodaamattomille on siinä, että niiden avulla voi oikaista esimerkiksi idean ympärille tarvittavan yhteisymmärryksen saavuttamisessa ja päästä yli ’toimiiko tämä?’ -vaiheesta.”
Vibekoodaus on uusi tapa kommunikoida.
Timin kuvaus sopii saumattomasti projektipäällikön taitoprofiiliin: vaatimusten kirjoittaminen, liiketoiminnan tarpeiden muuttaminen selkeiksi määrittelyiksi sekä viestiminen teknisten ja ei-teknisten tiimien välillä – projektipäälliköt tekevät näitä kaikkia päivittäin, ja juuri näitä taitoja vibekoodaus palkitsee.
Aniket Ghonge, Amazonin toimitusketjun vanhempi johtaja, kuvaili omaa polkuaan vibekoodaukseen tavalla, joka puhuttelee monia projektipäälliköitä. Vuosia ennen agenttisen tekoälyn olemassaoloa hän auttoi ohjaamaan kehitystiimiä sisäisen työkalun rakentamisessa kirjoittamalla vaatimuksia ja kuvailemalla, mitä hän tarvitsi. ”En rakentanut mitään. En koodannut mitään. Sanoin vain: ’Tässä on se, mitä tarvitsemme. Näin sen pitäisi toimia.’ Ja he rakensivat sen vaatimusteni perusteella. Mutta siitä matkani alkoi. Nyt agenttisen tekoälyn avulla teen samaa asiaa. Kirjoitan vaatimukseni, mutta tekoäly hoitaa koodaamisen.”
Ainoa ero nyt? Hän ei tarvitse enää kehitystiimiä.
Mitä ihmiset oikeasti rakentavat?
Vakuuttavin todiste vibekoodauksen mahdollisuuksista ei ole teoreettinen – se ovat konkreettiset ja käytännölliset asiat, joita ihmiset ovat kaikessa hiljaisuudessa julkaisseet samalla, kun me muut vielä väittelimme siitä, kannattaako sitä kokeilla.
Tässä katsaus siihen, mitä neljä teknisen alan ulkopuolella työskentelevää ammattilaista on rakentanut:
Dixie Willard, Poised and Plumbin perustaja ja johtava projektistrategi, työskentelee pääasiassa sisustussuunnittelijoiden kanssa ja rakensi täysin itse työn laajuuden määrittelytyökalun. Sovelluksen avulla suunnittelija voi käydä asiakaskonsultaation läpi tabletilla, merkitä huoneet, valinnat ja projektivaiheet tehdyiksi reaaliajassa sekä luoda siistin työn laajuutta kuvaavan asiakirjan saman tien — aiemmin tähän tarvittiin muistiinpanoja, muistia ja tuntikausien hallinnollista työtä tapaamisen jälkeen. Hän rakensi sen, koska mitään vastaavaa ei ollut olemassa. ”Sellaista ei yksinkertaisesti ole. Ja on paljon työkaluja, joita suunnittelijat voisivat käyttää, mutta joita ei vain ole olemassa.” Hänen näkemyksensä siitä, miksi vibekoodaus on tärkeää hänen kaltaisillaan aloilla: ”Luulen, että erityiset käyttötapaukset ovat luultavasti suurin syy käyttää vibekoodausta. Se tekee elämästä vain niin paljon helpompaa.”
Luulen, että erityiset käyttötapaukset ovat luultavasti suurin syy käyttää vibekoodausta. Se tekee elämästä vain niin paljon helpompaa.
Aniket Ghonge käytti 16–18 tuntia joka viikko satojen Amazonin logistiikkaverkoston rahdinkuljettajien kysynnän ennustamiseen liittyvien tietojen manuaaliseen käsittelyyn — lukujen kopioimiseen taulukkolaskentaohjelmasta toiseen, laskelmien tekemiseen käsin ja kaiken saman toistamiseen seuraavalla viikolla. ”Se on manuaalinen prosessi. Siihen kului noin 16–18 tuntia joka viikko. En voi jatkaa sen tekemistä käsin ja virheiden tekemistä, koska aina kun ihminen käsittelee jotain suuressa mittakaavassa, siihen liittyy virheriski.” Niinpä hän rakensi vibekoodaamalla kokonaisen verkkosovelluksen, joka automatisoi nyt suurimman osan tästä työstä. Vertailu aiempaan on huomattava: ”Muutama vuosi sitten minun piti työskennellä verkkokehittäjän, UX-suunnittelijan, tuotepäällikön, teknisen ohjelmapäällikön ja monien muiden ihmisten kanssa rakentaakseni tuotteen, johon konseptini perustui. Nykyään minulla ei ole mitään esteitä, ja rakensin sovelluksen kahdessa viikossa. Vastaavan sovelluksen, jota aiemmin olin mukana tukemassa, rakentamiseen kului kaksi vuotta.”
Michael Gold, Gold Project Managementin osa-aikainen toimitusjohtaja ja perustaja, rakensi Lovablella mukautetun CRM-järjestelmän, joka on yhteydessä hänen yrityksensä verkkosivustoon ja integroituu hänen kokousten litterointityökaluunsa Firefliesiin. Joka aamu hän ja hänen liikekumppaninsa käyvät myyntiputkensa läpi puhelussa, ja kun he ovat valmiita, yksi painikkeen painallus hoitaa loput: ”Voin vain napsauttaa litteroinnista päivittämistä, ja se käy litteroinnin automaattisesti läpi ja määrittää sen oikealle henkilölle. Lisäksi se lisää meille muistiinpanot ja tehtävät ja määrittää ne meille.” Sittemmin hän on vienyt vibekoodausta pidemmälle ja tehnyt yhteistyötä kehittäjän kanssa rakentaakseen kokonaisen asiantuntijapalveluiden automaatiotyökalun, joka on nyt etenemässä kohti julkista julkaisua.
Harry Max, osa-aikainen johtaja ja Prioriteettien hallinta -kirjan kirjoittaja, seurasi liikekumppaninsa vibekoodaavan monipuolisen priorisointialustan tyhjästä yhdeksän kuukauden aikana Claude Codea käyttäen — ilman kehitystiimiä tai ulkopuolista rahoitusta. Harryn esittämä vertailu ennen ja jälkeen oli vaikea ohittaa: ”Yksi henkilö rakensi yhdeksässä kuukaudessa jotain yhtä kehittynyttä kuin mitä rakensimme 20 vuotta sitten 14 henkilön ja 2 miljoonan dollarin voimin.”
Yksi henkilö rakensi yhdeksässä kuukaudessa jotain yhtä kehittynyttä kuin mitä rakensimme 20 vuotta sitten 14 henkilön ja 2 miljoonan dollarin voimin.
Rehellinen totuus: kaikki ei suju ongelmitta
Jokainen haastattelemani henkilö suhtautui vibekoodaukseen aidosti innostuneesti. He olivat kuitenkin poikkeuksetta rehellisiä myös siitä, missä kohtaa se vaikeutuu.
Yleisin kokemus näyttää olevan muunnelma siitä, mitä Michael kuvaili: ”Nollasta kuuteenkymmeneen pääsee nopeammin kuin koskaan, mutta mielestäni kuudestakymmenestä sataan on edelleen todella haastavaa. Jos todella haluat viedä sen valmiiksi, tarvitset edelleen asiantuntemusta.”
Harry Max nosti esiin hienovaraisemman ansan — itse prosessin houkuttelevuuden. ”On hyvin viettelevää jatkaa asioiden muuttamista, ja joka kerta kun muutat jotain, jokin rikkoutuu. Etkä löydä rikkoutunutta kohtaa, ellet ole todella miettinyt, miten aiot hallita laadunvarmistus- ja testausprosessejasi.” Hän esitti myös pysäyttävän huomion tuotoksista, jotka näyttävät paremmilta kuin ovatkaan: ”Se, että voit vibekoodata jotain, joka näyttää kauniilta, ei tarkoita, että se olisi hyödyllistä. Se ei tarkoita, että se toimii. Se ei tarkoita, että se ratkaisee ongelman, mutta se näyttää hienolta.”
[Vibekoodauksella] pääset nollasta 60:een nopeammin kuin koskaan, mutta mielestäni 60:stä 100:aan pääseminen on edelleen todella haastavaa.
Aniket Ghonge oppi yhden vaikeimmista läksyistä kantapään kautta. Innokkaana jatkamaan ominaisuuksien rakentamista hän ohitti testausvaiheen, mikä tuli hänelle kalliiksi: "Menetin yhtäkkiä 50 % työstäni, ja se pelästytti minut. Se oli kova oppitunti. Selvä, ominaisuus täytyy testata testiympäristössä ennen kuin tuotantoympäristöön tehdään muutos." Hän toipui tilanteesta, mutta siihen kului tunteja – ja huomattava määrä ahdistusta.
Riskit, joita ei-tekniset rakentajat eivät aina osaa ennakoida
Käytännön tekijöiden innostus on todellista, mutta niin ovat myös rakenteelliset riskit – ja juuri tässä kohtaa päätin pyytää Timiltä rehellisen teknisen näkemyksen.
Kun kysyin Timiltä, mitä hän ajatteli siitä, että projektipäälliköt koodaavat omia työkalujaan vibekoodauksen avulla, hänen näkökulmansa ei ollut niinkään ihmisten lannistaminen vaan sen varmistaminen, että he lähtevät mukaan silmät avoinna. Hänen tärkein huomionsa oli: "Yleisesti ottaen, jos et tiedä, mitä et tiedä, et voi olettaa, että tekoälyavusteinen koodaaja kertoo sen sinulle."
Tämä koskee erityisesti skaalautuvuutta. "Yleisesti ottaen kaikki vibekoodatut projektit eivät ole skaalautuvia, lähinnä siksi, ettet pyydä tekoälyavustajaa ottamaan skaalautuvuutta huomioon. Ei-kehittäjät eivät luultavasti edes pyydä sellaisia asioita kuin virheenkäsittelyä." Vibekoodattu työkalu saattaa toimia täydellisesti viidellä käyttäjällä ja hajota hiljaa viidenkymmenen käyttäjän kohdalla – eikä sen rakentaneella henkilöllä välttämättä ole mitään keinoa tietää, miksi näin tapahtuu.
Yleisesti ottaen kaikki vibekoodatut projektit eivät ole skaalautuvia, lähinnä siksi, ettet pyydä tekoälyavustajaa ottamaan skaalautuvuutta huomioon.
Sitten on vielä vastuukysymys, joka korostuu erityisesti silloin, kun työkalu saavuttaa suosion organisaation sisällä. "Jos rakennat jotain, johon ihmiset luottavat, siitä täytyy tulla enemmän kuin pelkkä vibekoodattu projekti; ammattilaisten, jotka tekevät tätä työkseen ja tietävät asioita, joita et edes osaa kysyä, täytyy ottaa se hoitaakseen." Fisher kuvaili tiettyä tilannetta, joka tuntui hyvin todelliselta: "Jos joku kysyy tältä henkilöltä: 'Ovatko tästä työkalustasi saamani tiedot tarkkoja?' eikä hän tiedä riittävästi siitä, miten työkalu toimii, koska hän antoi tekoälyavustajan tehdä kaiken työn, hän ei pysty vastaamaan kysymykseen."
Jopa Dixie Willard, joka rakentaa aktiivisesti uskomiaan työkaluja, myönsi innostuksen alla piilevän levottomuuden: "Juuri tuo saa minut aina hermostumaan, koska mietin, että entä jos kyseessä on tietoturvaongelma?"
On syytä huomata, että tietoturva-aukot – paljastuneet API-avaimet, suojaamattomat käyttäjätiedot ja työkalut, jotka käsittelevät tahattomasti henkilötietoja ilman asianmukaisia suojatoimia – kuuluvat yleisimpiin sudenkuoppiin, jotka Tim nosti keskustelussamme esiin. Kehittäjä käsittelee tällaisia asioita rutiininomaisesti, mutta vibekoodaaja ei välttämättä edes tiedä, että niihin pitäisi puuttua.
Pitäisikö sinun siis kokeilla sitä?
Rehellinen vastaus on: se riippuu siitä, mitä olet rakentamassa ja mitä aiot tehdä sillä.
Vibekoodaus on aidosti tehokas prototyyppien rakentamiseen ja viestintävälineenä. Jos sinulla on idea, haluat testata, toimiiko se, tai sinun täytyy näyttää sidosryhmille jotain konkreettista ennen kuin investoit varsinaiseen kehitystyöhön, mahdollisuudet ovat suuret ja riskit hallittavissa. Tim ilmaisee asian hyvin: keskeinen hyöty on siinä, että pääset "toimiiko tämä?" -vaiheen ohi nopeammin kuin koskaan aiemmin olisi ollut mahdollista.
Tilanne muuttuu monimutkaisemmaksi, kun vibekoodattu työkalu siirtyy prototyypistä sellaiseksi, jonka varaan ihmiset alkavat rakentaa toimintaansa. Silloin alussa helposti sivuutetut skaalautuvuuden, virheenkäsittelyn ja tietoturvan puutteet alkavat merkitä jotain – eikä työkalun rakentaneella henkilöllä välttämättä ole teknistä sanastoa, jonka avulla hän edes tietäisi, mistä etsiä.
Tämän artikkelin käytännön tekijät käsittelevät tätä jännitettä parhaillaan. Jotkut luovuttavat työn kehittäjille. Jotkut oppivat matkan varrella. Kaikki heistä selvittävät yksi kehotus kerrallaan, missä tämän teknologian rajat kulkevat.
Projektipäälliköille mahdollisuus on todellinen – mutta niin on myös siihen liittyvä vastuu. Hyvä uutinen on se, että omien tarpeiden tunteminen, oikeiden kysymysten esittäminen ja sen ymmärtäminen, milloin apua tarvitaan, ovat kaikki asioita, joita hyvät PM:t tekevät jo valmiiksi. Parhaimmillaan vibekoodaus on vain uusi asiayhteys samoille taidoille.
Haluatko lisää tällaisia näkemyksiä? Luo maksuton DPM-tili kuullaksesi lisää näiden kaltaisilta asiantuntijoilta.
