Kihagyás

Egyjátékos AI-ból többjátékos AI-ba. Miért akad meg az AI-bevezetés a licencek kiosztása után

Epizód: Using AI at Work #123 Dátum: 2026-09-28 Házigazda: Chris Daigle Vendég: Justin Watt, a Switchboard társalapítója és vezérigazgatója (belső AI-eszközök, szoftverek és automatizált munkafolyamatok vállalatoknak) Hossz: 51:05 (3065 sec) Platform: Buzzsprout (2278116) Epizód link: https://www.buzzsprout.com/2278116/episodes/19858377 Honlap: https://www.usingaiatwork.com Media: https://p.podderapp.com/2370592068/www.buzzsprout.com/2278116/episodes/19858377-how-ai-workflow-automation-changes-the-way-your-business-works-with-justin-watt.mp3 Transcript: natív Buzzsprout transcript (podcast:transcript VTT, 10 548 szó)

Bevezetés és a lényeg

Az epizód egyetlen kérdés köré épül, amit szinte minden cég feltesz magának: ha már megvettük a ChatGPT- vagy Claude-licenceket, miért nem változott meg tőle a vállalat működése? Justin Watt válasza nem a technológiában keresendő. A chatbotot mindenki egyjátékos élményként ismerte meg, és az is maradt, hiába lettek jobbak a modellek és hiába lehet integrálni őket. A cég viszont nem egyjátékos: a folyamatok emberek között mennek át, és ha a kérdést egy chatbot ablakában tesszük fel, az csak a saját adatainkat látja.

A beszélgetés második fele arról szól, ami ebből következik. Ha meg akarjuk érteni, hol segíthet az AI, előbb meg kell érteni, hogyan dolgozik a csapat, és ez szinte soha nem vezetői szinten derül ki. Justin visszatérő tapasztalata szerint a legtöbb vezetőnek fogalma sincs arról, mit csinál a csapata egész nap, és ez nem a vezető hibája: egy bizonyos méret felett egyszerűen nem tudhatja. Ezért a helyes első lépés nem az AI kiválasztása, hanem a folyamat és az emberek megkérdezése.

A gyakorlati tanulságok:

  1. Kezdd a folyamatnál, ne az AI-nál. Az esetek jelentős részében a folyamat húsz éve nem változott, és az AI nélkül is van benne egy hét és fél munkányi pazarlás.
  2. Az AI legyen láthatatlan a munkában. Ne minden lépésbe kerüljön bele, hanem néhányba, ahol ténylegesen segít.
  3. Az egyéni hatás, nem a hivatalos ROI. A vezetőség azt tudja mérni, hogy nőtt a bevétel, és nem kellett négy embert felvenni.
  4. A determinisztikus folyamatok az érettek az átadásra. Ahol a kimenet kiszámítható, ott az ember vezet; ahol nem, ott embernek kell jóváhagynia.
  5. Indulj kicsiben, és építs normákat. A normaszegés önmagát jelzi: az AI kimenete romlik.
  6. A "multiplayer" nem technológiai kérdés. A jogosultságok és az adatok egységes jelentése nélkül a rendszer a legrosszabb esetben adatszivárgást okoz.

Összegzés

A vállalati AI-bevezetés szűk keresztmetszete nem a modell, hanem a folyamat és a kontextus. Justin Watt központi állítása az, hogy az AI-t mindenki egyjátékos eszközként ismerte meg, a cég viszont többjátékos környezet: a munka emberek között áramlik, és ha ezt a rendszert nem tesszük explicitté, akkor a modell csak a felhasználó saját szeletét látja. Ebből a felismerésből három gyakorlat következik. Először: a folyamatot kell megérteni, mielőtt bármit automatizálunk, mert a legnagyobb megtérülés gyakran nem az AI-ból, hanem a folyamat újragondolásából jön. Másodszor: a folyamatot azoktól kell megkérdezni, akik csinálják, nem azoktól, akik vezetik, mert a vezetői önértékelés erre alkalmatlan. Harmadszor: az átadás előfeltétele a determinizmus, vagyis hogy a kimenet kiszámítható legyen. Ahol ez nem áll fenn, ott a human in the loop marad az egyetlen felelős megoldás, nem udvariassági formula, hanem felelősségi következmény. Az epizód legértékesebb része a logisztikai cég esete, ahol az AI csak azután működött, hogy a 14 000 soros díjszabást 40 sorra vitték vissza, és a 160 órás heti ráfordítás 24 órára csökkent. A tanulság: az AI nem javítja meg a rossz folyamatot, de a jó folyamaton nagyságrendekkel gyorsabb.

Egyjátékos és többjátékos: a chatbot és a csapat közti szakadék

Justin az epizód elején a saját tapasztalatával indít. A cégek így kopogtatnak be: szeretnénk AI-t a vállalkozásunkba. Justin visszakérdez, hogy hol, mire a válasz az, hogy mindenhol. Ez az a pont, ahol szét kell választani valamit, mert az AI nem varázsgolyó, ami átdöf minden munkafolyamaton és minden adathalmazon.

