Artikkelin podcast-tulos
Aloitin oman vibekoodaus-tekoälyassistentin rakentamisen, koska olin kyllästynyt käymään läpi samoja liiketoiminnan konteksteja uudelleen ja uudelleen. Obsidianin, Pythonin ja tekoälyn kanssa aloittamani koekaniini muuttui The Bridger Lairdiksi, toimivaksi tietojärjestelmäksi, jossa debuggaamalla olen kerryttänyt yllättävän määrän opetusmateriaalia.
Minun ongelmani ei ollut tiedon puute.
Ongelmana oli se, että minun täytyi jatkuvasti selitellä ja vakuutella, että tietoa on.
Jokainen uusi tekoälykeskustelu alkoi jonkinlaisella versiolla: “Tässä on se, kuka olen, tässä on mitä C-Mimmi-O tekee, tässä on asiakaskonteksti, tässä on tuotekonteksti, tässä on se, miten minä ajattelen tätä, tässä on se, mitä ei pidä olettaa. Ei tehdä tästä nyt mitään korporaatiojargonia.”
Uudelleen. Ja uudelleen.
Jossain vaiheessa hokasin, ettei tässä tarvita jälleen uutta chat-ikkunaa. Se, mitä tarvitaan on toimiva järjestelmä, joka tuntee minut, auttaa minua käyttämään jo rakentamaani tietoa säilyttäen samalla auktoriteettini, valinnat ja kykyni sanoa “ei näin”.
Siitä järjestelmästä syntyi The Bridger Laird.
Siis, ei The Bridger, luomani identiteetti/hahmo, C-Mimmi-O:lle. The Bridger Laird on paikallinen Obsidian-pohjainen tietojärjestelmä, joka työskentelee ohjeistamallani tavalla taustalla.
Nyt ei siis puhuta “robotityöntekijästä, jolla on pieni solmio”, vaan enemmänkin “ luomastani apulaisesta, jolla on pääsy arkistooihini, tiukka ohjeistus eikä lupaa missään nimessä lähettää mitään ilman että kysyy ensin.”
Nämä ovat merkittävästi eri asioita.
En tarvinnut lisää tekoälyä. Tarvitsin apua vähentää toistoa.
Tekoäly osaa hyvin vakuuttaa sinut siitä, että se ymmärtää sinua yhden kappaleen lukemisen jälkeen. Mutta se ei oikeasti ymmärrä taustaasi, osaamistasi, sinun liiketoimintaasi, asiakkaitasi, rajojasi, aiempiasi päätöksiäsi ja eroa hyödyllisen ehdotuksen ja itsevarmasti itse keksimänsä höpönlöpön välillä.
Työskentelen markkinoinnin, liiketoiminnan kehittämisen, operatiivisen ajattelun, teknologian ja käytännön toteutuksen rajapinnassa. Usein työ lähtee liikkeelle turhauttavalla tosielämän prosessilla, eikä kiiltävällä ohjelmiston idealla. Mikä hidastaa ihmisiä? Mitä tietoa on hajallaan? Kuka päivittää sitä? Mitä tapahtuu, kun normaali prosessi katkeaa kiireisenä tiistai-iltapäivänä?
Näitä kysymyksiä ei kysytä huvin vuoksi. Ne määrittävät, onko rakennettu työkalu tai toiminto hyödyllinen vai vain yksi turhake, jota kukaan ei oikeasti käytä.
Ajan myötä, C-Mimmi-O on jo kerännyt merkityksellisen määrän materiaalia: artikkeleita, palveluinnovointia, liiketoimintakontekstia, asiakastöitä, tutkimusta, tuoteideoja ja päätöksentekopuitteita. Halusin varmistaa tiedon uudelleen hyödyntämisen ilman että se kaadetaan yleisen tietokannan kokoiseksi tai heitetään roskakoriin erillään oleviksi muistiinpanoiksi, joissa on merkintöjä kuten FINAL_final_v2_actually-final.md.
Tämä on meille kaikille tuttua. Kyllä siitä vieläkin kärsitään.
The Bridger Lairdin tavoite alkuun oli yksinkertainen: kun kysyn järjestelmältä, sen pitäisi pystyä tuottamaan asiaankuuluvaa kontekstia, säilyttämään tärkeitä eroja, tunnistamaan epävarmuustekijät ja auttamaan minua valmistautumaan työhön. Se ei saisi kuvitella, että jokainen tietue on yhtä tärkeä, jokainen rajapinta on varma tai jokaisen vastauksen kuuluu aloittaa uusi työ.
Se on vähemmän hehkeä tavoite kuin “autonomisen tekoälyagentin rakentaminen”.
Mutta. Se on myös se hyödyllisempi.
Miksi Obsidianista tuli homman peruskallio
Valitsin Obsidianin, koska halusin, että perusta olisi paikallinen, verkostoitunut ja ymmärrettävä.
En halunnut työkokemukseni katoavan mysteeriseen alustaan, josta en voisi nähdä lähdemateriaalia, tarkastella suhteita tai ymmärtää, miksi järjestelmä oli päätynyt johonkin päätelmään. Halusin muistiinpanoja, joita voisin avata, parantaa, haastaa ja jotka pysyisivät yhteydessä niihin työkohdeihin, joista ne tulivat.
Muistiinpanoja täynnä oleva kansio ei automaattisesti tarkoita tietojärjestelmää. Sama pätee myös laajaan kokoelman AI-keskusteluihin. Ero on suhteissa, rakenteessa, todisteissa ja säännöissä, jotka koskevat tietojen käyttöä.
The Bridger Lairdissa asiakas ei ole automaattisesti tuote. Tuote ei ole automaattisesti markkinointialue. Mirva/Mimmi ei ole C-Mimmi-O, eikä se ole sama asia kuin The Bridger merkki. Näiden kuulostaa kireiltä erotuksilta, kunnes järjestelmä erehtyy niihin.
Sitten ne muuttuvat hyvin kalliiksi erotuksiksi.
Yksi ensimmäisistä todellisista opetuksista tuli Wiurilan kanssa tehtävästä työstä. Järjestelmän oli erotettava:
- Wiurila, asiakasyksikkö
- Wiurilan Varaukset, nimetty varausmalli
- Wiurila Marketing, erillinen ja suppeampi markkinointityöalue
Aluksi hakutoiminnassa ei annettu riittävästi etusijaa nimetylle tuotteelle. Laajat asiakaskontekstit voisivat tulla liian aikaisin ja häiritä tuotekohtaisia tietoja, jotka olivat todella tärkeitä tehtävään.
Tämä ei ollut jännittävä vika Hollywoodin hakkeriskenessä. Kukaan ei tarvinnut kirjoittaa nopeammin, kun edistymispalkki vilkkoi punaista. Mutta se oli juuri sellainen ongelma, joka ratkaisee, onko tekoälyyn perustuva järjestelmä todella hyödyllinen vai pelkkiä innostuneita käyttäjiä.
Korjaus oli periaatteessa yksinkertainen ja käytännössä tärkeä: tuotemalliin perustuva työ alkaa nyt nimetyllä tuotteella ja sen toiminnallisen älykkyyden avulla. Sen jälkeen se laajenee laajempaan asiakaskokonaisuuteen ja vasta sitten nykyiseen ulkoiseen tutkimukseen, kun tämä tutkimus on erikseen tarkoituksenmukaista ja säänneltyä.
Hakuketju muuttui näin:
Wiurilan Varaukset → varaus- ja tuotetietojen hallinta → operatiiviset tiedot → Wiurilan asiakaskonteksti → nykyinen ulkopuolinen tutkimus
Seuraava askel heijastaa sitä tapaa, jolla työskentelen todellisessa elämässä. Jos keskustelemme jostain tietystä asiasta, aloita siitä. Älä tuoda mukaan kaikkia mahdollisia tietoja laajemmasta organisaatiosta ja keskity vain tärkeimpiin yksityiskohtiin.
Obsidian antaa minulle käytännön tavan pitää lähdeaineisto, strukturoituja tietoja, luotuja näkymiä, tutkimustuloksia ja työmuistiinpanoja yhdessä paikallisessa ympäristössä. Mutta todellinen arvo ei ole itse sovellus. Se on sen takana oleva kurinalaisuus.
Mistä tämä tieto on peräisin? Onko se ajantasaista? Onko se ihmisen hyväksymä päätös, luotu ehdotus, historiallinen tieto vai avoin kysymys? Voiko sitä käyttää asiakastyössä? Tarvitseeko se ihmisen tarkistusta?
Hyödyllisen tiedonhallintajärjestelmän täytyy sisältää vastauksia näihin kysymyksiin. Muuten se on vain hyvin järjestetty kellaritila.
Vibecodingin tekoäly-assistentin rakentaminen Obsidianin avulla
The Bridger Laird ei ole mikään maaginen ohjelmisto. Se on käytännön toimintamalli paikallisen tietämyksen tallennuskeskuksen, jäsennellyn tiedon, Python-pohjaisen automaation, hallittavan hakemisen, tekoälyä hyödyntävän päättelyn ja ihmisen tarkastelun välillä.
Obsidian on kotipaikka. Siinä säilytetään muistiinpanoja, tietoja, lähdeaineistoa, työn tuloksia sekä historiaa, joka antaa pyynnölle merkityksen.
Pythonin automaatio auttaa valmistelemaan ja siirtämään työt määriteltyjen vaiheiden mukaisesti. Se voi tukea strukturoitua pyyntöjen käsittelyä, kontekstien lataamista ja toistuvia tarkistuksia ilman, että minun tarvitsee rekonstruoida sama asetus manuaalisesti joka kerta.
Hallinnollinen hakeminen on osa prosessia, jossa löydetään arkistosta relevantti aineisto. Tässä on tärkeää sana “hallinnollinen”. Se ei tarkoita sitä, että kaikkia muistiinpanoja otettaisiin esiin, jotka ovat jonkin verran samankaltaisia kysymyksen kanssa. Se tarkoittaa määriteltyä kontekstia, luokittelua, rajojen määrittämistä, alkuperää sekä tunnettuja rajoituksia.
Sitten tekoälyn analysointi auttaa tulkimaan pyyntöä ja valmistelemaan perusteltu päätös: luonnoksen, suosituksen, tutkimusvastauksen, työsuunnitelman tai hyödyllisen seuraavan vaiheen.
Lopuksi tarkastan sen uudelleen.
Perusjärjestys näyttää tältä:
- Kysyn kysymystä tai kuvaan tehtävän luonnollisella kielellä.
- Järjestelmä tunnistaa relevantin työympäristön.
- Se hakee ja kokoaa rajatut tiedot säilytystilasta.
- Se tulkitsee tehtävän ja valmistelee tulosta tai suositusta.
- Minä tarkistan sen.
- Mikään ei julkaista, lähetetä, toteuteta tai kirjata takaisin kanoniseen tietoon automaattisesti.
Se viimeinen osa ei ole ärsyttävä tekninen rajoite. Siinä on asiaan pohja.
The Bridger Laird voi tukea päivittäisiä työnkulkuja, kuten Kysy The Bridger, Se luo uutta työtä, asiakastöitä, tuotetöitä ja selvittää tietämisvajeita. Se voi auttaa kokoamaan yhteen kontekstia ja ehdottamaan perusteltua ratkaisua. Se voi säilyttää alkuperän ja tuoda esiin epävarmuuden sen sijaan, että hiljaisesti teeskentelisimme, ettei epävarmuutta ole olemassa.
On myös luonnollisen kielen pyyntivirta. Voin kuvata mitä tarvitsen tavallisin kielen sävyllä, ja järjestelmä voi laatia hallitun pyynnön asianomaisella kontekstilla ennen työn luomista.
Toisin sanoen, minun ei tarvitse rakentaa monimutkaista kyselyä aina, kun haluan kysyä yrityksestä jotain.
Mutta en myöskään saa heiluttaa käsiäni ja luoda vahingossa itsenäisen toimintamallin perustavan perustan. Tämä on pieni armo kaikille osallisille.
Minun asiantuntemukseni on edelleen tärkeää, ehkä harmittavasti robotteille.
The Bridger Laird ei korvaa minun asiantuntemustani. Se tekee siitä saatavilla enemmän sitä aikaa, jolloin sitä tarvitsen.
Se on eri juttu.
Järjestelmä voi hakea tietoa markkinointistrategiasta, asiakaskäyttäytymisestä, sisällön suorituskyvystä, tuotteen sijainnista tai toteutustekijöistä. Se ei voi itsenäisesti tietää, onko suositus tarkkaan tiettyyn liiketoimintaympäristöön sopiva, ellei ole olemassa asiaankuuluvaa kontekstia ja joku voi sen arvioida.
Taustani vaikuttaa kysymyksiin, joita kysyn.
Markkinoinnin ja tuotekehityksen kokemus auttaa yhdistämään tekniset kyvykkyydet asiakkaan ongelmiin, markkinoinnin ja käyttöönoton tilanteeseen sekä kaupalliseen todellisuuteen. Toiminnallinen kokemus auttaa etsimään päivityksen omistajaa, totuuden lähdettä, poikkeustilanteen ratkaisua ja sitä todellista henkilöä, joka joutuu käyttämään sitä, kun hän on jo kiireinen.
Vuosien kokemus palvelualueista, vähittäiskaupasta, tuotannon suunnittelusta ja käytännön liiketoiminnasta on herättänyt minussa epäilyksiä ratkaisuista, jotka näyttävät erinomaisilta dioesityksessä mutta romahtavat, kun joutuu päivittämään niitä ennen aukioloaikaa.
Siksi palautan jatkuvasti tylsään mutta voimakkaaseen kysymykseen: mitä ihmiset todella yrittävät tehdä?
Ei: mikä ohjelmisto näyttäisi vaikuttavalta?
Ei: mitä voisimme automatisoida, koska teknisesti voimme?
Mitä työtä on tehtävä, mitä tietoja tarvitaan, kenen omistuksessa se on ja mikä on tärkeä lopputulos?
Teollinen tekoäly voi auttaa nopeuttamaan analysointia, strukturoimaan tietoa ja tuottamaan alustavia luonnoksia. Se voi auttaa luomaan pieniä ja kohdennettuja työkaluja vibecodingin avulla. Se voi jopa auttaa paljastamaan piirteitä, joita muuten ehkä missaisinkin.
Se ei voi ottaa vastuuta siitä, palveleeko asiakassuhde, liiketoimintapäätös tai toimintaprosessi todella asiakasta parhaalla mahdollisella tavalla.
Se on silti ihmisen työtä.
Mitä rakennusta se todella koski
Kätköversio on vähemmän “Minulla oli idea ja rakennettiin tekoäly-apuri” ja enemmän “Olin koko ajan löytämässä jotain muuta, jolle tarvittiin sääntö”.”
On tehty vibecodingia, Python-automaatiota, Obsidian-integraatiota, strukturoidun hallintatyön toteutusta, testauksia, auditointia, tallennusajastusten säätöä ja paljon debuggausta. Osan työstä on luovaa. Osan on systeemin suunnittelu. Osan on lukenut epäonnistuneen testituloksen ja mietitty, onko ohjelmisto viallinen, testi viallinen vai onko minä yksinkertaisesti unohtanut, mikä päivä on.
Yksi todellinen esimerkki tuli hakujen parantamisesta.
Järjestelmän oli tunnistettava merkitykselliset käsitteet myös silloin, kun kysymyksen sanamuoto ei täysin vastannut olemassa olevaa toimialaluokitusta. Tämä kuulostaa itsestään selvältä, kunnes yrittää rakentaa sen itse. Henkilö voi ymmärtää, että “selvitettävä, mitä tietoja joku tarvitsee ennen avaamista”, voi liittyä toimintoihin, totuuden lähde-omaisuuteen, etulinjan käytettävyyteen ja asiakaskokemukseen ilman, että käytetään niitä tarkkoja nimityksiä.
Järjestelmän tarvitsee enemmän apua.
Laajennetun hakemisen ansiosta semanttinen vastaavuus parani. Oppitunti oli selvä: semanttinen käsite ei välttämättä ole täsmällinen graafikennon nimitys.
Sitten luonnollisesti yhden ongelman ratkaiseminen loi uuden.
Joillakin tiiviillä osaamisalueilla syntyi satoja tai jopa tuhansia sopivia hakijoita. Viiden laajennetun kyselyn tulosrajat saavuttivat asetettuja rajoja. Silloin enemmän hakutoimintoa ei automaattisesti tarkoittanut parempaa hakutoimintaa. Se tarkoitti vain sitä, että enemmän materiaalia kilpaili sisällyttämisestä.
Ensimmäinen intutioni, kuten monien muidenkin ihmistenkin ensimmäinen intution AI:ta kohtaan, oli luultavasti jokin muunnelma seuraavasta: “Totta kai lisää kontekstia on turvallisempaa?”
Ei välttämättä.
Liian paljon löyhästi valittu konteksti voi tehdä järjestelmästä vähemmän keskittynyttä eikä enää informatiivisempaa. Se voi piilottaa vahvimmat todisteet vain yhteen liittyvän materiaalin vuoreen. Joten vastaus ei ollut antaa järjestelmän syödä koko kokoelmaa ja toivoa, että se saavuttaa viisautta.
Vastaus oli rajatun kontekstin kokoonpano: edistää edustavaa auktoriteettia ja monimuotoisuutta raakaa hakumäärää enemmän.
Se oli hyvin Bridger Lairdin oppitunti. “Lisää” ei ole laatuvaatimus.
Toinen hyvin todellinen opetus tuli pyyntöasennotarjontanäytön testaamisesta, joka on osa sitä, mikä auttaa muuttamaan tavallisen kielen kyselyn sääntöjen mukaiseksi työnkulkukyselyksi oikean suoritusympäristön kera.
Hyväksymistesti epäonnistui aluksi suoritustilanteen uudelleenkäsittelyn yhteydessä. Se kuulosti huolestuttavalta. Eikö käynnistin onnistunut uudelleenlukemaan tärkeää kontekstia suorituksen aikana? Eikö koko prosessi ollut luotettava?
Ei. Perusratkaisu ei ollut ongelma. Testin havainto itse oli heikkonen.
Korjausratkaisuna hyväksymistesti korjattiin AST-pohjaisella lähestymistavalla, joka on luotettavampi tapa tarkastaa relevantti koodirakenne kuin turvautuminen hauraisiin tekstin tunnistamiseen. Kun korjaus oli tehty, hyväksymistesti läpäisi.
Tämä ei ole sellainen yksityiskohta, joka saa aikaan onnistunutta voimakkaampaa sävelkappaletta tuotteen esittelyssä. Kukaan ei nappaa, koska vääriä negatiivisia tuloksia todettiin haurasta testausmenetelmää johtuen.
Mutta minua se kiinnostaa, koska se on todellista.
Jos testi on virheellinen, passi tai epäonnistuminen -merkki ei yksin kerro totuutta. Sinun on silti tutkittava asiaa. Sinun on yhä ymmärrettävä, mitä todella tarkastellaan. AI:n avulla rakentaminen ei poista tätä vastuuta. Vaan päinvastoin tekee tapoista arvokkaampia, koska uskottava selitys voi syntyä hyvin nopeasti.
Järjestelmä kehitettiin myös vaiheittaisin auditointien ja ihmisten arviointien avulla, jotka kattoivat tunnistautumisen, hakemisen, synteesin, työnkulun valmiuden ja aidot työnteko-tehtävät. Käytännön MVP:tä hyväksyttiin vasta sen jälkeen, kun todelliset työnkulut oli testattu ihmisten päätöksillä.
En halunnut taikaa sisältävää mustaa laatikkoa.
Halusin jotain, jota voisin tarkastaa, kyseenalaistaa ja parantaa.
Mitä opin ja mihin tämä vie seuraavaksi
Suurin oppimamme asia on se, että tekoälyyn perustuvan työjärjestelmän rakentaminen ei ole lähinnä tekoälyyn liittyvä ongelma.
Se on tietotapausten ongelma, prosessien ongelma, luokittelun ongelma, omistusongelma ja arviointiongelma.
Sinun on päätettävä, mikä kuuluu järjestelmään, mikä katsotaan todisteeksi, mikä jää epävarmaan, mitkä erot on suojattava ja mitä järjestelmän ei koskaan saa tehdä yksin.
Sinun on myös hyväksyttävä, että hyödyllinen edistys näyttää usein ulkopuoliselta pieneltä. Siistimpi hakujärjestelmä. Korjattu luokittelu. Epäonnistunut testi, joka osoittautuu huonoksi. Kontekstirajoite, joka estää hyödyllisen signaalin piiloutumasta valtavan määrän epätarkkoja muistiinpanoja peittämään sen.
Se ei ole automaation epäonnistuminen. Se on vastuullista automaatiota.
The Bridger Laird on toimiva ja hyödyllinen työkalu, mutta se ei ole vielä valmis. Sen rajoitukset ovat edelleen olemassa. Joillakin osa-alueilla on kuitenkin tarpeen kiinnittää huomiota kontekstiin. Laajemman kontekstin monimuotoisuus on edelleen parantamisen tarpeessa käytännön käytön kautta. Joillakin toimintojen osilla on tarkoituksellisesti rajoituksia, koska selkeät rajat ovat tärkeämpiä kuin teeskentely autonomisuudesta.
Sitten parannan sitä käytännön työn kautta: parempi hakutoiminto, tarkempi kontekstien yhdistäminen, paremmat työnkulut ja enemmän tietoa siitä, mikä todella säästää aikaa tai parantaa päätöksentekoa.
Kyse ei ole siitä, että tekoäly korvaisi minun tapaani tehdä töitä. Haluan vain viettää vähemmän aikaa rekonstruoimalla sitä, mitä jo tiedän, ja enemmän aikaa hyödyntää sitä hyvin.
Ja sitä varten on olemassa kumppanini.
Lähteet ja linkit
Sisäisten linkkien osalta viitataan luonnollisesti olemassa olevaan C-Mimmi-O -sisältöön:
- C-Mimmi-O Insights mukaan lukien muut vibecoding- ja AI-kehitystä koskevat artikkelit.
- Bridger tietoa hahmosta ja laajemmasta konseptista.
- C-Mimmi-O-portfolio esimerkkejä käytännön ohjelmistotyöstäsi ja markkinointityöstäsi.
Jos haluat oppia Obsidian-työkalusta, suosittelen lukemaan seuraavat kaksi tekstiä: Obsidian tietämyskansion säätiön puolesta ja Python automaatioteknologian osalta nämä ovat sopivia kontekstuaalisia linkkejä, eivätkä todisteita henkilökohtaisesta kehityshistoriastanne.
Vastaa