- október 15-én Tim O’Reilly egy órás adásban beszélgetett Andrew Odewahn-nal, az O’Reilly Media műszaki igazgatójával a Live with Tim O’Reilly sorozatban. Andrew csapatával az elmúlt évben az Expert Intelligence nevű eszközkészleten dolgozott: ezek olyan megoldások, amelyek egy AI-ügynököt az egyes szervezetek belső rendszereihez kötnek, leírják a képességeit (skill file), és az O’Reilly könyvtár gyakorlati kereteivel támasztják alá az elemzéseket.
A kutatóügynök felépítése
Andrew elmondása szerint az ügynök személyes szükségből nőtt ki: gyakran kellett megtudnia projektek állapotát (például mennyi ideig tart egy RabbitMQ–>Pub/Sub migráció), amit egyedül nehéz átlátni. Az ügynök négylépéses építése: a szervezet információs rendszereinek feltérképezése hierarchiában, ezek összekapcsolása MCP-n keresztül, egy skill megírása az ügynök viselkedéséhez, majd az Expert Intelligence réteg hozzáadása.
A források feltérképezése volt kulcsfontosságú: stratégiai célok és feature-prioritások a Productboardban élnek; ezek epikekké, sprint-ekké és story-kká válnak Jira-ban; a story-k kódot eredményeznek GitHub-ban. A platformot körülbelül 300 szolgáltatás alkotja, amit egy szolgáltatáskatalógus ír le, és az observability eszközök mutatják az SLO-k teljesülését. A skillnek a helyi gyakorlatokat is kódolnia kellett (például hogy egyes csapatok epiket dátummal zárnak, mások csak akkor, ha minden ticket le van zárva). Az ügynök kutatóügynök szerepet kapott — nem kódolni, hanem jelentéseket írni.
A rendszerek MCP-vel való összekapcsolása volt "a legteljesebben fárasztó lépés". Productboard akkoriban nem rendelkezett MCP szerverrel, ezért Andrew wrapper-t írt. Más cégeknek azt javasolta, hogy a beszállítói listából induljanak ki: exportálják a procurement rendszerből, kérdezzék meg a modellt, mely termékek tartalmaznak releváns információt, és állítsák őket fontossági sorrendbe. Ezt az O’Reilly termékmenedzserei Expert Intelligence skills hub-ként tervezik elérhetővé tenni.
Egy toborzási esetből munka- és toil-audit lett
A bemutató központi példája egy korábbi esettanulmány volt. Egy mérnökvezető toborzást kért; az első jelentés, amit az ügynök készített, részletes adathalmazt hozott: egy öt fős csapat, amely a tartalomért és metaadatokért felel, 10 darab tier-A szolgáltatásával (plusz B és C szolgáltatások), a Pub/Sub migráció 64%-os készültségi állapotával, és a teljes backloggal. A jelentés arra jutott, hogy kapacitásprobléma miatt fel kellene venni új embert — nagyon részletes, talán túl részletes eredmény.
Amikor ugyanazt az elemzést az Expert Intelligence-hez kötve futtatta, a következtetés más lett: az üzemeltetési túlterhelés strukturális probléma, nem egyszerűen személyzeti hiány. Az ügynök az Expert Intelligence-ből átemelte a Google Site Reliability Workbook-ból ismert "toil" fogalmát (ismétlődő, automatizálható, manuális munka, ami lineárisan skálázódik a szolgáltatással), és elkülönítette a backlogon belül a toil-t a valódi fejlesztési munkától. Javasolta a tervezési ciklus előtt egy strukturált toil-auditot, explicitt toil-csökkentési célokat és a runbook-tulajdonlás kezelése mint elsőrendű mérnöki artefaktum. A csapat követte a javaslatot és jelentős hányadát lezárta a korábban kognitív terhet jelentő backlognak.
A jelentés Jim Highsmith (Agile Manifesto aláírója, Wild West to Agile szerző) elméletét is idézte, hogy a technikai adósság halmozódik. Andrew kiemelte, hogy a rendszer nemcsak elvont tanácsokat adott, hanem konkrét projektre (például Django-upgrade) helyezte azokat a kereteket, így gyakorlati, konkrét teendők jöttek ki.
Egy másik elemzés a csapathatárokon átívelő szolgáltatásokat vizsgálta: a videó metaadat-szolgáltatást a rendszer komplex alrendszer-problémának diagnosztizálta (nem egyszerű boundary problémának), Kent Beck coupling-elveire és mikroservizek szakértőinek munkáira hivatkozva. Az ügynök idézeteket húzott ki, attribuálta és forrásra mutatott — ez után néhány régi rendszert kivontak a termelésből. Andrew hangsúlyozta: nem azt akarja, hogy LLM-ek kódot adjanak hozzá; azt akarja, hogy csökkentsék a kódot.
A legnagyobb meglepetést az váltotta ki, hogy amikor az elemzések ismert, hiteles szakértőkhöz kapcsolódtak, a dokumentumok sokkal jobban befogadhatóvá és cselekvésre ösztönzővé váltak. Korábbi adathalmaz-jelentésekből hiányzott, honnan származik egy állítás; a szakértői attribúció növelte az olvasói elköteleződést.
Tim O’Reilly: szakértelem bevonása mint fókuszálás
Tim azzal helyezte el a bemutatót a szélesebb vitában, hogy szembeállította a "modellek már önállóan elvégzik" narratívát azzal az állítással, hogy érdemes visszahozni a szakértelmet. Hivatkozott Felix Rieseberg (Anthropic) aznap közzétett bejegyzésére, amely a modellekkel való munkában négy ambíciót különít el: sebesség, magasság (altitude), mélység (depth) és hatótáv (range). Szerinte Andrew azzal, hogy szakértőket és elismert forrásokat idézett, magasságot és mélységet nyert: nem csak gyorsabban dolgozik a szervezet, hanem jobban gondolkodik a célról és szakértői megközelítést alkalmaz.
Tim metaforájával — az AI programozást varázsige-szövegezésként leírva — azt emelte ki, hogy Andrew lényegében így szólította meg a modellt: „Kent Beck erejével gondolkodj erről a problémáról”. Még amikor Andrew nem konkrét személyt nevezett meg (például az SRE workbook esetében), az O’Reilly kiadványok kanonikus tudása növelte az ügynök teljesítményét.
Andrew elmondta, hogy az első promptja így szólt: „Legyél snob — keresd meg ezeket a nagyszerű forrásokat és nézd át őket.” Inkább azt akarja, hogy a modell elismert szakmai művek alapján gondolkodjon, mintsem elfogadja az első találatot.
Mit csinálnak a modellek iránymutatás nélkül
Tim azt állította, a modellek irányítás nélkül gyakran rossz irányba indulnak: a láncolt gondolkodásukból néha véletlenszerű internetes fájl kerül elő mint első forrás. Andrew beszámolt egy esetről: amikor az ügynök ösztönzés nélküli keresést végzett incentiv programokról, egy „Robusto” nevű cég frameworkjét találta meg az első találatként — az ok: nem volt csatlakoztatva a VPN-hez. Miután a VPN-t bekapcsolta, relevánsabb források (például Harvard Business Review) jelentek meg.
Tim felvetette a gazdasági dimenziót is: például Anthropic Claude rendszerének rendszerpromptjában vannak korlátok arra, hogy mennyit idézhetnek forrásokból — ezt úgy olvasta, mint hogy az AI-vállalatok el akarják kerülni a tartalomköltségeket, ami által a modellek gyakran általánosságokhoz nyúlnak. O’Reilly ezzel szemben a meglévő jogdíjmodellt alkalmazza: az Expert MCP szerveren keresztül visszaadott anyag idézhető, és a szerzők jogdíjat kapnak rá, így a szakértői tartalomnak piaci jövedelme van.
Expert Intelligence jelenleg előzetes kiadásban van alapító partnerekkel, miközben O’Reilly a gazdasági modelljeit finomítja; érdeklődő szervezetek elérhetőséget kérhetnek a termékoldalon.
Mi történik a jelentés után: a SuperAnswers és a döntéshozatal
A prezentáció második része arról szólt, mi történik, miután az ügynök jelentést ír. A döntések konszenzust igényelnek — és az AI-elemzéseknél ellenőrizni kell, hogy a modell nem egy elavult, vagy jelentéktelen forrásra támaszkodott-e.
Kezdetben a csapat Google Docs-ként terjesztette a jelentéseket, de két probléma merült fel: az értő vita gyakran a kommentekben zajlik, és akkor O’Reilly politikája miatt az MCP nem látta a Google Docs kommenteket; amikor pedig a modellbe visszaemelték a vitát, a kommentek eltűntek.
Doug Hogan (O’Reilly engineering director) épített egy alternatívát Git és GitHub fölé, amit Andrew SuperAnswers-nek nevezett. A dokumentumok Git repóban laknak, a vita GitHub Discussions-ben történik, minden változtatás verzionálva van. Így az ügynök meg tudja kérdezni, mi a konszenzus egy projektről, képes beépíteni a kommenteket egy új tervezetbe anélkül, hogy elveszítené a történetet, és rekonstruálni, mikor hozták meg a döntést és mit tudtak akkor a résztvevők. A rendszer automatikusan generálhat derivált dokumentumokat (scope statementek, meeting agenda stb.), és gráfnézetben csoportosítja a témákat és kiemeli a nyitott döntéseket.
Andrew szeretné open-source-olni a SuperAnswers-t; ez szerinte csak egy vékony réteg a Git fölött. Hangsúlyozta, hogy a probléma nem csak a mérnökségre korlátozódik: értékesítésnél is elterjedtek a fragmentált rendszerek (Salesforce, 6sense, Gainsight), és minden funkciónak hasonló igénye van a rendszerek összekapcsolására.
Közönségi kérdések és lezárás
A kérdések között felmerült az aggodalom, hogy a dolgozók az AI-hoz beszélnek egymás helyett, és a munka eltűnik egy „AI-lyukban”. Andrew válasza szerint a Git használata részben választ ad erre, mert központi nyomot ad embernek és gépnek. Ugyanakkor az ő célja, hogy az AI támogassa az emberek közötti beszélgetést, nem váltsa ki azt.
Andrew azt is bevallotta, hogy nem gondolkodott elég korán azon, hogyan fogják az emberek átnézni és reagálni az AI-írt dokumentumokra. A dolgozók gyakran elutasítják az egész anyagot, ha abban egyetlen tény hibás. Az AI-eszközöknek képeznünk, rendezett bizonyítékot kell bemutatniuk és növelniük kell az emberek analitikus kapacitását, nem le kell őket váltani.
Tim a deskilling (készségek elvesztése) veszélyére is figyelmeztetett: saját kísérlete egy kis finomhangolással Fable-lel részben azért nem volt sikeres, mert a modell nem segített megérteni az egyes lépéseket. Ezzel szemben az O’Reilly Tutor (fejlesztés alatt) Andrew szerint elég háttértudást küldött, hogy Tim felismerje a hibáit.
A beszélgetés végén Andrew összegzően azt mondta, hogy a szervezet okosabbá tétele nem csak a sebességről szól. Három dolog kell hozzá, amit a modellek önmagukban nem adnak meg: (1) térkép arról, hol él a szervezet tudása, (2) egy megbízható szakértői testület vagy kanonikus források, és (3) egy hely, ahol emberek vitatkozhatnak és reagálhatnak az AI termékeire.
Hol lehet megnézni
A Live with Tim O’Reilly adások teljes felvételei elérhetők az O’Reilly learning platformon, YouTube-on és podcastkliensben.