„Most leadership has no idea what most of their team does all day.”

A fogalmi keret, amit bevezet, a videojátékok világából jön. Az AI-t mindenki egy chatboton keresztül ismerte meg, és az egyjátékos élmény maradt, mint a Mario vagy a Zelda: egyedül mész végig egy történeten, előre meghatározott karakterekkel találkozol. A többjátékos mód ehhez képest a Roblox, a Fortnite vagy a Call of Duty: internetkapcsolaton vagy, és száz másik emberrel együtt mozogtok ugyanabban a környezetben. Amikor egy chatbotnak azt mondod, hogy nézd meg az e-mailjeimet, a naptáramat és a SharePointomat, az kizárólag a te számodra elérhető információt látja.

Ez azért döntő, mert a vállalati folyamatok nem így működnek. Vegyük az értékesítési folyamatot: van benne üzletfejlesztés, van szolgáltatásnyújtás, van jogi, van pénzügy, és ezek az emberek különböző részeit látják ugyanannak a folyamatnak. A folyamat egész, de sok alkotóelemből áll össze, és nem csak a tényleges munkafolyamatból, hanem a benne részt vevő emberekből is. Ha azt mondod a chatbotnak, hogy indítsd el az értékesítési folyamatot, akkor az csak azt az információt kapja meg, ami a te számodra hozzáférhető. Ez viszont nem a vállalat működése, és nem a csapat működése.

Chris a saját gyakorlatából erősíti meg ugyanezt. Az ügyfeleiknél bevezetik az összeköttetéseket, hogy a modellek személyre szabottabb élményt adjanak, de ha nincs minden közösen megosztva a SharePointban, a Google Drive-ban vagy bármelyik szerverkörnyezetben, akkor a modell csak azt tudja támogatni, amihez hozzáfér. Ha valaki átadta a leadet, és a korábbi beszélgetés nincs olyan helyen, ahhoz hozzáférsz, akkor nem tudod, milyen kapcsolat épült ki. Chris megjegyzi azt is, hogy az általa látott cégek többsége még az egyéni összeköttetések szintjéig sem jutott el, vagyis nagyon messze van a többjátékos környezettől.

Arra a kérdésre, hogy honnan tudjuk, készen áll-e egy cég erre, Justin válasza az, hogy technikailag mindenki készen áll, mert a csapatok már most együtt dolgoznak és együttműködnek. A nehéz rész a munka újragondolása. Ha egy vállalatot leegyszerűsítünk egy futószalagra, akkor egy értékesítési folyamat vagy egy ügyfélszolgálati kérés is ilyen futószalag: valaki telefonál, majd ajánlat készül, majd árajánlat, majd tárgyalás, majd átadás egy másik csapatnak. A technikai és folyamati oldalon a csapatok valószínűleg nincsenek készen, de fogalmilag a munka ott van, csak el kell dönteni, hogyan alkalmazzuk rá az AI-t.

„AI, if it's done well, should kind of be invisible in the work.”

A futószalag-hasonlatnál maradva Justin szerint nem az a helyes minta, hogy az AI minden lépésre rákerül. Az AI a második, a negyedik, a kilencedik és a tizenkettedik lépésben segít, és azoknak egy részét elvégzi helyetted. Az pedig, hogy egy cég „készen áll-e”, rossz kérdésfeltevés: valójában mindenki készen áll, csak meg kell nézni, hol vannak azok a pontok, ahol az AI ténylegesen segíteni tud.

Kezdd a folyamatnál, ne az AI-nál

Chris szerint három fő korlátot hall vissza a cégektől: szeretnénk több AI-t használni, de nem tudjuk, hol; szeretnénk több AI-t használni, de nem vagyunk biztosak a kockázatban; és szeretnénk több AI-t használni, de nincs megfelelő emberünk rá.

Az elsőre Justin válasza meglepő: a cégek leggyakrabban azt kérik, hogy segítsenek növelni a bevételt, és ez általában rossz kiindulópont, mert az AI kifejezetten gyenge ebben. Az AI-alapú kimenő üzletkötés érezhető, és mindenki kap naponta kilencven levéltől olyan ajánlatot, amit csak archivál. A helyes célpont a belső működés, ahol a vállalat jelentős adót fizet a saját működésére, és ahol az árrés sokkal jobb lehet, miközben rengeteg idő megy el adminisztratív munkára. A konkrét kérdés tehát az, hogy a bevételt termelő részeken hol lassulnak le a dolgok.

A logisztikai cég esete ezt teljes mélységében megmutatja. A cég ajánlatokat és javaslatokat készít a logisztikai munkáira, de nem volt egységes igazságforrás a díjszabásokra. Nyolc ügyfélmenedzser dolgozott ott, mindegyiknek saját változata volt a díjszabásról, és mindegyiknek saját rendszere. Azt kérték, hogy az AI segítsen az ajánlatokban és az árajánlatokban. Justin visszakérdezett: hogyan? Ugyanaz a munka, de kilenc különböző díjszabás tartozik hozzá, hogyan találja ki ezt egy AI?

A megoldás nem az AI-ban volt, hanem az előtte lévő munkában. Össze kellett gyűjteni mindent egy helyre, ami egyetlen táblázat lett, és a díjszabás 14 000 sornak felelt meg. A Switchboard szerepe az volt, hogy kihívja a céget: hogyan lehetne ez 40 sor 14 000 helyett? Ez az a rész, amit Justin a saját hozzáadott értéküknek nevez. Miután a díjszabás lecsökkent, az AI alkalmazása már könnyű volt: bejön egy ajánlatkérés, az AI megnézi, mit keres a megrendelő, összeveti a díjszabással, megállapítja, hogy az milyen szolgáltatásnak felel meg, és elkészíti az árajánlat első változatát.

Az eredmény számszerű. A nyolc ügyfélmenedzser a hetük körülbelül felét, azaz heti 20 órát töltött az árajánlatokkal, ami összesen heti 160 óra volt. Ez heti körülbelül 3 órára csökkent, vagyis 24 órára a nyolc embernél. Az emberek nem kerültek ki a folyamatból, mert az ajánlatokat továbbra is át kell nézni, de ez már csak tíz-húsz perces korrekciókat jelent. És nem arról van szó, hogy leépítették volna a csapatot: a csapat bevétele nőni kezdett, mert az embereknek több idejük maradt az ügyfélkapcsolatokra és a munka tényleges lezárására, nem pedig az ajánlatok és javaslatok mechanikus előállítására.

„Half the time people think they need AI, and the answer is just, hey, this process and this workflow was created 20 years ago. That person has since left, and no one has ever thought to question it.”

Ez a mondat az epizód egyik visszatérő motívuma. Justin később megismétli: valami, ami egy hét és fél munkát vesz igénybe öt emberen és kilencven e-mailen keresztül, elvégezhető két emberrel két nap alatt és négy e-maillel, AI-val vagy anélkül. Az öt ember heti húsz órája úgy szabadul fel, hogy a folyamatot újragondolják, nem úgy, hogy AI-t tesznek rá.

Arra a kérdésre, hogy mi a várt kimenet, Justin szerint a legtöbb ember nem is gondolkodik. A kérdés egyszerű: mi lenne más egy év múlva, ha mindenhová betennéd, ahová szeretnéd? A leggyakoribb, őszinte válasz nem a munkahelyek megszűnése, hanem hogy nagyon sok ember végez nagyon sok adminisztratív munkát. Justin megfogalmazása szerint mindannyian úgy nőttünk fel, hogy űrhajós, orvos vagy ügyvéd szeretnénk lenni, nem az, hogy táblázatcellákat mozgatunk egész nap, és CRM-bejegyzéseket frissítünk. A vezetőség szintjén viszont a mérés máshogy néz ki: húsz százalékkal nőtt a bevétel, függetlenül attól, hogy ebben segített-e az AI, de nem kellett felvenni négy embert, akiket pedig terveztek. A növekedés tehát nem jár együtt a létszám növekedésével, és ez kézzelfoghatóan érzékelhető.

Kit kérdezz meg, és hol kezdd

A cégek gyakran azt szeretnék, hogy csak a vezetőséggel beszéljünk, mert ők majd megmondják, mi a teendő. Justin szerint ez visszautasítandó kérés, mert gyors út a kiábrándító vagy semmilyen eredményhez.

„At the end of the day, most leadership has no idea what most of their team does all day. And it's not a reflection that they're doing a bad job, it's more so once you get to a certain size, how could you know?”

A helyes kiindulópont tehát az egyéni hozzájárulók megkérdezése. A javaslata az, hogy válaszd ki a legnehezebb vagy problémásnak tartott részleget, vagy azt, amelyik a leglassúbbnak tűnik, és ott beszélj azokkal, akik a munkát végzik. Az N itt anekdotikus, Justin nyolc-kilenc esetről beszél, de a minta konzisztens: akik régen a cégben vannak, úgy érzik, elég mélyen ismerik a vállalatot minden szinten, hogy leírják a folyamatokat és az adatokat. „Még soha nem láttam, hogy ez igaz lett volna” - fogalmaz.

Egy másik visszatérő jelenség, hogy a vezetők úgy érzik, minden választ nekik kell tudniuk a csapat helyett. Justin ehelyett azt javasolja, hogy kérdezd meg a csapatot, de olyan analógiás kérdéssel, ami nem riasztja el őket, mert az AI hallatán sokan azonnal azt kérdezik, mi lesz a munkájukkal. A működő kérdés: ha varázspálcával holnap kapnál egy robotot, a munkád mely részeit gondolod, hogy el tudná végezni? Vagy még jobb: melyek a munkád legkevésbé kielégítő részei, amiket meg kell csinálni, de utálsz? Ha húsz-harminc embert megkérdezel, trendek rajzolódnak ki, és nagyjából megkapod a választ arra, hová érdemes fókuszálni. Chris ugyanezt a gyakorlatot erősíti meg a változásmenedzsment oldaláról: ha olyan dolgokba vezetjük be az AI-t, amiket az emberek nem szeretnek csinálni és nem is jók benne, akkor egy idő után maguktól kezdik keresni, hol lehetne még alkalmazni.

Részleg szinten Justin szerint az operáció a legjobb választás, különösen ha technikailag gondolkodó emberek vannak benne. A pénzügyi vezetőknek, a növekedési és értékesítési embereknek mind megvan a maguk nézőpontja, míg egy jól működő operációs részleg Svájc módjára viselkedik: a célja a vállalat szolgálata, nem a saját érdekeinek érvényesítése. Szerep szinten viszont nehezebb a döntés, mert a technikailag erős embernek üzleti érzékre is szüksége van ahhoz, hogy megértse, miért érdemes valamit egyik vagy másik módon csinálni, és mekkora a megtérülés. Az üzleti oldalon viszont sokan nem tudják, mi az az API vagy az MCP, és így nem tudják megmondani, mi lehet a megoldás, ha a lehetőségeket sem ismerik. Justin ezért az operációs részleget és az üzleti érzékkel rendelkező technikai embereket jelöli meg.

Erre a kérdésre tartozik az epizód egyik legjobb gyakorlati eszköze. Kérdezd meg a vezetőséget, ki a legtechnikaibb ember a szervezetben, majd kérdezd meg azt az embert, mire képes.

„their peak top-tier technical ability is creating pivot tables in Excel. And everyone else views that as a high technical competence.”

A teszt tehát az, hogy ha a válasz a kimutatástábla-készítés vagy egy saját magának vibe-codingolt teendőlista-alkalmazás, akkor az valószínűleg nem az az ember. Ha viszont van a szervezetben valaki, akkor ő általában klasszikusan képzett, IT- vagy szoftverfejlesztői szemléletű ember. A többjátékos környezetben nem egy ember fér hozzá az adatokhoz, hanem sok, és tisztázni kell, ki olvashat, ki írhat, milyenek a jogosultságok és a struktúra.

A jogosultsági blamázs története ezt a kockázatot szemlélteti. Egy cég operációt bízott meg a feladattal, technikai ember nélkül. Az operáció épített magának egy remek eszközt, ami a HR-adatokhoz kapcsolódott, és ezzel egy belső chatbotot kaptak, amivel gyorsan meg lehetett tudni dolgokat. Ezután azt mondták, hogy adjuk ki az egész szervezetnek, és nem vették észre, hogy az operációs csapatnak más jogosultságai voltak, mint mindenki másnak, viszont ezeket átadták mindenkinek. Gyakornokok kérdezhették meg, mennyit keres a vezérigazgató, és kollégák azt, hogy milyen értékelést kapott egy másik részlegben dolgozó munkatársuk. Justin tanulsága: ha nincs technikai ember a folyamatban, ez visszaüt. Chris hozzáteszi a másik végletet: ha az IT-ra hagyjuk, az valószínűleg a lehető legszigorúbban lezárja a rendszert, és az sem feltétlenül a helyes válasz, ezért kell olyan partner, aki mindkét oldalt érti.

Human in the loop kontra human in the lead: a determinizmus dönt

Chris vezeti be a fogalompárt, amit egy másik podcastben hallott: a human in the loop mellett létezik human in the lead. Az előbbi azt jelenti, hogy látom, mi történik, jó lesz, küldhető, de nem feltétlenül jelenti azt, hogy az ember hozza a döntést. Az utóbbi azt jelenti, hogy várom a kimenetet, mielőtt megmondom a következő lépést.

Justin szerint ez a megkülönböztetés determinisztikus és nem determinisztikus kimenetek kérdése. Ez magyarázza, miért vált a szoftverfejlesztés az egyik olyan területté, amit az AI bizonyos fokig megoldott: a kód determinisztikus. Ha nem teszel be egy oszlopot, akkor el fog bukni. A saját mérnökeiknél is ez a minta: megadják a célt és a kívánt eredményt, az AI megírja a kódot, majd ők átnézik, és ameddig fut és a biztonsága ellenőrizhető, valószínűleg rendben van. Ez gyökeresen más, mint amikor mindent át kell nézni, és előre tudod, hogy sok módosításra lesz szükség. A következtetés tehát: a determinisztikus kimenetű folyamatok érettek arra, hogy az ember vezessen bennük, a nem determinisztikusaknál viszont az embernek a folyamatban kell maradnia. A jogi terület a példa: az AI javasolhatja, hogy egy kikötés valójában nem szükséges, mekkora legyen a kártalanítás vagy a felelősség, de valakinek alá kell írnia, egyrészt a felelősség miatt, másrészt mert a jogi értelmezés annyira nem determinisztikus, hogy ezen a szinten nem lehet rá bízni.

Ehhez kapcsolódik az epizód egyik legjobb hasonlata, ami az AI három korszakát írja le bowlinggal. Az első korszakban úgy kellett gurítani a golyót, hogy szép lassan minden egyes bábuhoz odavezesd, vagyis nagyon pontos utasítások kellenek, babusgatni kell. Azután, az elmúlt körülbelül hat hónapban megjelentek a bumpered: gurítsd el a golyót, és a bumperek mint korlát mellett mindenki, aki nem profi bowler, valószínűleg eltalálja a bábukat.

„a lot of people use Chat GPT when it first came out, and it felt like a Google on steroids that was about it, and it kind of sucked.”

Az összehasonlítás éles: ha egy évvel korábban azt kérted volna, hogy nézze meg a naptáradat, az e-mailjeidet és a megbeszélések átiratait, elemezze az elmúlt hetedet, és mondja meg a következő hét prioritásait, akkor a kimeneten nevettél volna. Ma ez már egészen jó. A modell képes magától okoskodni és kiszűrni, amire szüksége van. És pont ezért válik kritikussá a kontextus: a többjátékos környezetben meg kell határozni a folyamatot, a munkafolyamatokat, a követelményeket és a szabványokat, mert ezek lesznek a bumperek. Ha a modell tudja, hogy ilyen típusú cég vagyunk, ilyen iparágban, ilyen szervezeti felépítéssel, és így közelítjük meg az értékesítést, a jogot vagy a pénzügyet, akkor a többit általában magától kitalálja, és ebben csak jobb lesz.

Kontextus és normák: a közös tudás felépítése

Chris felveti Jack Dorsey „hierarchy to intelligence” írását és az intelligencia-réteg gondolatát: ameddig a vállalat összes artefaktumát rögzítjük, addig az agentek és automatizmusok a munka nagy részét el tudják végezni. A kérdés az, hogy hol érdemes kezdeni: a kontextus megteremtésénél vagy az összeköttetéseknél.

Justin szerint a legtöbb ember az egyjátékos kontextussal kezd, vagyis az MCP-kkel és az integrációkkal, amelyek hozzáférést adnak a naptárhoz és az e-mailhez. Ez viszont személyes kontextus. A többjátékos környezet ebben tér el: az AI valóban el tud olvasni egy Harry Potter-kötetet körülbelül egy perc alatt, de ha száz ember minden e-mailje, naptára és egyéb adata áll rendelkezésre, akkor végig kell gondolni, hogyan adunk elsőbbséget egy szabványos dokumentum vagy sablon legfrissebb verziójának. És ha két részleg vitatkozik azon, mit jelent egy kifejezés, például az EBITDA mint pénzügyi mutató, akkor tisztázni kell, mi a számítás mögötte.

„if AI looks around your business and has nine formulas for how you calculate your sales pipeline, how's it going to be able to tell you when you ask it what your sales pipeline is?”

Chris saját példája mutatja a személyes szintű alkalmazást: egy beteg gyerek miatti álmatlan éjszaka után három megbeszéléssel indult a nap, és az első dolga az volt, hogy megkérte a Claude-ot, nézze meg a naptárát, a kapcsolódó e-mail-szálakat, és adjon egy rövid összefoglalót mindegyik megbeszéléshez. Nem forgatókönyvet kért, mert ismeri a saját üzletét, csak azokat a beszélgetési pontokat, amelyekkel nem tűnik felkészületlennek. Ez a kontextus személyes szintű alkalmazása. Ha viszont száz emberre skálázódik, akik mind száz levelet kapnak naponta és több online megbeszélést tartanak, az már hatalmas adathalmaz. És onnantól nem az a kérdés, hogy el tudja-e olvasni, hanem hogy kilencven napnyi hívásból ki tudja-e szűrni azokat a nyelvi mintázatokat, amelyek arra utalnak, hogy a termék valamit nem kezel.

Justin szerint itt a leggyakoribb hiba a tökéletes adattóra várása. Sok csapat úgy gondolkodik, hogy az egész vállalatra kiterjedő AI-hoz előbb tökéletes adattó kell, és minden szerep és minden részleg kontextusa fejekben lévő tudásból összegyűjtve, és csak azután lehet elkezdeni. Ennek az ellenkezőjét javasolja: válassz ki egy területet. A technikai feltétel az, hogy a tudás és a kontextus olyan helyen legyen, ahová a többi részleg később be tud kapcsolódni, de nem szabad azzal kezdeni, hogy mindenkit egy helyre hozunk, és csak utána használunk AI-t.

A javasolt indulás: egyetlen munkafolyamat, de nem az, hogy valaki válaszol egy e-mailre, hanem az üzlet egyik alapterülete, vagy egy egész részleg és annak minden munkája. Utána lehet rétegezni, mert így normák alakulnak ki. A legtöbb vállalat a kölcsönös elvárások kultúrájából áll össze, mert emberek döntik el, hogy valamiből csak egy verzió lehet, miközben mindenkinek van egy példánya ugyanarról a fájlról a saját lemezén, mindenki szerkeszti, és valójában senkinek nincs igazságforrása.

Az itt leírt mechanizmus az epizód egyik legérdekesebb megfigyelése: ha kicsiben kezdesz, normákat állítasz fel, majd hozzáadsz egy új elemet, és a normák sérülnek, akkor ezt az AI kimenetének romlása jelzi. Justin ezt öngyógyító figyelmeztetésnek nevezi: hozzáadtuk ezt a részleget, és most nem működik olyan jól, mert hat verziójuk van ugyanabból a sablonból. A rosszabb kimenet tehát nem hiba, hanem diagnosztikai jelzés.

Chris külön kiemeli a hallgatóknak: ha mindez túl nehéznek tűnik, akkor nem az a lényeg, hogy neked kell vezetned. Az a lényeg, hogy most már felkészültebben tudsz részt venni abban a beszélgetésben, amikor egy szállító megkeres, vagy amikor a vezetőség azt mondja, hogy ez most már kötelező.

Eszközök: Granola, Grok Bot és Claude Code

Justin személyes kedvence a Granola, az AI-alapú megbeszélés-jegyzetelő. A szerepéből adódóan rengeteg megbeszélése van, de a vállalatában mindenki szereti, mert könnyen használható. Van MCP-je, amivel bármihez csatlakoztatható, és mindent mappákba lehet rendezni. Ez pontosan a kontextus-felépítés ellenérve: ha van egy alkalmazás, ahová az összes megbeszélés-átirat befut, akkor elég mappákba rendezni, és máris nem nehéz. Chris kiegészíti, hogy a Granola egy AI-alapú megbeszélés-jegyzetelő.

A második a Grok Bot, amit Justin gyorsan megszeretett, mert megmutatja, hová fejlődnek a modellek. Egyre kevésbé kell a promptolással bajlódni, és lenyűgöző, mennyire homályosan lehet kérni, mennyit talál ki magától. Ha arról van szó, hogy egy projektről beszélnek ezekkel az emberekkel, akkor magától megnézi az ahhoz kapcsolódó Slack-csatornát, a Notion-oldalt, néhány e-mail-szálat és a Granolát is. Justin szerint ez hangsúlyozottan egyjátékos eszköz, de a személyes használat szempontjából ez az egyik kedvence.

A Grok Bot felépítése külön figyelmet érdemel, mert Slackre vagy iMessage-ra hasonlít: az oldalsávban vannak a botok, és velük beszélgetsz. Az első pillantásra felmerül a kérdés, hogy ez nem ugyanaz, mint a ChatGPT vagy a Claude, és nem az. Az integrációk sokkal jobbak, a botnak saját számítógépe van, ezért magától el tud menni dolgokat kideríteni és olyan helyekre is bejutni, ahol a Claude vagy a ChatGPT azt mondaná, hogy nem tudja, hogyan kell. A harmadik eltérés pedig az, hogy a botok beszélnek egymással. Justin az üzlet területei köré szervezi őket: van egy vezérkari főnök botja, ami a növekedési bottal beszél, ez utóbbi az értékesítést és a marketinget fedi, van szolgáltatásnyújtási bot a tanácsadócég operatív munkájára, és van pénzügyi bot. A gyakorlatban ez úgy néz ki, hogy jelzi, hogy jövő hétre van egy ötlete a tartalomnaptárra, mire a vezérkari bot elbeszélget a növekedési bottal, és tíz perc múlva visszajön azzal, hogy ezt két héttel később kellene tenni, a helyére lehet tenni egy másikat, és a növekedési bot szerint így kellene megfogalmazni. Chris szerint a hallgatóknak havi húsz dollárért, egy Cursor-előfizetéssel hozzáférhető ez a képesség, és ő maga is használja: fogta a szervezeti ábrát a munkaköri leírásokra mutató hivatkozásokkal, odaadta a vezérkari botnak, és megkérdezte, mennyit tud ezekből megépíteni.

A harmadik eszköz a Claude Code, ahol Justin szerint a code szó félrevezető. A Claude Cowork a Claude Code egy másik felülettel a tetején, a Claude Code viszont sokkal képességesebb, és utasítható arra, hogy sub-agenteket indítson. Az agentek szerinte nem termékként léteznek, hanem az AI működésének egy funkciójaként. A konkrét példa: sok felvétel és sok munkaköri leírás volt folyamatban, és egy kulcsfontosságú dolgot változtattak meg abban, ahogyan a leírásokat megfogalmazzák. A Claude Code-ban elég volt megadni a Google Drive hivatkozást az összes munkaköri leíráshoz, megkérni, hogy változtasson meg bennük valamit, és használjon sub-agenteket. Ezt körülbelül négy perc alatt elvégezte egy tucat munkaköri leíráson. A Claude Chatben ugyanez sokkal tovább tartott volna és kevésbé lett volna hatékony. Justin szerint nem a kódolásról szól, hanem arról, hogy ez a Claude legerősebb verziója, és ugyanez igaz a ChatGPT felhasználóknak a Codexszel. Chris gyakorlati útmutatót is ad: a Claude desktop verziójában a bal felső sarokban megjelenik a code navigációs hivatkozás, a ChatGPT desktop alkalmazásban pedig a chat vagy a work menüben a kis nyíllal legördíthető menüből érhető el a Codex. Chris megfogalmazása szerint a sima chat a legtöbbünknek olyan, mint egy autós ablak: elvesszük a választ és megyünk tovább. A Code vagy a Codex viszont olyan, mintha az AI-nak széke lenne az irodában, és valóban asszisztens vagy másodpilóta lenne.

A Handoff: mit adj át rendszeresen

Chris új szegmenst vezet be az epizódban, amit handoffnak nevez, és a kérdés az, hogy mi az, amit minden hallgatónak át kellene adnia az AI-nak, és amit már nem az embernek kellene végeznie.

Justin előrebocsátja a feltételt: ha az AI hozzá van kapcsolva az eszközeidhez, akkor ez sokat segít. Ha viszont csak egy chat ablak, ami semmihez nem kapcsolódik, amit a munkádban használsz, akkor a tanács kevésbé hasznos, és ilyenkor érdemes az IT-val vagy a vezetőséggel beszélni a helyzet megváltoztatásáról.

A konkrét javaslat: ha bármilyen szerepben rendszeresen kérnek tőled állapotjelentéseket vagy összefoglalókat, akkor készíts magadnak egy skillt. A Claude-ban és a ChatGPT-ben is meg lehet ezt tenni azzal, hogy megmondod, készítsen egy skillt, ami ilyet csinál. Meg kell adni, hol találja meg az információt, milyen kontextusra van szüksége az értelmezéshez, milyen állapotjelentést készítsen, és milyen hangnemben és nyelvezettel. Ezután el kell menteni skillként, és rendszeresen aktiválni. Justin szerint érthetetlen, mennyi időt töltenek emberek azzal, hogy mások kergetik őket azzal, hogy hol tart ez vagy az, hol van a kétheti összefoglaló vagy a jelentés. És a modellek egyre jobbak a diagramok és a valódi jelentések elkészítésében is, tehát ha ez része annak, amit csinálni kell, azt is meg lehet oldani így. Az összefoglaló szabálya: ha rendszeresen ugyanarról kérnek tőled frissítést, abból csinálj skillt.

Chris ehhez hozzáteszi, hogy a Chief AI Officer közösségében, a chiefaiofficer.com/community oldalon ingyenesen lehet csatlakozni, és rendszeres képzéseket tartanak pontosan erről. A belépő tippje pedig az, hogy ha nem tudod, hol kezdd, nyiss egy beszélgetést az LLM-mel, és kérd meg, hogy nézze meg, mit csináltatok együtt, és tegyen javaslatokat skillre.

Záró gondolat

Justin záró tanácsa egyszerű: kezdd el. Sok ember azért nem kezd bele, mert túlterhelt vagy fél. A megfélemlítést megérti, de a javaslata az, hogy próbáld ki, és kérdezd meg a modelltől, hogy a leveleidhez és a naptáradhoz kapcsolódva milyen ismétlődő dolgokat csinálsz, és milyen javaslatai lennének arra, hogyan tudna segíteni. Apró dolgokkal kell kezdeni.

A beszélgetés egyik visszatérő motívuma a Mátrix-hasonlat, amit Justin egy ügyvezető partnerrel folytatott beszélgetésből hoz: amikor elkezdi látni az ember a valódi világot, vagy a világot kódban, akkor a vállalatra nézve azt kérdezi, hol használjam az AI-t, majd miután egy-két-három helyen használta, mindenki elkezdi mindenre kérdezni, miért nem alkalmazzuk ott is. Chris ezt úgy fogalmazza meg, hogy az emberek elkezdenek AI-ban gondolkodni: nem nyers erővel oldanak meg egy üzleti problémát, hanem megkérdezik, hogyan segíthetne ebben az AI. Ez a váltás az, amit a vendég és a házigazda is ugyanúgy lát a saját ügyfeleinél, és ami miatt Chris szerint ez az epizód jel, nem zaj: ha több forrásból ugyanazt hallod, az általában valódi minta.

Forrás

  • Podcast: Using AI at Work (Chris Daigle házigazda)
  • Vendég: Justin Watt, társalapító és vezérigazgató, Switchboard
  • Dátum: 2026-09-28
  • Hossz: 51:05
  • Epizód link: https://www.buzzsprout.com/2278116/episodes/19858377
  • Honlap: https://www.usingaiatwork.com
  • Media: https://p.podderapp.com/2370592068/www.buzzsprout.com/2278116/episodes/19858377-how-ai-workflow-automation-changes-the-way-your-business-works-with-justin-watt.mp3
  • Transcript forrás: natív Buzzsprout transcript (podcast:transcript VTT), 10 548 szó

Kapcsolódó külső források

  • Switchboard (a vendég cége, belső AI-eszközök és automatizált munkafolyamatok): https://www.withswitchboard.com
  • Justin Watt LinkedIn (a vendég elérhetősége, DMs nyitva): https://ca.linkedin.com/in/wattjustin
  • Granola (AI-alapú megbeszélés-jegyzetelő, MCP-vel): https://www.granola.ai
  • Claude, Claude Code és Claude Cowork: https://claude.ai
  • ChatGPT és Codex: https://chatgpt.com és https://openai.com/codex
  • Grok Bot: https://grok.com
  • Notion: https://www.notion.so
  • Chief AI Officer (a podcast szponzora, ingyenes AI-felkészültségi felmérés és stratégiai útmutató, közösség): https://www.chiefaiofficer.com
  • Jack Dorsey „from hierarchy to intelligence” írása (az intelligencia-réteg gondolata, amit Chris hoz be): az epizódban említett hivatkozás
  • The Artificial Intelligence Show (Paul Reuters podcastje, a „human in the lead” kifejezés forrása Chris szerint)

Kapcsolódó belső források

Hogyan kapcsolódik a saját rendszerünkhöz?

Ez az epizód szokatlanul közvetlenül érinti a saját pipeline-architektúránkat, és több ponton visszaigazolja a meglévő döntéseinket.

  • A „kezdd a folyamatnál, ne az AI-nál” elv pontosan az, amit a podcast-processing skillnél is megtettünk: a self-write pipeline bevezetése előtt megmértük a chunk-batch alternatívát (FTF#57 A/B mérés), és ahol a régi megoldás 43 százalékkal több szöveget adott ugyanazért a pontszámért, ott nem AI-t tettünk a folyamatra, hanem a folyamatot gondoltuk újra. A logisztikai cég 14 000 soros díjszabása és a chunk-konkatenáció ugyanaz a hibaosztály: a bonyolultság nem hozzáadott érték.
  • A „human in the lead” a determinisztikus kimeneteknél közvetlenül leírja a saját postprocess-sorrendünket. A determinisztikus kapuk (output_integrity_gate.py, injection_assertions.py) azok, ahol az ember vezet: a gép eldönti, amit gép el tud dönteni, és blokkol. A value tengely (LLM-ítélet) az, ahol a human in the loop marad, mert nem determinisztikus. Az epizód jogi példája és a mi script_leak kapunk ugyanazt a logikát követi: ahol a kimenet nem kiszámítható, ott emberi jóváhagyás kell, ahol viszont igen, ott a gépé a döntés.
  • A „normák öngyógyító jelzése” megegyezik a saját broken-windows megközelítésünkkel. Az epizód azt mondja, hogy ha egy új részleg hozzáadása után romlik az AI kimenete, az nem hiba, hanem jelzés a normaszegésre. Nálunk ugyanez a mintázat: a --drift-check és a canonical-transcript szabályok (D2, G szabály) pontosan a normaszegést teszik láthatóvá, csak nem a kimenet minőségén, hanem a mappastruktúrán keresztül.
  • A kontextus mint a modell korlátja a saját MEMORY.md és skills rendszerünk indoklása. Ahogy az epizódban kilenc díjszabás kilenc különböző választ ad ugyanarra a kérdésre, úgy nálunk a state/notes.md és a MEMORY.md az egyetlen igazságforrás a session-ök között, és a memory-relevance-filter az, ami eldönti, melyik kontextus kerül be egy adott feladathoz. Justin „bumperei” és a mi relevance-filterünk ugyanazt a célt szolgálják: korlátot adni a modellnek, hogy a válasza használható legyen.
  • A skill-írás mint átadási egység a legközvetlenebb párhuzam. Justin azt javasolja a hallgatóknak, hogy az ismétlődő állapotjelentésekből csináljanak skillt, és ha nem tudják, hol kezdjék, kérjék meg az LLM-et, hogy nézze meg a korábbi közös munkát és tegyen javaslatokat. Ez pontosan a saját skill-curation folyamatunk: a munka közben keletkezett ismétlődő eljárásokat skill-lé képezzük, és a skill-library-maintenance kezeli a karbantartásukat. Az epizód ehhez hozzátesz egy érvrendszert: a skill nem technikai luxus, hanem annak a munkának az átadása, amit senki sem szeret csinálni.
Vissza a tetejére